12 ms·

Rust Is the Future of JavaScript Infrastructure

249 points by leerob 5y ago

lostmsu 5y ago
The state of Rust debugging is atrocious. No expression evaluators work with traits, and their implementations are the majority of all Rust code. Until somebody fixes this, I don't see Rust taking on any mainstream languages.
- tialaramex 5y ago
  Ha. I hadn't even thought about this. In several months of writing Rust I have never once reached for a debugger, but you're right, the debuggers, at least the ones I have, don't understand how to evaluate Traits. Maybe some day I'll write a Rust program that has a bug worth using a debugger on and I'll remember this.
  - lostmsu 5y ago
    Well I hit this on my 2nd week of Rust trying to debug GPT-1 implementation in tch-rs. Sprinkling code with extra variables holding debug values I'd normally put as expressions in IDE Watches and restarting only works until assert violation happens after 5+ mins of program execution.
Zababa 5y ago
> With Rust, developers have more control over memory allocation, without it being as painful as C++ or Go. Memory allocation is painful in Go?
- leerob 5y ago
  That was my takeaway from folks who had moved from Go to Rust. I'm not a Go expert though, so feel free to correct me. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
  - j03b 5y ago
    The takeaways in this article are much more why Go's memory model becomes difficult at scale. When you're dealing with memory at Discord scale garbage collection is hard, for example on the mentioned Discord microservice: > There are millions of Users in each cache. There are tens of millions of Read States in each cache. There are hundreds of thousands of cache updates per second. This is something that is probably never going to be hit locally in the development toolchain. You can certainly prefer the Rust memory system to Go and have that be a valid reason to use Rust over Go for something like dev toolchains, but you're not going to hit scale problems like those mentioned in the article.
    - foota 5y ago
      I don't know, building JavaScript things involves similar orders of magnitude.
    - AaronFriel 5y ago
      Not just at scale, Go doesn't make it obvious when an allocation is on the heap or stack. The escape analysis can change (hopefully without regressions) from version to version of Go, and that can mean performance regressions can happen. It also means small refactors risk de-optimizing code without an obvious reason why that would be the case. I think more engineers are becoming skeptical of optimizing compilers with that sort of implicit, potential "spooky action at a distance" where nonlocal code can cause performance regressions. In Haskell, laziness and iterator fusion can do the same thing. Nonlocal code can cause local expressions to compile differently, resulting in - from an engineer's POV - nondeterministic performance, memory usage, GC pressure. "Space leaks" can also occur, again, due to nonlocal effects. In JavaScript, the JIT can similarly cause local regressions due to nonlocal code. A single expression deep in a call stack mutating an object can result in it no longer fitting an optimized "shape", resulting in function deoptimization. Just say no to spooky action at a distance in programming languages, in my opinion. It leads to tremendously difficult to debug regressions.
      - kgeist 5y ago
        >Not just at scale, Go doesn't make it obvious when an allocation is on the heap or stack. The escape analysis can change I thought heap allocations are only triggered by taking pointers, i.e. using reference semantics (including casting to interface and calling a method whose receiver is by-ref)? If I'm careful to only use variables by-value (for types that can afford it, i.e. excluding map/array), what else can trigger heap allocation?
- mountainriver 5y ago
  Sure when you disable the GC =P
- twic 5y ago
  Perhaps memory allocation is not, but control over memory allocation is. Like most other managed languages, Go trades less control for more ease of use.
- honkycat 5y ago
  There is a lot of pain over garbage collection and tuning that in really high pref cases
- PragmaticPulp 5y ago
  Definitely not painful for simple operations (obviously). But every large Go project I've worked on has eventually invested a lot of time into minimizing allocations, rewriting critical path sections to use pools, and various other techniques to improve performance by taking more control over memory allocation. Go's GC is very good, but it still has limitations. Honestly it's not a bad tradeoff most of the time. Write code that works as quickly as possible, profile it as load scales, and apply further optimization as hot paths are identified. On the other hand, I've been working with Rust long enough that I can almost write the same thing in Rust as fast as I could in Go (Rust is inherently more verbose and requires more cognitive overhead). I've been writing prototypes in Rust more and more lately and haven't really been missing Go as much as I did when I first started with Rust.
  - romero-jk 5y ago
    Sure maybe, but here we are talking about short running CLI applications not long running processes. IMO, Go is better suited at this 'js infrastructure' stuff.
  - Thaxll 5y ago
    When you work at certain scale with C++ and Rust you ends rewriting a GC inside those language because default allocator are not good enough. That's why GC languages are faster than C++/Rust in some scenarios.
    - obviouslynotme 5y ago
      >Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. - Greenspun's tenth rule Joking aside, Java VM can be as fast as C++, not C, by using profiling and JIT optimization if tuned to a specific server and only measuring after running for a while. If you are really thinking about your allocators and not just calling malloc, nothing is faster. Half of this is due to less allocator calls and half is due to laying out the memory in a cache-friendly manner.
leerob 5y ago
Author here. A few other Rust projects to note that I didn't mention in the original post I've since found: - Boa (JS engine in Rust) – https://github.com/boa-dev/boa https://github.com/boa-dev/boa - RSLint (JS/TS linter in Rust) – https://github.com/rslint/rslint https://github.com/rslint/rslint - Node version manager in Rust – https://github.com/Schniz/fnm https://github.com/Schniz/fnm If you know of any other popular ones, let me know. I'm keeping a list :)
- dceddia 5y ago
  I've been using NAPI-RS to bridge from Electron <-> Rust and it's been nice - https://napi.rs/ https://napi.rs/ I believe SWC uses it behind the scenes. They just put out an alpha release that makes it way more ergonomic to write Rust functions that interop with JS, too. There's a small example of it in the README: https://github.com/napi-rs/napi-rs#taste https://github.com/napi-rs/napi-rs#taste NAPI isn't as well-known in the JS-to-Rust bindings world (Neon is the more well-known library, https://neon-bindings.com/ https://neon-bindings.com/) but it seems to be gaining steam.
  - leerob 5y ago
    Ah yes, how could I forget! NAPI-RS is very, very slick.
- cjpearson 5y ago
  Volta is also written in Rust. I've only used it for managing Node and npm versions, but it can do more than that and describes itself as a "tool manager" rather than a node version manager. https://docs.volta.sh/guide/ https://docs.volta.sh/guide/
- leerob 5y ago
  Another one: Electron alternative Tauri written in Rust – https://news.ycombinator.com/item?id=26194990 https://news.ycombinator.com/item?id=26194990
- jbbe 5y ago
  fnm was a game changer for me, it is significantly quicker than nvm. It was mentioned in the article but swc as an alternative typescript compiler has really sped up builds.
nickcw 5y ago
Go is active in this space too, esbuild is a very fast JavaScript bundler - https://github.com/evanw/esbuild https://github.com/evanw/esbuild
- onox 5y ago
  Recently I've used ReScript + esbuild for a completely webpack-free experience with just a small node_modules folder
  - toastercat 5y ago
    The more popular this kind of setup gets, the better. I've also vastly simplified a lot of my projects with just esbuild as the sole dev dependency.
    - merb 5y ago
      our webpack based build took 70000ms (70s) to finished with a cached built. it only took 5s in esbuild (esbuild has no cache... or at least i don't know it yet).
davnicwil 5y ago
I really like how javascript tooling appears to have followed the make it work -> make it good -> make it fast pattern, which is pretty much always the correct way to build software. It is reassuring that we have actually got the feature sets and interfaces correct, since we are now, at last, turning to making stuff really fast. If we had started with speed being the goal of tools, I'd wager they would have been nowhere near the standard they are today in those regards.
- jakequade 5y ago
  I like how you've followed the delusional -> delusional pattern.
- c7DJTLrn 5y ago
  >make it good Wait, when did that happen?
  - layer8 5y ago
    Even "make it work" is debatable.
  - te_chris 5y ago
    This got a genuine laugh from me. Stockholm syndrome is a prerequisite for writing JS
  - Already__Taken 5y ago
    to be fair they didn't say it has completed the progression through that program.
  - zeroxfe 5y ago
    I'd say when ES6 landed. I used to hate JS, but since ES6, I think it's a pretty good language for building frontends.
    - LordDragonfang 5y ago
      ES6 is indeed pretty good, all things considered, but GP specified javascript tooling, which, uh, could still use some work before it's considered truly "good".
blondin 5y ago
yesterday, i recommended "the c programming language" here on HN. and i wanted to see if it's still a number one best seller on amazon. i was quite surprised. "the rust programming language" has taken over "the c programming language" in the "c programming" best sellers mind you! i am getting more and more curious about this language. i have avoided it for a long time because of the inconsistent syntax i have seen in the wild.
- leetrout 5y ago
  The syntax feels more unusual than some others but it isnt so bad once you use it. It still baffles me when i try to understand parts of it in isolation. As with all things it normalizes with exposure.
- worik 5y ago
  > i have avoided it for a long time because of the inconsistent syntax i have seen in the wild. What do you mean?
  - tialaramex 5y ago
    I'm intrigued too. One obvious cause of "inconsistent syntax" would be if you saw any pre-1.0 Rust. Early Rust is a very different animal, it has a different concurrency model, it has a garbage collector, and the syntax is not at all like it is today. Such radical changes would of course be completely unacceptable for an industrial language, and sure enough 1.0 is the end of it.
    - worik 5y ago
      There have been some changes since too. I am hazy, not done as much Rust as I would like I am interested in what the issues are people have had
  - nabakin 5y ago
    I'm wondering about this too.
- 5y ago
deleted 5y ago
[deleted]
tbeseda 5y ago
Nice writeup, Lee. Zig is also pretty interesting for this type of tooling, see https://bun.sh/ https://bun.sh/
- leerob 5y ago
  Thank you! Jarred is doing incredible work, worth following on Twitter too: https://twitter.com/jarredsumner https://twitter.com/jarredsumner
game_the0ry 5y ago
Front end engineer, here. Not very experienced, less than 10 years exp. Dumb question - why do we still need compilers like Babel and SWC to compile our es6 (excluding TS) to...whatever version of js the compiler is targeting? Are browsers still so out of sync with each other that we still need to compile to es5? If yes, wouldn't it be more worthwhile for the front end community, including TC39 and every major browser engine developer (google, apple, mozilla, etc), to focus on the base implementation (engine) so they are no longer so out of sync? The most popular browser are based on open source engines anyway. Don't get me wrong, I am sure there is a good reason for all this rust tooling - faster compilation does not hurt, but it seems inefficient to have an intermediate compiler (Babel / swc/ TS/ etc) that creates deployable code that will eventually be interpreted by the user's JS engine (V8 / webkit / gecko) anyway. A standardized engine seems the way to go and it seems like we are going in that direction with only a handful of JS engines in use today.
- skohan 5y ago
  It seems to me the future is rather in gradually replacing JS engines with a WASM back-end. The whole webpack/babel ecosystem could be replaced by a toolchain which targets WASM, and browsers could ship with a JS engine which just translates es5 to WASM for legacy support. I guess the WASM api is lacking a lot of features which would be required to make this work, but I don't see why it shouldn't be the goal.
  - sroussey 5y ago
    JS is too complex for that. But you can have a look at AssemblyScript.
- RcouF1uZ4gsC 5y ago
  Also, if we are going through a compile step anyway, why not a future for more support for WebAssembly and then we can use other languages instead of JavaScript.
- totaldex 5y ago
  In a perfect world, things would be like you describe. Unfortunately we live in a diverse landscape of browsers and devices, many of which have not been updated in quite some time. Factors ranging from IT policy at older companies, to geographical limitations, may prevent many users from upgrading to the latest and greatest. Some companies choose to cut their losses, and support only certain browsers - these can get away with less compilation and polyfills. Other companies may be targeting these specific segments (such as B2B), and can't get away with such a luxury.
threatofrain 5y ago
Rome is also being rewritten into Rust. https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in-rust https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in...
- bruce343434 5y ago
  Good luck on your rewrite!
steventey 5y ago
Bullish on Rust
caymanjim 5y ago
People tend to write dev tools in the languages they develop in. C compilers written in C, JavaScript minifiers written in JavaScript, etc. There's often no reason to use the same language for the tooling, but you use what you know and like to work with, and if you've got a need for a language-specific tool (like Webpack) you're probably going to start out writing it in the same language. If Rust becomes popular for JavaScript tooling, how long until those developers abandon JavaScript entirely? This isn't necessarily a problem, but it could lead to some, if you can't fix your own tools because you're not conversant in the language. More importantly, if the key toolmakers all switch to Rust and lose interest in JavaScript, the tool authors might lose touch with (or interest in) the problems of the JavaScript community. We all talk about dogfooding, and this is the opposite. Rust seems to have this cult-like power. Rust developers are definitely drinking a lot of Kool-Aid. Maybe if all the JavaScript tools are written in Rust, we'll start seeing Rustscript in the browser.
- Daishiman 5y ago
  > Rust seems to have this cult-like power. Rust developers are definitely drinking a lot of Kool-Aid. Maybe if all the JavaScript tools are written in Rust, we'll start seeing Rustscript in the browser. Rust has tremendous popularity because it solves an enormous class of problems for system programmers and require very few compromises compared to any alternative. The hype is real, but it is very unlikely that another language will compete for this space. Rust doesn't really work well in the niches most impacted by fad-driven-development. Nobody is claiming you should do web dev in Rust nor consider it comparable to much better languages for that space.
  - pjmlp 5y ago
    Except web development isn't systems programming.
    - cema 5y ago
      Not _except_ but _because_.
- 5y ago
skohan 5y ago
I agree that wasm should be the future of web, but to be honest I'm not sure rust is the best candidate to replace JS from the developer perspective. For one thing, Rust is slow to compile. I built a simple one-page app in rust/wasm to kick the tires, and it was much slower from a developer perspective than for instance a react/ts app. Even with hot reloading set up, it took noticeably longer for the rust app to refresh after hitting the save button. Also rust is fairly demanding on the programmer. Right now there are an army of js programmers keeping the web running. To be perfectly honest, I don't think there is sufficient supply of programmers in the world with the aptitude to replace all those js programmers with rust programmers. Due to the sheer scale of the web, front-end programming has to be fairly easy for things to keep moving at the pace which they are. I hope wasm does supplant js as the main deployment target for web development. But I think it will have to be a much simpler language than rust which is the one targeting wasm.
- rektide 5y ago
  > I agree that wasm should be the future of web, but to be honest I'm not sure rust is the best candidate to replace JS from the developer perspective. Rust & wasm don't replace JS, in my view. They're there to create good libraries & frameworks for the scripting languages to consume & use, at many times. There will definitely be some Rust entering the scene, but I tend to think Rust & other wasms will not be the entire web app, but be used for engineering the better crafted, more re-usable bits. Wasms success, imo, is ultimately gated on how well it's host-object bindings work. Wasm doesn't really yet play well with JS. Rust has a fairly unique edge right now in that Rust pioneered their own wasm<->js foreign interfacing, via wasm-bindgen, then generated a web-sys crate with all the web foreign objects already defined in it, allowing Rust far better inter-operation. Because host-object binding/ interface types/ &c are still in-progress, there's much less ability to experiment with what pieces of the webapp make sense to keep in JS, and what pieces make sense to go engineer in wasm. We'll see more interesting blends, with more webdevs writing JS, but consuming/authoring against Wasm tools, as we start to emerge a real wasm ABI.
cairo140 5y ago
I've worked in JS for around 12 years now and welcome this change of keeping JS as a scripting language but incrementally retiring it for performance-intensive general-purpose applications. To my eye, JavaScript has three applications: * A GUI-building language: A language and ecosystem we use to build UIs, where code runs on the end user's machine, served over the Web or as desktop applications using a compatible API (e.g. Electron). * A scripting language: An approachable high-level C-like language. * A general purpose programming language: A server-side or developer machine-side programming language for computational tasks like linking dependencies, transpiling code, type checking, orchestrating tasks. At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord. At the second, performance doesn't matter anyway, so making JS capable of this just makes it approachable for folks who learned the language for the GUI-building purpose. It's at the third application that the fundamental limitations of JavaScript---the programming language---really show. These are things like the lack of true multithreading (technically possible with significant limitations around shared memory and messaging and high overhead with Web Workers), lack of low-level primitives to fine-tune performance, and the ease with which authors can accidentally write extremely slow code. So much of this (TypeScript compilation, NPM package resolution/linking, Webpack bundling) in the modern Web ecosystem is regrettably still done in mostly JS. I hope the JS community rallies around one general-purpose language to offload these tasks to as well as a uniform shim layer like Ruby's C extensions so we don't end up with a chaotic mishmash of different technologies. If nothing else, it would be nice to have a good excuse to write not-JS every once in a while!
- xboxnolifes 5y ago
  > At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord. I don't really think this is attributed to JS in any way besides it being the only browser language. Desktop apps use JS because they are browsers, not necessarily because JS was the best language option. An ecosystem has developed around it not because it's good, but because there is no other option for working in a browser.
  - 5y ago
cosmotic 5y ago
The use of the word 'modern' is inappropriate in these sorts of articles. > It's a modern replacement for languages like C++ or C with a focus on code safety and concise syntax. Instead: "It's a replacement..." > Babel: developers wanted to write modern JavaScript while supporting older browsers. Instead: "developers want to write with new versions of Javascript..." > Deno, created in 2018, is a simple, modern, and secure runtime for JavaScript and TypeScript that uses V8 and is built with Rust. Instead: "Deno, created in 2018, is a runtime for JavaScript and TypeScript that uses V8 and is built with Rust, with a focus on Security." > WebAssembly (WASM) is a portable low-level language that Rust can compile to. It runs in the browser, is interoperable with JavaScript, and is supported in all major modern browsers. Instead: "all major browsers."
- lifthrasiir 5y ago
  It's futile, from the history we can expect that the next major generation of browsers would be called postmodern browsers, and next one would be post-postmodern browsers.
  - bqmjjx0kac 5y ago
    I only use Pre-Raphaelite browsers.
- VWWHFSfQ 5y ago
  now this is the kind of pedantry i come to hn for
gigel82 5y ago
I doubt that; for the foreseeable future, the future of JavaScript infrastructure will likely continue to be TypeScript and C++. deno is too opinionated to absorb a significant number of node.js developers that just want to get stuff done. Sure, there will be tools written in Rust (because it's the new sexy thing) just like there were tools written in Go (when it was the "new sexy thing"), but it's not going to take over the ecosystem any time soon.
- pjmlp 5y ago
  Agreed, many people enjoy writing bindings and creating tools, however the large majority will just pick what is supported out of the box and carry on with their actual work.
coliveira 5y ago
Rust probably will have its place, but it is useless to assume that it will oust code that is already used and trusted. Even the people at Firefox figured out that it would be near impossible to replace their C++ infrastructure to use something unproven. I guess rust advocates would have an easier time creating something new and successful rather than preaching that people should throw their code in the garbage just to rewrite it in the language of the day.
- sophacles 5y ago
  I guess reading the article isn't necessary to make comments anymore!
vzaliva 5y ago
Picking a random example from the article: "Deno’s linter, code formatter, and docs generator". Why you need to write a tool like this in low-level system language like Rust? And please, do not answer "performance" because: a) it is not critical for tool like this b) many other high-level modern languages for this type of project will give performance only marginally inferior to low-lewel implementation in Rust or C.
- VWWHFSfQ 5y ago
  what should it be written in
  - bruce343434 5y ago
    Javascript
    - deleted 5y ago
      [deleted]
  - pjmlp 5y ago
    Any AOT compiled language would do, nothing special about Rust magic dust.
- nicoburns 5y ago
  JavaScript linters and more specifically the TypeScript type checker are one of things that slow my computer down the most at work. Probably doesn’t help that I have 7 projects open at once, but that’s the nature of working a micro services based code based. Performance absolutely matters for this kind of code. Many other high levels languages might give you the performance you need, but JavaScript won’t, and not many languages are as nice to use as Rust. So if you have to do it in another language then it’s a good pick.
- Asraelite 5y ago
  I use Rust for a lot of things where performance is completely irrelevant. It has a lot of nice features and benefits other than memory safety and performance.
codethief 5y ago
It's been 16 or 17 years since I wrote my first line of JavaScript and I still hate the language and almost everything that comes with it. The language is still arcane, even if or sometimes even more so if you use TypeScript; browser incompatibilities are still prevalent (though not as ugly as they used to be); and even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/… by people who, as it turns out, don't have a clue any more than you do, until you finally come across that one open Github issue that explains (and confirms) all the reasons for your frustration. What's more, people are adding more magic and opaqueness to their build pipelines every day. There's not one linker ("bundler", "loader") and one compiler/transpiler, no, there are several. And depending on the bundler, loaders, compiler and transpiler and the target platform, some things like imports might work in completely different ways. (If you thought getting imports right in Python was difficult, good luck with JS.) Of course, these often happen to be precisely the things that are not well documented at all. I'm not sure what the point of my post is, other than to vent. I guess sometimes I just wish we would get rid of JavaScript entirely and switch to a sane language with sane build tools.
- ostenning 5y ago
  Your frustrations are felt by many. Every tool is attempting to dethrone the competition, coming up with yet another way to do the same simple yet infinitely elusive fucking goal: render a website. The whole ecosystem is fucked
- ASalazarMX 5y ago
  JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all. Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets: > "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’" > "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'" https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...
buzzwords 5y ago
Reading some of the comments here has really made me feel better. I felt like I was the only one that felt JS ecosystem is just bad and painful to work with. Thanks everyone.
forty 5y ago
> The Rust version probably could be made to work at an equivalent speed with enough effort. But at a high level, Go was much more enjoyable to work with. Wow. I always thought Go was a language for depressed (or depressing? :)) devs ;) . I mean, it's boring _by design_. On the other hand Rust is really a cool language, with many things that are designed cleverly, and really enjoyable to use. Well, to me, at least, as it seems some people like boring more :)
- jacquesm 5y ago
  In IT boring is good. It translates into stable, long term support, no breaking changes and having a life. Exciting on the other hand does not have any of those.
  - forty 5y ago
    I agree with that. I'm not saying boring is bad. It's just that I find it weird to choose Go because it's enjoyable ^^
forty 5y ago
I'd love to build my stuff faster (of course), I tried SWC and it seems impressive. But as long as it doesn't include a TS compiler that check types, I'm not exactly sure where/how I would use it. Both locally and in my CI I want my types checked, otherwise I wouldn't bother writing them.
amelius 5y ago
Rust is good for systems programming. For everything else, use a language with GC so you don't have to reinvent the wheel for every memory allocation and your brain is free to think about functionality, architecture, security, UX, ...
- pjmlp 5y ago
  Indeed, something like having a micro-kernel or composition engine written in Rust, everything else on top should just use a language with any kind of automatic memory management and value types support.
jchw 5y ago
Nitpick: There are a ton of programming languages in use at Facebook, Amazon, Apple, Microsoft and Google. Maybe a hundred amongst them! The fact that Rust is even being considered by as many large slow-moving companies is, indeed, impressive. But the way it’s being phrased makes it sound like it is in production everywhere, and I think the truth is the most substantial amount of Rust code in production is probably from Mozilla and maybe Amazon. In many cases, the amount of Rust code is likely very small, isolated for now, and not necessarily in production code yet. Go has also gained an impressive portfolio, too, so Rust doesn’t stand alone. Personally, I suspect Zig will be following on some day. My personal opinion is that all we can conclude today is that JavaScript is not the future of JavaScript infrastructure. However, I am somewhat unconvinced that Rust’s strengths are conclusively important enough to offset the added complexity in all use cases. In production where you might have cases where every cycle and byte counts and where a race condition or memory bug could come at a dire cost, Rust is an obvious winner. On a developer’s computer that is running mostly idle and running dev tools that are mostly embarrassingly parallel with little shared state, it’s just not so clear. Which is why I feel putting the Discord pull quote about their Rust migration underneath the testimony of evan regarding esbuild is a little bit misleading. I am still very bullish on Rust, but when honeymoon periods end, the truth comes out, and in Rust my opinion is that the language is pretty complex, the build times need a lot of work, and the ecosystem has some pretty difficult to ignore weaknesses (I reasonably frequently run into packages that are incomplete, and the dependency trees in Rust projects seem to get as unwieldy as smaller JS/npm projects!) Don’t get me wrong. Go and Zig, as two promising other languages, are obviously not competing with Rust directly. What Rust offers is fairly unique even for a memory safe language. Also, Go’s lack of sum types and pattern matching hits me harder than its verbose error handling or lack of generics. But many people, seeing the borrow checker in action, seem to conclude that it is the future, and that everything else is obsoleted by its existence. Disagree. I think all of these languages are formidable opponents and worthwhile improvements over older languages that people are migrating from. But the thing about zero cost abstractions is that they are a misnomer. They have zero cost at runtime. They have non-zero cost at compile time, they have non-zero costs on cognitive overhead, they have non-zero costs on language design… and once you acknowledge this, it’s only fair to recognize that there are cases where it’s not the trade-off you want. Still, I hope to see more adoption of what I’ll call “next generation” programming languages. Be it Rust, Zig, Go, Pony, Nim… there really is a lot promising on the horizon, stuff that will be well worth the “RiiR” costs in the long-term. I have a feeling many of them will find a place and wind up complementing each other as options you can choose for differing tastes and goals. I am very interested to see which programming language ultimately wins for JS toolchains because it might tell us a lot about just how versatile Rust’s tradeoffs are or aren’t. For now, I am happy enough with esbuild, and looking out into the future to see what’s next.
jacquesm 5y ago
It probably isn't. Simply because JavaScript has a low barrier to entry and Rust has a high barrier to entry. It would be a bit like saying LISP or Erlang are the future of BASIC or PHP.
dzonga 5y ago
as someone who has decent experience with frontend, I believe the future we will be treating JS as a assembly language. However, for that to happen we need a lua like language for js with inferred types. and for apps the will be rendered by wasm in a canvas like interface.

249 points by leerob 5y ago

The state of Rust debugging is atrocious. No expression evaluators work with traits, and their implementations are the majority of all Rust code. Until somebody fixes this, I don't see Rust taking on any mainstream languages.

tialaramex 5y ago
Ha. I hadn't even thought about this. In several months of writing Rust I have never once reached for a debugger, but you're right, the debuggers, at least the ones I have, don't understand how to evaluate Traits. Maybe some day I'll write a Rust program that has a bug worth using a debugger on and I'll remember this.
- lostmsu 5y ago
  Well I hit this on my 2nd week of Rust trying to debug GPT-1 implementation in tch-rs. Sprinkling code with extra variables holding debug values I'd normally put as expressions in IDE Watches and restarting only works until assert violation happens after 5+ mins of program execution.

Zababa 5y ago

> With Rust, developers have more control over memory allocation, without it being as painful as C++ or Go. Memory allocation is painful in Go?

leerob 5y ago
That was my takeaway from folks who had moved from Go to Rust. I'm not a Go expert though, so feel free to correct me. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- j03b 5y ago
  The takeaways in this article are much more why Go's memory model becomes difficult at scale. When you're dealing with memory at Discord scale garbage collection is hard, for example on the mentioned Discord microservice: > There are millions of Users in each cache. There are tens of millions of Read States in each cache. There are hundreds of thousands of cache updates per second. This is something that is probably never going to be hit locally in the development toolchain. You can certainly prefer the Rust memory system to Go and have that be a valid reason to use Rust over Go for something like dev toolchains, but you're not going to hit scale problems like those mentioned in the article.
  - foota 5y ago
    I don't know, building JavaScript things involves similar orders of magnitude.
  - AaronFriel 5y ago
    Not just at scale, Go doesn't make it obvious when an allocation is on the heap or stack. The escape analysis can change (hopefully without regressions) from version to version of Go, and that can mean performance regressions can happen. It also means small refactors risk de-optimizing code without an obvious reason why that would be the case. I think more engineers are becoming skeptical of optimizing compilers with that sort of implicit, potential "spooky action at a distance" where nonlocal code can cause performance regressions. In Haskell, laziness and iterator fusion can do the same thing. Nonlocal code can cause local expressions to compile differently, resulting in - from an engineer's POV - nondeterministic performance, memory usage, GC pressure. "Space leaks" can also occur, again, due to nonlocal effects. In JavaScript, the JIT can similarly cause local regressions due to nonlocal code. A single expression deep in a call stack mutating an object can result in it no longer fitting an optimized "shape", resulting in function deoptimization. Just say no to spooky action at a distance in programming languages, in my opinion. It leads to tremendously difficult to debug regressions.
    - kgeist 5y ago
      >Not just at scale, Go doesn't make it obvious when an allocation is on the heap or stack. The escape analysis can change I thought heap allocations are only triggered by taking pointers, i.e. using reference semantics (including casting to interface and calling a method whose receiver is by-ref)? If I'm careful to only use variables by-value (for types that can afford it, i.e. excluding map/array), what else can trigger heap allocation?
mountainriver 5y ago
Sure when you disable the GC =P
twic 5y ago
Perhaps memory allocation is not, but control over memory allocation is. Like most other managed languages, Go trades less control for more ease of use.
honkycat 5y ago
There is a lot of pain over garbage collection and tuning that in really high pref cases
PragmaticPulp 5y ago
Definitely not painful for simple operations (obviously). But every large Go project I've worked on has eventually invested a lot of time into minimizing allocations, rewriting critical path sections to use pools, and various other techniques to improve performance by taking more control over memory allocation. Go's GC is very good, but it still has limitations. Honestly it's not a bad tradeoff most of the time. Write code that works as quickly as possible, profile it as load scales, and apply further optimization as hot paths are identified. On the other hand, I've been working with Rust long enough that I can almost write the same thing in Rust as fast as I could in Go (Rust is inherently more verbose and requires more cognitive overhead). I've been writing prototypes in Rust more and more lately and haven't really been missing Go as much as I did when I first started with Rust.
- romero-jk 5y ago
  Sure maybe, but here we are talking about short running CLI applications not long running processes. IMO, Go is better suited at this 'js infrastructure' stuff.
- Thaxll 5y ago
  When you work at certain scale with C++ and Rust you ends rewriting a GC inside those language because default allocator are not good enough. That's why GC languages are faster than C++/Rust in some scenarios.
  - obviouslynotme 5y ago
    >Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. - Greenspun's tenth rule Joking aside, Java VM can be as fast as C++, not C, by using profiling and JIT optimization if tuned to a specific server and only measuring after running for a while. If you are really thinking about your allocators and not just calling malloc, nothing is faster. Half of this is due to less allocator calls and half is due to laying out the memory in a cache-friendly manner.

leerob 5y ago

Author here. A few other Rust projects to note that I didn't mention in the original post I've since found: - Boa (JS engine in Rust) – https://github.com/boa-dev/boa https://github.com/boa-dev/boa - RSLint (JS/TS linter in Rust) – https://github.com/rslint/rslint https://github.com/rslint/rslint - Node version manager in Rust – https://github.com/Schniz/fnm https://github.com/Schniz/fnm If you know of any other popular ones, let me know. I'm keeping a list :)

dceddia 5y ago
I've been using NAPI-RS to bridge from Electron <-> Rust and it's been nice - https://napi.rs/ https://napi.rs/ I believe SWC uses it behind the scenes. They just put out an alpha release that makes it way more ergonomic to write Rust functions that interop with JS, too. There's a small example of it in the README: https://github.com/napi-rs/napi-rs#taste https://github.com/napi-rs/napi-rs#taste NAPI isn't as well-known in the JS-to-Rust bindings world (Neon is the more well-known library, https://neon-bindings.com/ https://neon-bindings.com/) but it seems to be gaining steam.
- leerob 5y ago
  Ah yes, how could I forget! NAPI-RS is very, very slick.
cjpearson 5y ago
Volta is also written in Rust. I've only used it for managing Node and npm versions, but it can do more than that and describes itself as a "tool manager" rather than a node version manager. https://docs.volta.sh/guide/ https://docs.volta.sh/guide/
leerob 5y ago
Another one: Electron alternative Tauri written in Rust – https://news.ycombinator.com/item?id=26194990 https://news.ycombinator.com/item?id=26194990
jbbe 5y ago
fnm was a game changer for me, it is significantly quicker than nvm. It was mentioned in the article but swc as an alternative typescript compiler has really sped up builds.

nickcw 5y ago

Go is active in this space too, esbuild is a very fast JavaScript bundler - https://github.com/evanw/esbuild https://github.com/evanw/esbuild

onox 5y ago
Recently I've used ReScript + esbuild for a completely webpack-free experience with just a small node_modules folder
- toastercat 5y ago
  The more popular this kind of setup gets, the better. I've also vastly simplified a lot of my projects with just esbuild as the sole dev dependency.
  - merb 5y ago
    our webpack based build took 70000ms (70s) to finished with a cached built. it only took 5s in esbuild (esbuild has no cache... or at least i don't know it yet).

davnicwil 5y ago

I really like how javascript tooling appears to have followed the make it work -> make it good -> make it fast pattern, which is pretty much always the correct way to build software. It is reassuring that we have actually got the feature sets and interfaces correct, since we are now, at last, turning to making stuff really fast. If we had started with speed being the goal of tools, I'd wager they would have been nowhere near the standard they are today in those regards.

jakequade 5y ago
I like how you've followed the delusional -> delusional pattern.
c7DJTLrn 5y ago
>make it good Wait, when did that happen?
- layer8 5y ago
  Even "make it work" is debatable.
- te_chris 5y ago
  This got a genuine laugh from me. Stockholm syndrome is a prerequisite for writing JS
- Already__Taken 5y ago
  to be fair they didn't say it has completed the progression through that program.
- zeroxfe 5y ago
  I'd say when ES6 landed. I used to hate JS, but since ES6, I think it's a pretty good language for building frontends.
  - LordDragonfang 5y ago
    ES6 is indeed pretty good, all things considered, but GP specified javascript tooling, which, uh, could still use some work before it's considered truly "good".

blondin 5y ago

yesterday, i recommended "the c programming language" here on HN. and i wanted to see if it's still a number one best seller on amazon. i was quite surprised. "the rust programming language" has taken over "the c programming language" in the "c programming" best sellers mind you! i am getting more and more curious about this language. i have avoided it for a long time because of the inconsistent syntax i have seen in the wild.

leetrout 5y ago
The syntax feels more unusual than some others but it isnt so bad once you use it. It still baffles me when i try to understand parts of it in isolation. As with all things it normalizes with exposure.
worik 5y ago
> i have avoided it for a long time because of the inconsistent syntax i have seen in the wild. What do you mean?
- tialaramex 5y ago
  I'm intrigued too. One obvious cause of "inconsistent syntax" would be if you saw any pre-1.0 Rust. Early Rust is a very different animal, it has a different concurrency model, it has a garbage collector, and the syntax is not at all like it is today. Such radical changes would of course be completely unacceptable for an industrial language, and sure enough 1.0 is the end of it.
  - worik 5y ago
    There have been some changes since too. I am hazy, not done as much Rust as I would like I am interested in what the issues are people have had
- nabakin 5y ago
  I'm wondering about this too.
5y ago

deleted 5y ago

[deleted]

tbeseda 5y ago

Nice writeup, Lee. Zig is also pretty interesting for this type of tooling, see https://bun.sh/ https://bun.sh/

leerob 5y ago
Thank you! Jarred is doing incredible work, worth following on Twitter too: https://twitter.com/jarredsumner https://twitter.com/jarredsumner

game_the0ry 5y ago

Front end engineer, here. Not very experienced, less than 10 years exp. Dumb question - why do we still need compilers like Babel and SWC to compile our es6 (excluding TS) to...whatever version of js the compiler is targeting? Are browsers still so out of sync with each other that we still need to compile to es5? If yes, wouldn't it be more worthwhile for the front end community, including TC39 and every major browser engine developer (google, apple, mozilla, etc), to focus on the base implementation (engine) so they are no longer so out of sync? The most popular browser are based on open source engines anyway. Don't get me wrong, I am sure there is a good reason for all this rust tooling - faster compilation does not hurt, but it seems inefficient to have an intermediate compiler (Babel / swc/ TS/ etc) that creates deployable code that will eventually be interpreted by the user's JS engine (V8 / webkit / gecko) anyway. A standardized engine seems the way to go and it seems like we are going in that direction with only a handful of JS engines in use today.

skohan 5y ago
It seems to me the future is rather in gradually replacing JS engines with a WASM back-end. The whole webpack/babel ecosystem could be replaced by a toolchain which targets WASM, and browsers could ship with a JS engine which just translates es5 to WASM for legacy support. I guess the WASM api is lacking a lot of features which would be required to make this work, but I don't see why it shouldn't be the goal.
- sroussey 5y ago
  JS is too complex for that. But you can have a look at AssemblyScript.
RcouF1uZ4gsC 5y ago
Also, if we are going through a compile step anyway, why not a future for more support for WebAssembly and then we can use other languages instead of JavaScript.
totaldex 5y ago
In a perfect world, things would be like you describe. Unfortunately we live in a diverse landscape of browsers and devices, many of which have not been updated in quite some time. Factors ranging from IT policy at older companies, to geographical limitations, may prevent many users from upgrading to the latest and greatest. Some companies choose to cut their losses, and support only certain browsers - these can get away with less compilation and polyfills. Other companies may be targeting these specific segments (such as B2B), and can't get away with such a luxury.

threatofrain 5y ago

Rome is also being rewritten into Rust. https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in-rust https://rome.tools/blog/2021/09/21/rome-will-be-rewritten-in...

bruce343434 5y ago
Good luck on your rewrite!

steventey 5y ago

Bullish on Rust

caymanjim 5y ago

People tend to write dev tools in the languages they develop in. C compilers written in C, JavaScript minifiers written in JavaScript, etc. There's often no reason to use the same language for the tooling, but you use what you know and like to work with, and if you've got a need for a language-specific tool (like Webpack) you're probably going to start out writing it in the same language. If Rust becomes popular for JavaScript tooling, how long until those developers abandon JavaScript entirely? This isn't necessarily a problem, but it could lead to some, if you can't fix your own tools because you're not conversant in the language. More importantly, if the key toolmakers all switch to Rust and lose interest in JavaScript, the tool authors might lose touch with (or interest in) the problems of the JavaScript community. We all talk about dogfooding, and this is the opposite. Rust seems to have this cult-like power. Rust developers are definitely drinking a lot of Kool-Aid. Maybe if all the JavaScript tools are written in Rust, we'll start seeing Rustscript in the browser.

Daishiman 5y ago
> Rust seems to have this cult-like power. Rust developers are definitely drinking a lot of Kool-Aid. Maybe if all the JavaScript tools are written in Rust, we'll start seeing Rustscript in the browser. Rust has tremendous popularity because it solves an enormous class of problems for system programmers and require very few compromises compared to any alternative. The hype is real, but it is very unlikely that another language will compete for this space. Rust doesn't really work well in the niches most impacted by fad-driven-development. Nobody is claiming you should do web dev in Rust nor consider it comparable to much better languages for that space.
- pjmlp 5y ago
  Except web development isn't systems programming.
  - cema 5y ago
    Not _except_ but _because_.
5y ago

skohan 5y ago

I agree that wasm should be the future of web, but to be honest I'm not sure rust is the best candidate to replace JS from the developer perspective. For one thing, Rust is slow to compile. I built a simple one-page app in rust/wasm to kick the tires, and it was much slower from a developer perspective than for instance a react/ts app. Even with hot reloading set up, it took noticeably longer for the rust app to refresh after hitting the save button. Also rust is fairly demanding on the programmer. Right now there are an army of js programmers keeping the web running. To be perfectly honest, I don't think there is sufficient supply of programmers in the world with the aptitude to replace all those js programmers with rust programmers. Due to the sheer scale of the web, front-end programming has to be fairly easy for things to keep moving at the pace which they are. I hope wasm does supplant js as the main deployment target for web development. But I think it will have to be a much simpler language than rust which is the one targeting wasm.

rektide 5y ago
> I agree that wasm should be the future of web, but to be honest I'm not sure rust is the best candidate to replace JS from the developer perspective. Rust & wasm don't replace JS, in my view. They're there to create good libraries & frameworks for the scripting languages to consume & use, at many times. There will definitely be some Rust entering the scene, but I tend to think Rust & other wasms will not be the entire web app, but be used for engineering the better crafted, more re-usable bits. Wasms success, imo, is ultimately gated on how well it's host-object bindings work. Wasm doesn't really yet play well with JS. Rust has a fairly unique edge right now in that Rust pioneered their own wasm<->js foreign interfacing, via wasm-bindgen, then generated a web-sys crate with all the web foreign objects already defined in it, allowing Rust far better inter-operation. Because host-object binding/ interface types/ &c are still in-progress, there's much less ability to experiment with what pieces of the webapp make sense to keep in JS, and what pieces make sense to go engineer in wasm. We'll see more interesting blends, with more webdevs writing JS, but consuming/authoring against Wasm tools, as we start to emerge a real wasm ABI.

cairo140 5y ago

I've worked in JS for around 12 years now and welcome this change of keeping JS as a scripting language but incrementally retiring it for performance-intensive general-purpose applications. To my eye, JavaScript has three applications: * A GUI-building language: A language and ecosystem we use to build UIs, where code runs on the end user's machine, served over the Web or as desktop applications using a compatible API (e.g. Electron). * A scripting language: An approachable high-level C-like language. * A general purpose programming language: A server-side or developer machine-side programming language for computational tasks like linking dependencies, transpiling code, type checking, orchestrating tasks. At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord. At the second, performance doesn't matter anyway, so making JS capable of this just makes it approachable for folks who learned the language for the GUI-building purpose. It's at the third application that the fundamental limitations of JavaScript---the programming language---really show. These are things like the lack of true multithreading (technically possible with significant limitations around shared memory and messaging and high overhead with Web Workers), lack of low-level primitives to fine-tune performance, and the ease with which authors can accidentally write extremely slow code. So much of this (TypeScript compilation, NPM package resolution/linking, Webpack bundling) in the modern Web ecosystem is regrettably still done in mostly JS. I hope the JS community rallies around one general-purpose language to offload these tasks to as well as a uniform shim layer like Ruby's C extensions so we don't end up with a chaotic mishmash of different technologies. If nothing else, it would be nice to have a good excuse to write not-JS every once in a while!

xboxnolifes 5y ago
> At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord. I don't really think this is attributed to JS in any way besides it being the only browser language. Desktop apps use JS because they are browsers, not necessarily because JS was the best language option. An ecosystem has developed around it not because it's good, but because there is no other option for working in a browser.
- 5y ago

cosmotic 5y ago

The use of the word 'modern' is inappropriate in these sorts of articles. > It's a modern replacement for languages like C++ or C with a focus on code safety and concise syntax. Instead: "It's a replacement..." > Babel: developers wanted to write modern JavaScript while supporting older browsers. Instead: "developers want to write with new versions of Javascript..." > Deno, created in 2018, is a simple, modern, and secure runtime for JavaScript and TypeScript that uses V8 and is built with Rust. Instead: "Deno, created in 2018, is a runtime for JavaScript and TypeScript that uses V8 and is built with Rust, with a focus on Security." > WebAssembly (WASM) is a portable low-level language that Rust can compile to. It runs in the browser, is interoperable with JavaScript, and is supported in all major modern browsers. Instead: "all major browsers."

lifthrasiir 5y ago
It's futile, from the history we can expect that the next major generation of browsers would be called postmodern browsers, and next one would be post-postmodern browsers.
- bqmjjx0kac 5y ago
  I only use Pre-Raphaelite browsers.
VWWHFSfQ 5y ago
now this is the kind of pedantry i come to hn for

gigel82 5y ago

I doubt that; for the foreseeable future, the future of JavaScript infrastructure will likely continue to be TypeScript and C++. deno is too opinionated to absorb a significant number of node.js developers that just want to get stuff done. Sure, there will be tools written in Rust (because it's the new sexy thing) just like there were tools written in Go (when it was the "new sexy thing"), but it's not going to take over the ecosystem any time soon.

pjmlp 5y ago
Agreed, many people enjoy writing bindings and creating tools, however the large majority will just pick what is supported out of the box and carry on with their actual work.

coliveira 5y ago

Rust probably will have its place, but it is useless to assume that it will oust code that is already used and trusted. Even the people at Firefox figured out that it would be near impossible to replace their C++ infrastructure to use something unproven. I guess rust advocates would have an easier time creating something new and successful rather than preaching that people should throw their code in the garbage just to rewrite it in the language of the day.

sophacles 5y ago
I guess reading the article isn't necessary to make comments anymore!

vzaliva 5y ago

Picking a random example from the article: "Deno’s linter, code formatter, and docs generator". Why you need to write a tool like this in low-level system language like Rust? And please, do not answer "performance" because: a) it is not critical for tool like this b) many other high-level modern languages for this type of project will give performance only marginally inferior to low-lewel implementation in Rust or C.

VWWHFSfQ 5y ago
what should it be written in
- bruce343434 5y ago
  Javascript
  - deleted 5y ago
    [deleted]
- pjmlp 5y ago
  Any AOT compiled language would do, nothing special about Rust magic dust.
nicoburns 5y ago
JavaScript linters and more specifically the TypeScript type checker are one of things that slow my computer down the most at work. Probably doesn’t help that I have 7 projects open at once, but that’s the nature of working a micro services based code based. Performance absolutely matters for this kind of code. Many other high levels languages might give you the performance you need, but JavaScript won’t, and not many languages are as nice to use as Rust. So if you have to do it in another language then it’s a good pick.
Asraelite 5y ago
I use Rust for a lot of things where performance is completely irrelevant. It has a lot of nice features and benefits other than memory safety and performance.

codethief 5y ago

It's been 16 or 17 years since I wrote my first line of JavaScript and I still hate the language and almost everything that comes with it. The language is still arcane, even if or sometimes even more so if you use TypeScript; browser incompatibilities are still prevalent (though not as ugly as they used to be); and even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/… by people who, as it turns out, don't have a clue any more than you do, until you finally come across that one open Github issue that explains (and confirms) all the reasons for your frustration. What's more, people are adding more magic and opaqueness to their build pipelines every day. There's not one linker ("bundler", "loader") and one compiler/transpiler, no, there are several. And depending on the bundler, loaders, compiler and transpiler and the target platform, some things like imports might work in completely different ways. (If you thought getting imports right in Python was difficult, good luck with JS.) Of course, these often happen to be precisely the things that are not well documented at all. I'm not sure what the point of my post is, other than to vent. I guess sometimes I just wish we would get rid of JavaScript entirely and switch to a sane language with sane build tools.

ostenning 5y ago
Your frustrations are felt by many. Every tool is attempting to dethrone the competition, coming up with yet another way to do the same simple yet infinitely elusive fucking goal: render a website. The whole ecosystem is fucked
ASalazarMX 5y ago
JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all. Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets: > "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’" > "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'" https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...

buzzwords 5y ago

Reading some of the comments here has really made me feel better. I felt like I was the only one that felt JS ecosystem is just bad and painful to work with. Thanks everyone.

forty 5y ago

> The Rust version probably could be made to work at an equivalent speed with enough effort. But at a high level, Go was much more enjoyable to work with. Wow. I always thought Go was a language for depressed (or depressing? :)) devs ;) . I mean, it's boring _by design_. On the other hand Rust is really a cool language, with many things that are designed cleverly, and really enjoyable to use. Well, to me, at least, as it seems some people like boring more :)

jacquesm 5y ago
In IT boring is good. It translates into stable, long term support, no breaking changes and having a life. Exciting on the other hand does not have any of those.
- forty 5y ago
  I agree with that. I'm not saying boring is bad. It's just that I find it weird to choose Go because it's enjoyable ^^

forty 5y ago

I'd love to build my stuff faster (of course), I tried SWC and it seems impressive. But as long as it doesn't include a TS compiler that check types, I'm not exactly sure where/how I would use it. Both locally and in my CI I want my types checked, otherwise I wouldn't bother writing them.

amelius 5y ago

Rust is good for systems programming. For everything else, use a language with GC so you don't have to reinvent the wheel for every memory allocation and your brain is free to think about functionality, architecture, security, UX, ...

pjmlp 5y ago
Indeed, something like having a micro-kernel or composition engine written in Rust, everything else on top should just use a language with any kind of automatic memory management and value types support.

jchw 5y ago

Nitpick: There are a ton of programming languages in use at Facebook, Amazon, Apple, Microsoft and Google. Maybe a hundred amongst them! The fact that Rust is even being considered by as many large slow-moving companies is, indeed, impressive. But the way it’s being phrased makes it sound like it is in production everywhere, and I think the truth is the most substantial amount of Rust code in production is probably from Mozilla and maybe Amazon. In many cases, the amount of Rust code is likely very small, isolated for now, and not necessarily in production code yet. Go has also gained an impressive portfolio, too, so Rust doesn’t stand alone. Personally, I suspect Zig will be following on some day. My personal opinion is that all we can conclude today is that JavaScript is not the future of JavaScript infrastructure. However, I am somewhat unconvinced that Rust’s strengths are conclusively important enough to offset the added complexity in all use cases. In production where you might have cases where every cycle and byte counts and where a race condition or memory bug could come at a dire cost, Rust is an obvious winner. On a developer’s computer that is running mostly idle and running dev tools that are mostly embarrassingly parallel with little shared state, it’s just not so clear. Which is why I feel putting the Discord pull quote about their Rust migration underneath the testimony of evan regarding esbuild is a little bit misleading. I am still very bullish on Rust, but when honeymoon periods end, the truth comes out, and in Rust my opinion is that the language is pretty complex, the build times need a lot of work, and the ecosystem has some pretty difficult to ignore weaknesses (I reasonably frequently run into packages that are incomplete, and the dependency trees in Rust projects seem to get as unwieldy as smaller JS/npm projects!) Don’t get me wrong. Go and Zig, as two promising other languages, are obviously not competing with Rust directly. What Rust offers is fairly unique even for a memory safe language. Also, Go’s lack of sum types and pattern matching hits me harder than its verbose error handling or lack of generics. But many people, seeing the borrow checker in action, seem to conclude that it is the future, and that everything else is obsoleted by its existence. Disagree. I think all of these languages are formidable opponents and worthwhile improvements over older languages that people are migrating from. But the thing about zero cost abstractions is that they are a misnomer. They have zero cost at runtime. They have non-zero cost at compile time, they have non-zero costs on cognitive overhead, they have non-zero costs on language design… and once you acknowledge this, it’s only fair to recognize that there are cases where it’s not the trade-off you want. Still, I hope to see more adoption of what I’ll call “next generation” programming languages. Be it Rust, Zig, Go, Pony, Nim… there really is a lot promising on the horizon, stuff that will be well worth the “RiiR” costs in the long-term. I have a feeling many of them will find a place and wind up complementing each other as options you can choose for differing tastes and goals. I am very interested to see which programming language ultimately wins for JS toolchains because it might tell us a lot about just how versatile Rust’s tradeoffs are or aren’t. For now, I am happy enough with esbuild, and looking out into the future to see what’s next.

jacquesm 5y ago

It probably isn't. Simply because JavaScript has a low barrier to entry and Rust has a high barrier to entry. It would be a bit like saying LISP or Erlang are the future of BASIC or PHP.

dzonga 5y ago

as someone who has decent experience with frontend, I believe the future we will be treating JS as a assembly language. However, for that to happen we need a lua like language for js with inferred types. and for apps the will be rendered by wasm in a canvas like interface.