Rustle: Svelte compiler rewritten in Rust
github.com
github.com
That's what has happened to Python (numpy, pandas, scipy etc are all written in C and simply provide an interface in Python), and now it's happening to Javascript as well, with Deno, swc in Rust, Bun in Zig, esbuild in Go, and so on.
I foresee a future where we won't have to deal with slow tooling and can have instantaneous updates once again.
It's generally much better to simply go to a language that still operates at the same or similar level of abstraction but with higher performance. i.e going from Typescript to Kotlin isn't a substantial move from an abstraction level perspective but you no longer consider needing to write the code in C because it's not fast enough. (you might for other reasons, like runtime portability)
Efforts like Numba can alleviate some of the pain of a slow Python, but it turns out it's generally not possible to retroactively fit a JIT compiler onto a language designed not designed to be compiled.
In my experience, once I tried moving my work code to Julia, it became clear to me just how much energy I had spent trying to overcome the performance wall of Python, and I can't imagine going back now.
That's the general picture when trying to overcome Python's performance wall: Sometimes you can use Cython, or Numba, or PyPy or Numpy vectorization, or call into C. But only sometimes, and they each come with their own set of awful restrictions and caveats.
It's such a breath of fresh air to switch to a fast language and just forget all those hacks and workarounds. I get why people just migrate to static languages
8<--------------------------------------------
Lush brings the best of both worlds by wrapping three languages into one: (1) a weakly-typed, garbage-collected, dynamically scoped, interpreted language with a simple Lisp-like syntax, (2) a strongly-typed, lexically-scoped compiled language that uses the same Lisp-like syntax, and (3) the C language, which can be freely mixed with Lush code within a single program, even within a single function. It sounds complicated, but it is not. In fact, Lush is designed to be very simple to learn and easy to use.
8<--------------------------------------------
The language is secondary to the platform.
Having fast libraries is great. No one ever wishes that numpy was written in python.
And switching from typescript to kotlin? That's changing platforms. If you're in the browser or in node and replace it with the JVM? That's a wild suggestion to avoid some fast libraries.
Imo you're just wrong.
However, I do wonder if for javascript/typescript that's only for 'in browser' stuff.
If you look at the server - one of the best platforms is the JVM - lots of quality libraries - easy to write stable long running processes etc.
ie if you are driven by platform isn't it Javascript on the browser and Java on the JVM on the back? ( typescript or kotlin are both moving a bit away from the platform ).
The beauty of the network ( message passing ) means the stuff on the server doesn't need to be in the same language as that on the client.
Now I'll admit there is some benefit to having front and backend the same, in terms of validation code, or perhaps occassionally moving logic from server to client or back - but does this override the platform effect? Also note you can run js on the JVM/GraalVM - so client/server validation libraries could be written in js and reused both sides.
My entire career has been with scripting languages, but I think the pendulum is swinging again and they are back on notice.
Anything that isn't strictly a scripting need is orders of magnitude more ergonomic to do in a compiled language than it was a decade ago. Why fight it?
I'm still watching the developments of WASM closely, because while JS does the trick and always will, if you can build an app in a language that produces an equal or better result in WASM, why wouldn't you consider it from an engineering point of view? Then there would no longer be a language split.
There's a lot of "ifs" here for sure, but the possibility exists that the languages we currently use are not the best for the task. I think when we see projects like this, it's a good opportunity to reflect.
But those tools are then in written in statically typed langs that do not have such fast dev flows (as they have an extra step: edit-COMPILE-run-check).
I wonder how we can have the best of both worlds. I see a glimpse of this using Kotlin: I can use the JVM to run in debug mode and have very fast compile times due to incremental builds and hot code reloads), then I can compile the code to "native" (binary) for production scenarios.
This way we can have strong type guarantees AND fast dev flows.
I do not mind to never touch JS again, ever. I'm not in the business of keeping JS devs happy :)
One could say JSX/TS/TSX are compiled langs too...
Plenty of Lisps and Schemes are compiled (though often to bytecode) and can typically dynamically replace parts of the program.
I think ability to hot upgrade seamlessly is more a statement of "how much of the data structure shape is carried at runtime" / "how likely it is old and new API data structures happen to interoperate", and how likely it is that one can convert old runtime state to new runtime state. And that one can be seen as a trade-off; close to the metal control over memory layout is a performance gain, but in practice trades off this kind of flexibility (in theory you could make it work, but it's probably a lot of work).
https://www.theseus-os.com/ is an experimental kernel that can restart/reload/upgrade Rust components at ELF library boundaries. (State internal to a component has to be discarded unless you program a converter. Then again most JS web development hot reload discards internal state of a component.)
Where in strongly typed langs you typically dont.
In your linked article they claim that parts of key JS infra is being rewritten in Rust, but the claim seems exaggerated from where I sit. For instance, they list webpack but is that a good example of huge momentum to rewrite webpack in rust?
You Python examples are of libraries that are used at runtime, not infrastructure.
Coming back to JS, this svelte project is noted by the author as being very early stage and it seems more like a learning project for them. I don’t need to add that svelte isn’t nearly as broadly used as other JS tech.
Don’t get me wrong, I’m not saying writing tools in faster compiled languages shouldn’t be done, but one might find that the excitement and prediction seems premature. There are trade offs - speed isn’t free.
Yes, see swc and esbuild (in Go) for examples. They are taking off in the JS world such that many other frameworks are eschewing Webpack and wrapping them due to their sheer speed, like NextJS with swc and Vite with esbuild.
> libraries that are used at runtime, not infrastructure
Sure, I was just giving an example. I would say though that due to JS being interpreted (okay, JITed), the infrastructure would have to run Webpack anyway, in order to bundle/compile the JS.
> this svelte project is noted by the author as being very early stage and it seems more like a learning project for them
I'm not talking about this project in particular, just the JS ecosystem as a whole is trending towards compiled-language tooling. But I will say though that this trend is not early stage as the examples above like swc/esbuild have been some years in the making. If anything this will simply accelerate such progress.
You quote Python examples around data processing (an appropriate niche use-case for perf-oriented implementations), but then your final line is actually about build tooling.
The problem here is that things like esbuild are written to support dysfunction. Javascript-written build tooling build "reasonable" projects very fast. The dependency bloat in the NPM ecosystem is well-documented, and the actual level abstraction complexity of apps/frameworks/projects is also commonly considered to be excessive. This leads to slow builds, slow apps, and low maintainability/debuggability. Solving the first of those problems in isolation "supports dysfunction" in that it makes the latter problems less likely to be solved. It's especially bad when that solution comes with further maintainability/debuggability compromises.
Performance generally increases in priority depending on how much of a bottleneck it is. If webpack takes 0.2 seconds and esbuild would take 0.02 seconds, that's a 10x perf. gain but is probably not a compelling reason to switch. If webpack is taking 20 seconds however, that's a bottleneck that's worth looking at.
My point above is that an app that takes 20 seconds for webpack to build is overengineered in the most common cases - taking that badly written app and running it through esbuild to "fix" your problem isn't really fixing your problem, it's just hiding it under the bed. This is what's called "supporting dysfunction".
Numpy, pandas, scipy are poor comparators because they're processing data, not code: they're tasks that depend on data scale, rather than on how many over-abstracted layers of code someone is trying to compile all at once. The former is not (necessarily) a sign of dysfunction. It's much more likely to be a valid use-case.
I also maintain a large app in SolidJS. I like SolidJS even more than Svelte, especially for large projects but also for small projects.
Svelte has some disadvantages with tooling & some issues with Typescript integration. SolidJS allows more function decomposition & general flexibility in creating smaller more focused components, since the jsx/tsx components are plain old javascript functions. In addition, SolidJS javascript output is smaller than Svelte when the app hits a fairly low level of complexity. The engineering of SolidJS is more accessible than Svelte, so it's easier to understand what is going on.
> This project sounds awesome, and I'm sure we'll be able to learn a lot from it. Just a heads up that we will likely be making substantial changes to the compiler for Svelte 4, resulting in very different output JavaScript — thought I should mention that in case it affects your plans!
https://www.reddit.com/r/rust/comments/wlmzx1/rewriting_the_...
How does a rewrite in rust make using deno easier?
Ryan Dahl - author of both Node and Deno (will the next version be "Done"?):
One of Deno's strengths is Rust
My vote would be for "Endo".
Having the compiler not depend on NodeJS would mean you could live in either (Deno+Rust) or (Deno+WASM) ecosystems fully.
95% should be already there (maybe this does that? https://github.com/wuyudi/svelte-swc)
The interesting thing here is really the reaction from the HN community, not the incomplete implementation.
Having said that, this is a brilliant project.
Eventually it pans out and gets replaced by something else.
I would also add that rewriting something that exists in a new language is both a brilliant way to learn that language but also, if the language is still evolving, feed back improvements to the language itself.
What did I miss this time? Would you please elaborate?!
I think it will be successful despite that, because we've seen this happen before in other ecosystems... e.g. Scala was a large step away from Java, while Kotlin is a much smaller one, and in a way, you could also describe it as a step back from Scala. Yet, despite being younger, Kotlin has already surpassed Scala according to some rankings and has some major projects already (maybe more than Scala) investing heavily on it, like Android and Gradle.
Perhaps, another example is Elm... much simpler than Haskell or PureScript, but it seems to be by far the most popular functional language on the frontend.
Finally, I've written some Zig and definitely didn't feel like I have to debug a lot of segfaults... the tools to avoid that problem are already pretty good (the debug memory allocator is almost as strict as the Rust borrow checker and will keep you on check!) and even having little experience manually managing memory, I was able to get stuff done quite easily (unlike with C which I do find extremely dangerous on my own hands).
I guess in the end should be happier that more Zig and less C gets written.
It isn't there yet, but wait for 40 years industry adoption will make to it.
Now, I'd say they're on the same order of magnitude for simplicity. The huge advantage Rust has is that it tells you when you got it wrong, whereas C++ says "OK, I will put the toast in the fridge."
While Rust is definitely an improvement over C++, it remains to be seen how those 40 years of legacy will look like.
The people behind Jai and Odin have both expressed the opinion that the problems Rust prevents are not important. I would tend the pigeonhole this as "Real programmer" macho bullshit, especially from Jonathan, but I could be wrong of course.
(It's me, I dislike frontend frameworks and node and like svelte)
But since it's web-dev related and rust-dev related it deserves the front page on Hacker News...
Definitely starring.
(If it does not require pulling 1GB of Rust dependencies including the Rust compiler of course.)
A Svelte compiler in Rust might be a very interesting code base to work on / to study.
WYM? Svelte does not have dependencies https://www.npmjs.com/package/svelte
{#each 'SVELTE' as char, i}.. seriously !
Svelte is the biggest scam of all, reinventing the wheel all the way.
It's also not exactly new, from 2016.
I hear you about the JS frontend framework and tooling churn, but Svelte actually brings something new and valuable.
Usually, you do minimal transpilation when you create, say, a React app - limited to converting JSX to React.createElement calls, plus bundling and tree shaking (if possible). That means all of the work needs to be done at runtime, and React needs to keep track of a VDOM, where any changes can be made at any time, and there needs to be generic runtime infrastructure in place to handle that (diffing and reconciliation).
Additionally, each render completely reconstructs its slice of the VDOM, just to be diffed, leading to many wasted objects and CPU cycles even if nothing's changed.
Svelte is a different approach which sees the inefficiency in that and tries to implement an alternative. Sure, it's "new and shiny" (even though it's been over 6 years since 1.0), but it has some real benefits!
Svelte works by rewriting your code to make changes directly to the DOM, rather than going through a VDOM, and it does this by keeping track of all the possible changes at compile-time (along with things like event listeners and reactive state and so on) and hard-coding them in.
So instead of getting a generic runtime framework that has to run everything through a VDOM, you get something a bit more similar to what you would have if you wrote the whole thing by hand using vanilla JS with no framework at all.
Svelte has an article on the subject - I'd recommend checking it out: https://svelte.dev/blog/virtual-dom-is-pure-overhead
(Although I do think it's fad-like that Svelte is plastering their site with protest messages, that doesn't mean the technology isn't impressive!)