As easy as JavaScript to write, as fast as Rust when the extra effort to write it justifies it.
As easy as JavaScript to write, as fast as Rust when the extra effort to write it justifies it.
But perhaps it's a viable "training wheels" approach for getting used to borrow-checker friendly patterns? And I guess a scripting interpreter option that is fully rust-aware in terms of lifetimes could be truly golden for certain use cases, even if it turns out to be completely hostile to users not fully in tune with the underlying Rust. Sometimes "no recompile" is very important.
I wonder if the genesis story of the project might be hidden in "Dada has a required runtime": perhaps it started with the what-if of "how nice could we make Rust if we abandoned our strict "no runtime!" stance and went for making it runtime-heavy like e.g. Scala"? Then the runtime pulls in more and more responsibility until it's easier to consume a raw AST and from there it's not all that far to making types optional.
So don't do that then? Put most things on the stack. It's far faster than any allocation.
> if latency matters you end up having to care about (de)allocation patterns at the app level.
Yes, and you want tools that allow you to precisely describe your needs, which might be more difficult if a lumbering brute is standing between you and your data.
Most languages don't use reference counting because most applications are either one-shot console apps, GUI apps, or web apps - the latter two operate on "bursts" of input. If your app operates in "bursts" then a tracing GC is superior since you can delay collection until the app is waiting for more input. Real-time apps don't have a moment where they "wait" therefore they should prefer reference counting for its predictable performance.
You have to use the right GC algorithm for the right job, but unfortunately programming language runtimes don't usually offer a choice.
Rusts “difficulty” stems from its single ownership model, and this model is “different” not “easier”.
JS has plenty of bad parts you shouldn't use. Classes are the main one.
return
{ ... }
And JS helpfully inserted a semi-colon after returnThis is a feature you need to know about and you have to go out of your way not to get rekt by it
This isn't meant to be an attack on javascript as a worthwhile tool to learn, by the way, just a testament to the fact that it's not an easy language to master in the slightest.