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.
More to the point in terms of wider adoption for any of these JS in X languages: I've never been involved in a company that would want HTML/JS level code being produced at Rust developer salary overhead costs.
They're great weekend project and prototyping things but yeah.
My friend (ex-coworker) was involved in one about 1.5 years ago for a few months.
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?)
I think it'd be less about being info-heavy and more about needing to reimplement everything on top of a canvas anyway. Not saying it's impossible to implement a mindmap with html, but it's possible to want mindmap features that would be much easier to implement with canvas.
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, ...
I think that Typescript is a gateway drug for a language like Rust. Developers who like the combination of strictness and ergonomics of strict Typescript could be attracted to taking that “to the next level” with Rust.
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.
> 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.
null/undefined is type checked in Typescript so the compiler will make sure you check whether your value is defined or not and handle it appropriately.
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.
Here’s an analysis of cold starts on AWS Lambda (updated daily) that backs up your claim that Rust has the fastest cold starts - https://maxday.github.io/lambda-perf/. Although to be fair, Go isn’t that far behind on warm starts.
One caveat - these are hello world programs without I/O. The maintainer plans to add I/O to the benchmarked code.
Is not "hello world programs without I/O" basically measuring the startup time of the language's runtime? Not that that's not important, but given that Rust and Go are the only two compiled languages there, and Go has a slightly heavier runtime, these times are entirely what I'd expect.
When I hear "cold start" I usually think of the amount of time between process exec to when my first line of code starts executing. In this case I would just assume that Rust will be faster since it's pretty much how long it takes to load the binary image into memory and jump to the _start/main entrypoint. Go has a whole runtime to boot up before ever getting to that point. Many, many layers of setup code. So it's not surprising at all that it has a significantly slower "cold boot".
> Go has a whole runtime to boot up before ever getting to that point. Many, many layers of setup code. So it's not surprising at all that it has a significantly slower "cold boot"
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
Yeah… I have two containers running on google cloud run right now, the nextjs container cold starts an average of 1.5 seconds. The actix web rust container cold starts in 150 ms. The difference is staggering, I can’t even tell when the rust container cold starts
The versatility of Rust is quite impressive. Its looking like given a few years for these frameworks to mature, Rust could end up being a great job for just about every task.
Rust is both a low level but also a high level language. There aren't many mainstream languages that can go higher level than Rust with its traits, sum types, generics and macros. Haskell, Scala, maybe C++ to some degree, what else?
I don't think Kotlin is higher-level than Rust. It misses most metaprogramming features, and its generic programming capabilities are weaker (nothing remotely as capable as traits/implicits/type-classes).
I've said it misses most of metaprogramming features, not all of them. Reflection can't do the same things as macros can. Macros can transform arbitrary AST to arbitrary AST, reflection can't.
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).
The discussion was about being higher-level vs lower-level. Rust is a more expressive language than Kotlin. Where languages are used is a different matter, because expressiveness is not the only thing playing role there. Politics and historical reasons are another dimension.
You seem to be missing my point. The point was not about which languages are mainstream (which is highly subjective, hard to measure and also may be an effect of certain politics), but about their level of abstraction. Rust is often placed in the "low level, close to the hardware" bin because it can go low-level very far if you wish to. But it is often forgotten that it can be also very high in terms of expressiveness / abstraction power and offers productivity features not found in many mainstream languages.
This is an old myth thats no longer fully true. Rust is a language that straddles both high level and low level in the sense that it is literally indistinguishable. You can use rust as if it were a high level language without knowing anything about low level stuff. The binary you get at the end, ends up being low level in the sense that it's performant as if it was written in a low level language.
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.
> You can use rust as if it were a high level language without knowing anything about low level stuff.
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.
These are high level safety features that replace another sibling high level construct: The garbage collector.
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."
