If I were looking for an alternative in NextJS, looking for something built in Rust would definitely not be in top of my mind. I would assume this kind of movement from JS -> Rust would be quite rare.
They're great weekend project and prototyping things but yeah.
It was basically a one man startup and the argument to use Rust was because the guy wanted to use WASM on the frontend, because it was a mind mapping software (as far as I remember, and so information heavy, blablabla).
WASM might make sense or not, dunno. Figma somehow manages to be fast, I don't think they use WASM. (They are fast because of canvas, right?)
Rust becomes more viable the simpler the API between it and your JS is, and "takes events and renders pixels" is a very simple API.
> Figma somehow manages to be fast, I don't think they use WASM.
Figma not only uses wasm but pioneered it. They're consulted be standards bodies, they implemented wasm features in browsers, ...
Are they? It is a small miracle it runs as well as it does on the browser, but if you compare it to Sketch it’s molasses.
This is contrasted to Go, which I think turns away these developers (at least it did for me…) due to having null-pointer/non-existent nullability.
As opposed to Typescript's null, undefined, or optionally defined types? I don't use Go or Rust, but I do use Typescript so maybe I'm a bit confused by this statement. Go allowing nullability doesn't seem like a dramatic shift from Typescript's 3 different ways to represent a potentially ill defined object, and it wouldn't turn me away from the language.
Go having nullability isn’t the problematic part - it’s how nil is not type checked, so a value might secretly be nil and you won’t know until your program crashes at runtime.
Rust avoids this by just not having null, instead using things like Result and Option types, which is pretty neat with pattern matching.
One caveat - these are hello world programs without I/O. The maintainer plans to add I/O to the benchmarked code.
That’s one misconception you have about Go, when it comes to Cold start uptimes Go is one of the top garbage collected language to compete the likes of C, the go runtime is a progressive runtime it runs together with your code so it’s basically a Vlang code with added C codes
The others (except Swift) are barely mainstream.
Kotlin meta-programing is done via reflection and compiler plugins.
Traits are interfaces.
Similar thing with interfaces - while they serve the same purpose as traits, they are nowhere as flexible/expressive. E.g you cannot do blanket interface implementations - i.e. implement an interface for only the classes that implement another interface. You also cannot implement the same interface more than once, differing by generic parameters only. Or cannot define an interface with an associated type member (Scala is another language that can do it).
Yes they aren't 1:1 to Rust, so what.
Does any of them matter to ship better Android applications written in Rust? Nope.
Likewise Ada makes your vacations possible, in case taking a plane or train is part of it.
Kotlin turns pixie dust into Android apps, while Swift does the same for iOS.
There is definitely a mental overhead with rust but this has nothing to do with low level or high level concepts. The borrow checker is actually a high level feature that exists for safety, not performance.
How can you write that with a (I suppose) straight face? Rust makes you think about lifetime of every single variable, as anyone who's written a couple of lines of Rust knows... it' not just the lifetime annotations you will need when you get past the "copy everything" phase and start using or writing data structures, but the borrow checker making even the simplest stuff something you actually have to think through carefully (do you need to pass a reference, make a copy, use a mutable variation of some function, open a new block to limit the scope of the variable, assign it to a local variable to avoid it getting out of scope too early?). This is plainly "low level" stuff you need to worry about all the time which you just don't in any high level language.
It's a different style of programming but still high level. Make no mistake the abstractions are high level but the cost is zero, hence the term zero cost abstraction and the association with "low level."
The fundamentals are very different but it’s a case of convergent evolution - and I’m happy to liberally sprinkle clone’s around my rust code