I found this while trying to decide if vlang was a real thing or not. There was a link to how memory management was done in Lobster: https://aardappel.github.io/lobster/memory_management.html, which was a good read. Lobster itself looks interesting. Especially given that it uses what I assume to be a similar memory model as to what Nim is moving toward?
I found Lobster the same way as @ducktape (V discord), and decided to put it to the test with a difficult memory management challenge, a persistent balanced tree... difficult because there is no clear ownership model: structure is shared among all versions of the tree, and rebalancing makes link tracing non-trivial.
I happened to have an implementation in Nim that I ported to Lobster.
The memory management worked well in both Nim (default gc) and Lobster.
The Lobster type inference/checker separates nillable and non-nillable versions of reference types, so several changes were needed to convince Lobster that references wouldn't be nil. The Lobster generic type inference is interesting to explore: typical Lobster code is very lightly annotated with types, if at all.
As far as I understand, one reason Nim doesn't have powerful type inference (like it can't infer backward) is compilation speed.
Lobster has very powerful type inference and its compile time, almost instant, see video about it. When in Nim even for simple script you had to wait couple of seconds to compile it. Can Nim borrow some ideas from Lobster to have same compilation speed?
It not compiled it JIT ...
Implementation
Choose between running directly using the convenient JIT, or compilation to C++ for extra speed.
It not compiled it JIT
It doesn't matter. Lobster performs full code analysis, statically. So it doesn't matter how exactly it run, as JIT or Compile-to-C. As in both cases, the infer and code analysis happens before.
My point was about type infer. The argument Nim has against the type infer - it slows down the compilation speed. And I showed the Lobster as example that type infer could be fast.
Yes, Crystal also struggle with slow compilation speed, and given that Lobster is pretty much same as Crystal, with minor syntactical differences in how methods/functions are defined, maybe Crystal could benefit from that too.
I was thinking the same. Crystal is really nice, but compilation time is definitely an issue. I used both Nim and Crystal to write small programs to solve the Advent of Code puzzles last December, and it was typical for the Nim build (with nim c -d:release --gc:orc) to take around 1.5 seconds, while release builds with Crystal often took more than 15 seconds. I assumed this was due to how its more hands-off type inference works, so I'm curious to see how Lobster does it.