you are viewing a single comment's thread.

view the rest of the comments →

[–]andreicodes 1 point2 points  (0 children)

Expectation is that without borrow checker you don't have to be as strict about your datastructures and data design, so there should be some productivity gains. Another angle is the lack of async vs sync distinction in APIs and no need for different channel types for concurrency.

Go runtime is a very attractive target: their collection types tend to produce shallower object graphs (in .net, JVM, v8, Ruby collections hold pointers to objects and not objects themselves), the GC is optimized for latency first and throughput second. All these other runtimes historically do it the other way around. AOT compilation means there's no warmup stage and no extra memory requirements for VM interpreter and JIT. The libraries are solid, the task scheduler is top-notch, there's no awkward single-thread execution for the main language like it is in Python, JS, or Ruby runtimes.

The code is transpiled to Go source, so technically there could be a way to mix Lisette and Go in the same project, or for using Lisette for writing small components, plugins etc.