One thing I particularly like about Lobster is its memory management. It uses rust-like borrowing rules automatically under the hood to make one of the fastest RC implementations ever seen.

I think this is the direction languages should head in: embrace shared mutability for the flexibility benefits, and blend it with borrow checking for the speed benefits.

Vale and Koka do the same thing as far as I understand it. I think Koka looks the most interesting of the three - its effects system seems like it lets you have purity without the annoying "can't I just add a liiiittle printf debugging here without rewriting my entire program?"

It may be only "little" not "liiiittle" :-), but Nim lets you explicitly bypass the effects system locally for cases like this:

     {.cast(noSideEffect).}: echo "GOT TO THIS LOGIC with a=", a

Serious question which language doesn't have this 'escape hatch'? AFAIK even Haskell has unsafePerformIO to allow this..

Most languages don't encode purity in the type system, so they don't need an "escape hatch" - there's nothing to escape from.

Unlike `unsafePerformIO`, Koka's approach isn't really an "escape hatch" - effects are a safe, principled part of the language. And, if I understand them correctly, even though they're more ergonomic than monads, they also come with friction of their own (maybe needless to say, otherwise they couldn't be enforcing anything) - adding logging to a function will add the `console` effect to the function's type, which bubbles up to callers and might cause issues if any callers are declared as `total` (and indeed, that's the default for function type annotations). But at least, unlike Haskell, you wouldn't need to add `return` and `lift`s everywhere to fix things; and the changes you'll need to make to your signatures are usually quite a bit more straightforward I think.

This is what modern (arc/orc) Nim versions do as well.

One thing I find interesting and original is the idea of flow-based type inference.

Citing the "The Lobster Type System" page [1]:

    Type checking happens in order of function calls,
    i.e. it is much like evaluating the code,
    but with types instead of values.

With this flow analysis, lobster infer more specific types for each usage of a variable.

    var a = nil  // a is a nilable of unknown type
    if ..:
       a = "foo" // a is a nilable string
    if a:        // guaranteed not be nil inside block
       a += "!"  // ok: a is of type string here

[1] https://aardappel.github.io/lobster/type_checker.html

It is not a new idea. Typescript (for example) does something similar.

I found the contrast between zero known published game and the claims of iOS and android targets for a 10 year old language to be... interesting.

But you can see some more for yourself, including screen shots of the author's unreleased game:

https://github.com/aardappel/lobster/issues/136

I think what lobster really needs at this point is a page that prominently displays better examples of possible and real end-products somewhere.

raylib example:

https://itch.io/games/made-with-raylib

Can you elaborate what is so "interesting" about it? Yes I've been working on it for 10+ years (git history only since 2013), as a side project. There's actually one published game on Steam made with it, but its very simple. The one I am building now (linked from you link) is anything but simple.

Android build is part of CI so appears to be working. iOS is not, so may be broken but the code has always supported 6 platforms (win/lin/osx/ios/android/wasm).

As the link says, there aren't a lot of end-products made with it yet. It's mostly my side project, not sure why you are thinking there should be such a page, this is not a corp-backed megaproject making any kind of claims :)

Turns out, making a language popular in these days is hard. You may still find something interesting within though :)

Right now, as a side project, 99% chance of vaporware on my part, I'm interested in writing a game with first release as an HTML5+canvas or WASM game. I'm not interested in writing it in C or Rust because of free time constraints, but I'm also not going to use anything JVM and I'm not going to use anything slow, heavy, and sloppy like python. Stretch goals include a multiplayer game server, then android and iOS apps.

Nim is my leading choice for prototyping this ATM. I can at least write the game logic core once, unified server and web client, and figure out secondary target platforms later.

Love2D is also a thing of interest, but I find the concept of actually using Lua to be cruel. Javascript is cruel too, but I at least have muscle memory and Stockholm syndrome from my day job, and Nim can target JS directly in a suitable enough way for using canvas.

Lobster, at a glance, looked like it could compete with or compliment Nim on my specific project idea.

I have no idea why you would even think a project like this is vaporware. It makes no claims that you can't test out by just downloading it and giving it a spin. You could have known its not vaporware in less time than you just spent arguing on HN: https://aardappel.github.io/lobster/getting_started.html

I can't help you much with your language choice since you appear to be very particular in what you want. Nim is likely more mature as a project, so I suggest you go with that instead.

> I have no idea why you would even think a project like this is vaporware.

I thought I was pretty clear that my project was vaporware, not yours.

Author of Lobster here, AMA.