I’ve written quite a bit of tooling in JS, and I genuinely enjoy the language, but I feel like Rust and Go are a godsend for these types of tools. I will sometimes prototype with TypeScript, but if something requires massive concurrency and parallelism, it’s unlikely I’ll stick with it.
I wonder if the author would feel differently if they spent more time writing in more languages on tooling like this. My life got a lot easier when I stopped trying to write TypeScript everywhere and leveraged other languages for their strengths where it made sense. I really wanted to stick to one language I felt most capable with, but seeing how much easier it could be made me change my mind in an instant.
The desire for stronger duck typing is confusing to me, but to each their own. I find Rust allows me to feel far, far more confident in tooling specifically because of its type system. I love that about it. I wish Go’s was a bit more sane, but there are tons of people who disagree with me.
I don't buy the argument that a lot of the performance jumps from rewrites comes from developers writing more optimised code.
I've worked on multiple rewrites of existing systems in both JS and PHP to Go and those projects were usually re-written strictly 1:1 (bugs becoming features and all that). It was pretty typical to see an 8-10x performance improvement by just switching language.
For a smallish batch processing script I had written in node, I just fed it to chatgpt and got the golang version. It went from being unusable with over 100K records to handling 1M on exactly the same machine.
And only then I started adding things like channels, parallelism, and smart things.
Now that there's no perfect parity to maintain we've started optimising the Go versions as well. Multiple 2x performance improvements once we started doing this, on top of the original performance improvements. This translates to insane cost savings when you're working at scale.
This, like most articles dealing with "JS", is really more about the things you'll find yourself futzing around with when you're in the NodeJS and NPM ecosystem.
You wouldn't conflate Windows development with "C" (and completely discount UNIX along the way) just because of Win32. But that's about how bonkers it is when it comes to JS and people do the same with its relationship to Node—not only was JS not created to serve the Node ecosystem, the prescriptions that NPM and Node programmers insist on often cut against the grain of the language. And that's just when we're focused on convention and haven't even gotten to the outright incompatibilities between Node and the language standard (or Node's proprietary APIs).
node_modules, for example? That has fuck-all to do with ECMA262/JS. Tailwind, Rollup, Prettier, all this other stuff—even the misleadingly named ESLint? Same. You're having a terrible experience because you're interacting with terrible software. It doesn't matter that it's written in JS (or quasi-JS). Rewrite these implementations all in other languages, and the terrible experience will remain.
Besides, anyone who's staking out a position that a language is slow, and that JS is one of them is wrong two ways, and you don't have to listen to or legitimize them.
> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Is it though? Rust/Zig/Go programs are pretty much all incredibly easy to checkout and compile, it's one of the big selling points of those languages. And at the end of the day how often are javascript developers fixing the tooling they use even when it's written in javascript?
I've always felt learning new languages give me not only new tools to use but shapes the way I think about solving problems.
It's definitely more of a pain to figure out rustup than to use the Node.js environment that's already installed. As noted in the article, you can quite literally go edit the source of your NPM packages without downloading or compiling a single thing.
Minor speedbumps like installing Rust don't stop me now, and probably don't stop you either, but they might have at the start of my career. You have to think about the marginal developers here: how many people are able to debug the simple thing who would be unable or unwilling to do it for the complicated thing? As you note, it's already quite rare to fix up one's tooling, so we can't afford to lose too many potential contributors.
I like learning new languages too, but not to the extent that I'd choose to debug my toolchain in Zig while under time pressure. This is something I've actually done before, most notably for FontCustom, which was a lovably janky Ruby tool for generating font icons popular about a decade ago.
That’s not objectively true at all. I learned to use Rust long before I ever touched a Node setup, and the first time I wanted to run a JS app it took me a lot longer to figure out how to do it than it did to type `cargo run foo`.
Neither is easier than the other. Whichever one you already know will be easier for you, and that’s it.
Sorry, I think we might be talking across each other. I am saying from the perspective of someone who is already using a full Node.js environment, adding Rust must necessarily increase complexity. I am taking this perspective because in the article we're talking about, the examples are exclusively JavaScript tooling like Rollup, Prettier, and ESLint, where the only people using those tools are JavaScript developers who are already running node.
I have absolutely no interest in getting into a pissing match about whose language and ecosystem is better, and I in fact agree that the Rust tooling is less complicated than JS to start with. Nevertheless, the article is not about choosing either JS or Rust, it's about rewriting tools for working with JS in Rust, which necessarily makes you learn Rust on top of JS if you want to modify them.
I agree with you on the easy part, but it’s definitely not as fast. In JS you get instant hot code reload and even without that the interpreter starts up pretty fast. In comparison Rust takes a while to recompile even with simple changes, and if you have more changes in many files (eg. switching between branches) then it’s really slow.
On top of that some languages don't have support for SIMD/NEON and parallel libraries or GPU processing libraries - those things can significantly improve performance
the big issue here is the debuggability by having all your dependencies in the same language, and it's not even like these rewrites will all be in the same performant language for you to learn, so essentially if you are using a wasm compiled dependency you are not likely to be able to go into that dependency's code and figure out where the library author has messed up or what you have misunderstood from the documentation.
I recently discovered Rspack, which is a compatible rewrite of Webpack in Rust by a guy at ByteDance. It is genuinely 5x-10x faster across the board on my large/complicated project. I've been using Webpack for 8 years, and I was absolutely blown away to be able to easily swap Webpack out for something so similar (written in Rust) and get such a massive performance improvement. This has made my life so much better.
I’m continually surprised at JavaScript’s speed. Seeing JS sometimes nipping at the heels of C/rust/etc in performance benchmarks blows me away. V8 is such an incredible piece of engineering.
In my work, it’s hard to justify using something other than JS/TS — incredible type system, fast, unified code base for server/mobile/web/desktop, world’s biggest package ecosystem for anything you need, biggest hiring pool from being the best known language, etc.
It’s just such a joy to work with, ime. Full-stack JS has been such a superpower for me, especially on smaller teams.
The dissonance between how the silent majority feels about JS (see, e.g the SO yearly survey), vs the animus it receives on platforms like HN is sad. So here’s my attempt at bringing a little positivity and appreciation to the comments haha.
I want more people to understand how much people are working on JS performance. Google, Apple, Microsoft, Mozilla - all have incentive to make it as fast as possible.
Too bad JS is not the best candidate for many optimizations.
I wonder if we'll get to the point of having a compiled version of JS that allows more static optimizations to be done.
WebAssembly might occupy that niche if it gets nice standardized runtime.
Seems to me that the article and many of the comments conflate JS with Node. Personally I abhor Node and work with both Bun and Deno. In both cases avoiding the Node compatible bits.
> I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster
Rewriting in more performant languages spares you from the pain of optimization. These tools written in Rust are somehow 100× as fast despite not being optimized at all.
JavaScript is so slow that you have to optimize stuff, with Rust (and other performant languages) you don't even need to because performance just doesn't bubble up as a problem at all, letting you focus on building the actual tool.
I think there’s a lot of bias in the samples one tends to see:
- you’re less likely to hear about a failed rewrite
- rewrites often gain from having a much better understanding of the problem/requirements than the existing solution which was likely developed more incrementally
- if you know you will care about performance a lot, you hopefully will think about how to architect things in a way that is capable of achieving good performance. (Non-cpu example: if you are gluing streams of data with processing steps together, you may not think much about buffering; if you know you will care about throughput, you will probably have to think about batching and maybe also some kind of fan-out->map->fan-in; if you know you will care about latency you will probably think about each extra hop or batch-building step)
- hopefully people do a bit of napkin math to decide if rewriting something to be faster will achieve the goals, and so you only see the rewrites that people thought would be beneficial (because eg you’re touching a lot of memory so a better memory layout could help)
I feel like you’re much more likely to see ‘we found some JavaScript that was too useful for its own good, figured out how to rewrite it with better algorithms/data structures, concurrency, and sims instructions, which we used rust to get’ than ‘our service receives one request, sends 10 requests to 5 different services, collects the results and responds; we rewrote it in rust but the performance is the same because it turns out most of what our service did was waiting’.
Only semi-relevant, but there's also the fact that lower level languages can auto-optimize more deeply -- but that's also more my intuition (would love to get learnt if I'm wrong).
For example, I'd expect that Rust (or rustc I guess) can auto-vectorize more than Node/Deno/etc.
Javascript should introduce integers and structs and it will have 10-100x the performance it has today without spending another $100 billion on VM optimization.
I really don't think the problem is JavaScript in all these cases. I've seen codebases using webpack where the JS was being run through babel twice in a row, because webpack is a complicated nuisance and nobody on the team had gotten around to fixing it. You can't blame that on V8 or node being slow.
Being a statically-typed compiled language has its perks (especially when doing systems programming). Regardless, JS runtimes can and will push forward (like JVM / ART did), given there's healthy competition for both v8 & Node.
"Good" compared to what? All the mentioned languages keep getting more performant year-over-year, but in the medium future scripting languages are unlikely to reach the performance levels of C, Rust or other low-level languages.
Wouldn't it be amazing though? Maybe some combination of JIT and runtime static analysis could do it.
Personally, I never assign different types to the same variable unless it's part of a union (e.g. string | HTMLObject | null, in JS).
It would probably require getting rid of `eval' though, which I am fine with. On average, eval() tends to be naughty and those needs could be better met in other ways than blindly executing a string.
Javascript is screamingly fast compared to the vast majority of other dynamic languages (scripting type, not something like Objective C). This is with the V8 engine of course. I’m not sure where you’re getting that it’s slow?
I guess if folks write JS with the idea that optimisations are needed in mind, then the chances of premature optimisations may go up along with those of the required ones
Reminds me of using Ruby ten years ago and having to contend with folks who wanted to default to using the string literal style over another because it was known to be more performant at scale. That awkward stuff surfaces earlier with some languages than with others.
> I should also acknowledge: there is a perf hit from using Wasm versus pure-native tools. So this could be another reason native tools are taking the CLI world by storm, but not necessarily the browser frontend.
I didn't know about this before, I wonder how much overhead?
The reason I am reluctant to rely on JS tools for anything CLI is because of Node.js instability due to version sensitivity and impossible-to-fix-without-reinstalling-the-os low level LibC errors.
Compared to go, rust, or python, the odds that any given CLI.js program will run across my (small) fleet of machines is very low, by factor or 10x or more compared to alternatives. Some boxes I don't want to reinstall from scratch every 4 years, they're not public facing and life is too short.
JavaScript is a terrific language: more ubiquitous than BASIC ever was; nearly as easy to learn and use as Python; syntax that is close to Java/C/C++. And it only uses 10x the CPU and memory of C or C++.
I'm not sure if JavaScript supports it, but some Python libraries allow you to choose whether to install a more optimized binary version or the pure Python implementation.
For example, if you install psycopg you'll get a pure Python implementation which is easy to debug and hack. But you can also install psycopg[binary] to obtain a faster, compiled version of the library. https://www.psycopg.org/psycopg3/docs/basic/install.html
While the skeptical's stall in decision making, new comers who do not think twice about rewriting. Rewrite software on a smaller budget in experimental attempts. Then management decides to chose the cheaper option available, because lean startup is promising. Then in next 10 years the new comers become the new skepticals. I don't know if there's a case that this cycle is not repeated, at any time frame.
I've rewritten it for clarity: "While the skeptics stall in decision making, newcomers will not think twice about rewriting software on a smaller budget as an experiment. Then management will decide to choose the cheapest option available, because the lean startup was more competitive. Then in the next 10 years, the newcomers become the new skeptics. In my experience this cycle is always repeated, albeit across different time frames."
I made the difficult choice to rewrite it in English again, even though French might have been more performant.
Thank you so much, you taught me how to express this "albeit across different time frames". It is difficult to use any language to simplify complex narrations.
Imagine developers as the choosing (management) part and if you are involved with webdev in last decade. Compare webpack and vite. As pricing parameter consider the time to bundle (faster=cheaper). So, what webpack did not do by not rewriting itself, vite came in offering.
Yeah, i agree. I think there is a time where rewriting in a faster language is useful (just like how handcrafted assembly is still a thing), but most of the time you are very far away from the point where that is neccesary.
I also think there is an element of, "rewrite in rust" is just easy to say, where changing data structures or whatever requires analysis of the problem at hand.
It is analogues discussion to C vs Rust. Sure Rust is memory safe, but whole ecosystem I am using today is C based. Compiler, SDK, drivers, RTOS, ... Nobody sane is going to rewrite it for the sake of rewriting it into a different language.
I would disagree with that comparison. Rust really does provide an improvement in memory safety that is hard to achieve by other means. That's not to say you should always rewrite in rust, there are plenty of situations where that doesn't make sense. However its not analgous to the performance situation in my opinion.
Sometimes it seems that people who write these kinds of pieces forget that not everyone in the world does web or even web-adjacent work, and node.js is something we don’t even consider to be part of our ecosystem. Rewriting useful things in non-JS has the benefit of letting folks like me who avoid JS like the plague use useful tools. Stop assuming everyone wants to get anywhere near the JS ecosystem: I’ve gone 30 years without touching it, and plan to continue that streak. Rewriting stuff is great from my perspective.
Right, because tooling is standardized in eg Go. There’s no custom build pipeline, transpilation hell, or experimental language features that are selectively enabled randomly. I’m not even against JS, like at all, and I think the majority of perf issues can be resolved. However, JS tooling is the prime example of where things get truly nightmarish from a software development perspective. Webpack being a perfect example of this horror.
Well curious as to what some of these ideas might be.
NPM has done a pretty great job of showing everyone else what to avoid doing.
The mere mention of “web pack” sends most of the FE devs I’ve met into borderline trauma flashbacks.
There’s seemingly half a dozen package managements tools, some of which also seem to be compilers? There’s also bundlers, but again some of these seem integrated. Half of the frameworks seem to ship their own tools?
> For another thing: it’s straightforward to modify JavaScript dependencies locally. I’ve often tweaked something in my local node_modules folder when I’m trying to track down a bug or work on a feature in a library I depend on. Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Yeah, JavaScript is sloppy, but you can always monkey-patch it by modifying tool-controlled files. Great idea. Not.
JS is just not a good language. The JIT and the web of packages made it slightly more usable, but it's still Not Good. There's no real way to do real parallel processing, async/await are hellish to debug, etc.
> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Or you could use the source code already downloaded by a package manager and do similar tweaks locally with the build manager picking them up and compiling for you
IMO the biggest win when Phoenix switched to esbuild wasn't about _speed_ exactly, it was about not having to install&debug things like node-gyp just to get basic asset bundling going.
> I’ve written a lot of JavaScript. I like JavaScript. And more importantly, I’ve built up a set of skills in understanding, optimizing, and debugging JavaScript that I’m reluctant to give up on.
It's not that hard to do the same for a less terrible language. Choose something markedly different, i.e. a low level language like rust, and you will learn a lot in the process. More so because now you can see and understand the programming world from two different vantage points. Plus, it never hurts to understand what's going on on a lower level, without an interpreter and eco-system abstracting things away so much. This can then feed back into your skills and understanding of JS.
Curious what you mean by "most" (I'm agnostic/unlearned on the statistics tbh). I "feel" like it doesn't happen too often when it's not either already low-level or the supposed extra performance is likely worth it.
Like, I can't imagine most people using Javascript would want to rewrite in Rust without some decent reason.
> It's not that hard to do the same for a less terrible language.
I miss that brief era when coding culture had a moment of trying to be nice, of not crudely shooting out mouths off at each other's stuff crudely.
JS, particularly with typescript, is a pretty fine language. There's a lot of bad developers and many bad organizations not doing their part to enable & tend to their codebases, but any very popular language will likely have that problem & it's not the languages fault.
It's a weakness & a strength that JS is so flexible, can be so many different things to different people. Even though the language is so so much the same as it was a decade & even two ago, how we use it gone through multiple cycles of diversification & consolidation. Like perl, it is a post-modern language; adaptable & changing, not prescriptive. http://www.wall.org/~larry/pm.html
If you do have negative words to say, at least have the courage & ownership to say something distinct & specific, with some arguments about what it is you are feeling.
I’d normally agree with you, but JS is more or less designed to be terrible. It was hacked together by Brendan Eich in literally 10 days, who originally wanted to do something more Scheme-like. It was a quick and dirty hack that got stretched way beyond what it was even meant for.
It then literally had decades of ECMAscript committee effort to shape it into something more useable.
I could repeat the numerous criticisms, but there’s enough funny videos about it that make a much better job pointing out its shortcomings and, sometimes, downright craziness of it.
> but any very popular language will likely have that problem & it's not the languages fault.
No, sorry, just no. I get where you are coming from, but in the case of JavaScript, its history and idiosyncrasies alone set it apart from many (most?) other languages.
Perl for example was made with love and with purpose, I don’t think it’s comparable.
Okay, I stand corrected. So this prototype didn’t ship, or did it ship and evolve?
Brendan Eich himself calls JS a “rush job” and with many warts though, having had to add aspects that in retrospect he wouldn’t have. This snippet from your link is consistent with that:
Also, most of JavaScript's modern flaws do *not* come from the prototyping phase. The prototype didn't have implicit type conversion (`"1" == 1`), which was added due to user feedback. And it didn't have `null`, which was added to 1.0 for better Java Interop.
Like many people, I find JS super frustrating to use.
This anecdote about the double equality operator might have originated from Eich's chat with Lex Fridman where he states (at about 5 minutes and 26 seconds) that during the original 10 day sprint JavaScript didn't support loose equality between numbers and strings: https://www.youtube.com/watch?v=S0ZWtsYyX8E&t=326s
The type system was weakened after the 10 day prototyping phase when he was pressured by user feedback to allow implicit conversions for comparisons between numbers and serialized values from a database. So it wasn't because he was rushing, it was because he caved to some early user feedback.
The implicit type conversion is good for a very funny conference video ("wat") but man, it's just so overplayed as a weakness especially versus how much real world impact it has on anyone.
And with TypeScript or linting, many of the strange comparison/conversion issues go away.
I struggle to find any substantial arguments against the js language, in spite of a lot of strong & vocal disdainful attitudes against it.
The implicit coercion and its weird behavior is absolutely a major footgun, not just fodder for the “wat” video. It’s something that can get you into serious trouble quite easily if left unchecked, for example by just looking at a list wrong. For someone to say that it has never caused them surprising pain in plain JavaScript is probably disingenuous. This is something that most other languages plainly don’t have as a problem, at least not as baffling.
Other things worth mentioning are the unusual scoping (by default at least), prototypes, “undefined”, and its role versus "null"... the list goes on.
I give TypeScript a lot of credit for cleaning up at least some of that mess, maybe more. But TypeScript is effectively another language on top of JS, not everyone in the ecosystem has the luxury of only dealing with it, and across all layers and components.
Is my knowledge about JavaScript outdated and obsolete? Certainly. Is the above stuff deprecated and turned off by default now? Probably. I left web development more than 10 years ago and never looked back. I’m a bit of a programming language geek, so I’ve used quite a few languages productively, and looked at many more. But not many serious programming languages have left quite the impression that JavaScript and PHP have.
In the meantime, I have always remembered that one conversation I had with someone who was an ECMAscript committee member at that time: They were working really hard to shape this language into something that makes sense and compiles well. Maybe against its will.
EDIT: Dear god, I completely forgot about JavaScript’s non-integerness, and its choice of using IEEE 754 as its basic Number type. Is that still a thing?
I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.
Why would they never run on another machine? It's not that hard to write portable code, and done very often. Nowadays for example, you rarely ever think about whether you're on arm or x86.
If you write non-portal code, there might be an important reason (like writing OS components, which you won't do in JS).
almost every time code doesn’t run on my machine, the root cause is a political disagreement with a c-compiler author three layers below my actual problem.
javascript doesn’t have a compiler is my main point.
Bit rich to complain about that when all the major browsers have just as significant differences, and that’s before we bring node into the equation, let alone talking about a good 30% of websites I visit with any quantity of JS in them are either perpetually broken in some way, or so jank as to be effectively broken.
totally agreed about all of the above and i take credit for none of that code
i write plaintext at uris, progressively enhance that to hypertext using a port with a deno service, a runtime that unifies browser js with non browser js.
that hypertext can optionally load javascript and at no point was a compiler required aside from the versioned browser i can ask my customers to inspect or a version of deno we get on freebsd using pkg install.
node is not javascript would be my biggest point if i had to conclude why i responded.
microsoft failed at killing the web with internet explorer and only switched to google’s engine after securing node’s package manager overtly through github and covertly through typescript.
microsoft is not javascript is my final point after circling back to my original point of microsoft is also one of the aforementioned reasoned c-compilers are politically fought over instead of things that just work.
It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? I guess not making tools for say, c# devs in c# would also be bad?
> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS?
Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though.
The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts.
That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.
Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.
Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough.
Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.
> I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.
It's true, it has some really bad parts but you can avoid them.
If I could design the perfect language for myself, it would have the syntax of JavaScript and the portability of JavaScript but it would use Python's strong duck typing approach.
Not the OP, but the appeal of languages like JS has a lot to do with developer productivity. I write gobs of JS and Python code and the finished programs and libraries can be strongly and statically typed end-to-end. I just don't want to be forced to do it in cases when it doesn't really make a difference, and I don't want to waste time on it when I'm still figuring out the design.
My hope is one of the Next Big Things in programming languages is the widespread adoption of incremental typing systems.
So during the early stages of dev you get the productivity benefits of dynamic and loose/duck typing as much as you want, and then as the code matures - as the design firms up - you begin layering in the type information on different parts of the program (and hopefully the toolset gives you a jump start by suggesting a lot of this type info for you, or maybe you specify it only in places where the type info can't be deduced).
Then those parts of the program (and hopefully eventually the entire program) are strongly and statically typed, and you get all of the associated goodies.
most static type systems are verbose, probably due to linguistic verbosity, so one obvious thing that static type systems have probably done to a lot of people is given them pain from typing so much.
Not sure what languages you are thinking to with "most static type systems", but in languages like TypeScript or Rust (and I guess modern Java/C#, haven't touched those in a while), most of the types are inferred by the system such as you don't need to write them. You type your functions arguments (and return values in Rust) and that's about it.
I don't feel it's so much typing. Especially for the clarity and, most importantly, safety and correctness I get back. I'd rather type 3 1/2 seconds more than debug a dumb type issue for half an hour.
It gets really old to get something like "NoneType does not have blah" in a deeply nested, complicated data structure in python, but obviously only at runtime and only in that hard to hit corner case, when all you did is forget to wrap something in the right number of square brackets in some other part of the code.
I haven't fully given up on python, but I only deal with it using mypy, which adds static typing, anymore.
A bit of extra verbosity as added by static typing can also be immensely helpful for trawling through and/or learning an unfamiliar codebase, especially in the absence of an IDE or debugging environment (e.g. browsing code on GitHub or in a filemanager).
For instance, take function definitions. By just adding types to the function's arguments, you're potentially saving the reader a ton of time and mental overhead since they don't have to chase down the right the chain of function calls to figure out what it is exactly (or is supposed to be) that's getting passed in.
I can't even figure out how to write typescript that conditionally uses browser-only or node-only libraries depending on which environment it's in. My current best guess is to write 2 completely independent typescript projects that happen to point to the same source files?
This guy is not competent to talk about what he's talking about.
>"JavaScript is, in my opinion, a working-class language. It’s very forgiving of types (this is one reason I’m not a huge TypeScript fan)."
Being "forgiving of types" is not a good thing. There's a reason most "type-less" languages have added type hints and the like (Python, Typescript, etc) and it's because the job of a programming language is to make it easier for me to tell the CPU what to do. Not having types is detrimental to that.
It's not forgiving of types at all. Reality is not forgiving of type errors. The only thing JavaScript does is move the moment where you find out reality is not forgiving of type errors to when your code is running in prod rather than at compile time, and makes them more implicit. That doesn't make it a bad thing per se to be forgiving of type errors. For example, if you really like fixing errors in production rather than before pushing them to production, this faux forgiveness is precisely what you should be looking for. It's all up to personal preference. Personally, I prefer knowing early on if there's problems with my code, and having a higher degree of certainty regarding it working or not.
All of this is under the assumption that whatever you're writing has some degree of complexity to it (an assumption which is satisfied very quickly). Five line python glue scripts don't necessarily benefit from static typing.
> There's a reason most "type-less" languages have added type hints and the like (Python, Typescript, etc)
I would like to clarify that even without typing python is a LOT less "forgiving of types" than javascript. It has none of the "One plus object is NaN" shenanigans you run into with javascript.
Types are guidelines and strictly useful and a good thing. That said, one can wonder why languages like basic, python, scheme or php (dynamic, implicit types) have grown popular. Maybe for bad reasons but there IS an added value for implicit types. C++ (maybe even C !) has grown the auto keyword and other typed language have type inference. Which is not the same as "typeless" (it always is typed) but it defeats one of the "double check" security of types. And it's sometimes not needed (yes, if I initialize it with "abc" it may be a string)
Please, preferring dynamic typing is not a sign of "incompetence". Stop this nonsense. Also, I won't question your competence because you called Python and JavaScript "type-less". The type-less languages (other than assembly) that were ever used were BCPL and B (predecessors of C).
There are plenty of good things written in languages with weaker type systems than TypeScript (Linux, your browser, HN). Using C/C++ or a dynamic language doesn't immediately make you incompetent.
PHP does but the types actually mean something. If your types can be stripped out to make the program run, I have a hard time believing that there is any optimization occurring there.
Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.
Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.
As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.
> Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.
This is one of the biggest falsehoods in the software engineering I know.
Language is a collaboration glue and influences way of thinking guiding solution development. As an analogy: you can make a statue from a glass or from ice, but while both can be of the same shape and be equally awed upon, the process and qualities will differ.
For the prototypes and throwaways context doesn’t matter - That’s why all short lived contests, golfs and puzzles ignore it. Yet, when software is to be developed not over the week but over the decades and (hopefully) delivered to thousands if not millions of computers it’s the technological context (language, architecture, etc.) that matters the most.
Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. Sometimes it really is the programming language.
In the JavaScript world a lot of speed up comes from 3 major things as far as I can tell:
- easier concurrency.
- the fact that things are actually getting rewritten with the purpose of speeding them up.
- a lot of the JS tooling getting speedups deals with heavily with string parsing, tokenizing, generating and manipulation of ASTs. Being able to have shared references to slices of strings, carefully manage when strings are copied, and have strict typing of the AST nodes you enable things to be much faster than JavaScript.
I once worked on a Python system that had 50 machines dedicated to it. We were able to rewrite it in a more performant language such that it easily ran on one machine. This also allowed us to avoid all the issues distributed systems have.
So yeah, Python is not great for systems programming
This is a very nice counterexample, but it's not actually a counter example without an example.
Also, this was a thing before Rust. I've rewritten several things in C or Cpp for python back ends, and most pytbon performance-critical code is already an API to a shared library. You'd be surprised to run OR tools and find Fortran libraries loaded by your python code.
But can I write plugins for it? My understanding it is only implements a subset of the common plugins (and does not do any of the linting that pylint is useful for), so it avoids scanning the filesystem for plugins?
Choosing the right algorithm effectively means optimizing runtime complexity. Then, once runtime complexity is fixed with the right algorithm, you're still left with a lot of constant factors that O-notation deliberately ignores (it's only about growth of the runtime). Sometimes, optimizing those constant factors can be significant, and then the choice of language matters. And even some details about the CPU you are targeting, and overall system architecture.
Often languages like Javascript and Python don't allow optimal runtime complexity, because the types baked in to external interfaces fundamentally disallow the desired operation. And these languages are too slow to rewrite the core logic in the language itself.
(but of course, the vast majority of the code, even in widely used tools, isn't properly designed for optimization in the first place)
I only dabble in javascript, but `tsc` is abominable.
> Lots of very smart people have worked very hard on Python tools written in Python
Yes, I agree that is very sad
Python is achingly slow. I know the Python people want to address this, I do not understand. Python makes sense as a scripting/job control language, and execution speed does not matter.
As an application development language it is diabolical. For a lot of reasons, not just speed
> Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster.
So?
Some tool got written and did its job sufficiently well that it became a bottleneck worth optimizing.
That's a win.
"Finishing the task" is, by far, the most difficult thing in programming. And the two biggest contributors to that are 1) simplicity of programming language and 2) convenience of ecosystem.
Python and Javascript are so popular because they tick both boxes.
Don’t disagree about finishing the task, but personally I don’t find more performant languages any less productive for the sort of programming I tend to do.
Congratulations on being a programming god. This discussion isn't for you.
From my point of view, I'm happy if I can convince my juniors to learn a scripting language. Okay? I don't care which one--any one. I'd prefer that they learn one of the portable ones but even PowerShell is fine.
I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language.
Those folks who program but don't know a scripting language far outnumber the rest of us.
> I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language.
> Those folks who program but don't know a scripting language far outnumber the rest of us.
What domain are you in? This sounds like the complete inverse of every company I've ever worked at.
Entire products are built on Python, Node ect, and the time after the initial honeymoon phase (if it exists) is spent retrofitting types on top in order to get a handle, any handle, on the complexity that arises without static analysis and compile time errors.
At around the same time, services start OOM'ming left and right, parallellism=1 becomes a giant bottleneck, JIT fails in one path bringing the service performance down an order of magnitude every now and then etc...
> Congratulations on being a programming god. This discussion isn't for you.
On the behalf of mediocre developers everywhere, a lot of us prefer statically typed languages because we are mediocre; I cannot hold thousands of implicit types and heuristics in my head at the same time. Luckily, the type system can.
Quite the opposite, for most cases you don't hit the scale where asymptotic algorithmic performance really makes a big impact (e.g., for many small set comparisons, iterating over a list is faster than a hash set, but only by 10-50% or so), vs switching to a compiled language which instantly gets you 10x to 100x performance basically for free.
Or perhaps another way to look at it, if you care enough about performance to choose a particular algorithm, you shouldn't be using a slow language in the first place unless you're forced to due to functional requirements.
And anyone who expands the horizon to the real world, instead of focusing on the artificial one of contests, knows that the language matters a great deal
In higher level languages your code may allocate memory or trigger a GC pass or other smartness in unexpected places. This may cause slowdowns you may not have control over or may change from version to version or vendor to vendor. It is often easier to manage in "faster" languages. Good algorithm may not be enough.
The types of problems in those contests are meant to highlight algorithms. In the real world you might have a trivial algorithm but a huge input size, where the constant factor matters much more.
Here’s the thing: languages like C#, Java and Rust all have extensive libraries and packages that implement many common data structures and algorithms well. With all due respect to the incredible work that goes into projects like lodash, JavaScript does not. (Nor does C, for that matter.)
> knows that the language doesn’t matter so much as your algorithm.
I know what you’re referring to but these problems have also taught me a lot about language performance. python and JS array access is just 100x slower than C. Some difficult problems become much harder due to this limitation.
JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.
Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.
That's the only benchmark on the page that uses such wrapper.
Buffer.allocUnsafe just allocates the memory without zero-initializing it, just like e.g. malloc does. Probably usually not worth it, but in a benchmark it's comparable to malloc vs calloc.
It's not just a matter of “picking the correct algorithm”. Algorithmic-interview exercises are algorithmic-interview exercices. They are barely related to real-world software engineering.
While picking the right algorithm seldom comes up in most programmers day-to-day activities, being aware of big-Oh and the performance guarantees/characteristics of the libraries you use most certainly should.
I don't care if you don't know how to write a merge sort from scratch. I do care about you knowing not to write an O(n^2) loop when it can be avoided.
I do, but only in very, very rare circumstances. Basically only when you a) know that the typical use case is going to involve large ns, like millions to billions, b) the loop body takes a long time per invocation, or c) have profiled a performance issue and found that improving it would help.
If you're working with sets of 10 items, just write the damn nested loop and move on. Code jockeying is unlikely to be faster, and even if it is, it doesn't help enough to matter anyway.
Computer science theory likes to ignore constants. Big-O notation does that explicitly. But in the real world, it's usually the constants that kill you. Constants, and time to market.
If you are working with a hardcoded 10 items, and you are certain that won't change significantly, sure.
If not I strongly disagree, because I've seen way too often such cases blow up due to circumstances changing.
Now, if it is very difficult to avoid a nested loop then we can discuss.
But it can simply be due to being unaware that some indexed library call is in fact O(n) or something like that, and avoiding it by using a dictionary or some other approach is not hard.
While constants matter to some degree, the point of big-O is that they don't so much if you get handed two orders of magnitude more data than you expected.
I'll gladly sacrifice a tiny bit of performance for code that doesn't suddenly result in the user not being able to use the application.
Choosing the right algorithm is usually the prerequisite for fast code. Optimizing the constant factors is often pretty useless if you pick an algorithm with a runtime that grows quadratically, when there are much better options available.
What makes you think they're not? I don't know why these tools are sluggish, but I disagree with the notion that algorithms don't matter for "real-world software engineering".
You optimize the constant factors, e.g. the runtime of the inner loops. But this requires you to choose a sane algorithm in the first place.
Some problems are much more complicated, where you have to take, for example, locality (cache hierarchy etc.) and concurrency considerations like lock contention into account. This may affect your choice of algorithm, but by the time you reach that, you've almost certainly thought about the algorithm a lock already.
I’ve worked on some huge nodejs projects, it’s a great language for “serious projects”. It has costs and benefits like any other language. If you use TypeScript then IME many of the costs are mitigated.
Pretty much all the usual, boring offenders everyone's familiar with: truthy/falsey, errors passing silently, exceptions, and differences in importing behaviour with bundlers and runtimes. These things are admittedly quite simple to fix when it's your code, but when you multiply that by 1000 dependencies, which is a conservative number for a JS project a whole host of difficult to detect issues will rear over time.
> If you use TypeScript then IME many of the costs are mitigated.
TS meaningfully helps, but it still falls short of the mark imho. Turning on 99% of TS lints to error is the only solid way I've found to prevent a lot of the issues I've encountered. But that's really hard to introduce into existing codebases. It's doable, but with a lot of friction and effort.
If you look at JavaScript's history (especially for backend development), it reads like a series of accidents: First, the JS language was hacked together at Netscape in the space of a few months in 1995, and after that it was quickly baked in into all web browsers and therefore became very hard to change in a meaningful way. Then, Google developed the V8 engine for Chrome, and someone thought it would be a great idea to use it for running JS in the backend. My thoughts on that were always: "just because you can do something doesn't mean that you should"...
I’ve written quite a bit of tooling in JS, and I genuinely enjoy the language, but I feel like Rust and Go are a godsend for these types of tools. I will sometimes prototype with TypeScript, but if something requires massive concurrency and parallelism, it’s unlikely I’ll stick with it.
I wonder if the author would feel differently if they spent more time writing in more languages on tooling like this. My life got a lot easier when I stopped trying to write TypeScript everywhere and leveraged other languages for their strengths where it made sense. I really wanted to stick to one language I felt most capable with, but seeing how much easier it could be made me change my mind in an instant.
The desire for stronger duck typing is confusing to me, but to each their own. I find Rust allows me to feel far, far more confident in tooling specifically because of its type system. I love that about it. I wish Go’s was a bit more sane, but there are tons of people who disagree with me.
I don't buy the argument that a lot of the performance jumps from rewrites comes from developers writing more optimised code.
I've worked on multiple rewrites of existing systems in both JS and PHP to Go and those projects were usually re-written strictly 1:1 (bugs becoming features and all that). It was pretty typical to see an 8-10x performance improvement by just switching language.
Exactly the same experience.
For a smallish batch processing script I had written in node, I just fed it to chatgpt and got the golang version. It went from being unusable with over 100K records to handling 1M on exactly the same machine.
And only then I started adding things like channels, parallelism, and smart things.
Now that there's no perfect parity to maintain we've started optimising the Go versions as well. Multiple 2x performance improvements once we started doing this, on top of the original performance improvements. This translates to insane cost savings when you're working at scale.
> One reason for my skepticism is that I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster.
Exhausting is very exhausting, so at a fraction of that effort you could build on better foundations
This, like most articles dealing with "JS", is really more about the things you'll find yourself futzing around with when you're in the NodeJS and NPM ecosystem.
You wouldn't conflate Windows development with "C" (and completely discount UNIX along the way) just because of Win32. But that's about how bonkers it is when it comes to JS and people do the same with its relationship to Node—not only was JS not created to serve the Node ecosystem, the prescriptions that NPM and Node programmers insist on often cut against the grain of the language. And that's just when we're focused on convention and haven't even gotten to the outright incompatibilities between Node and the language standard (or Node's proprietary APIs).
node_modules, for example? That has fuck-all to do with ECMA262/JS. Tailwind, Rollup, Prettier, all this other stuff—even the misleadingly named ESLint? Same. You're having a terrible experience because you're interacting with terrible software. It doesn't matter that it's written in JS (or quasi-JS). Rewrite these implementations all in other languages, and the terrible experience will remain.
Besides, anyone who's staking out a position that a language is slow, and that JS is one of them is wrong two ways, and you don't have to listen to or legitimize them.
> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Is it though? Rust/Zig/Go programs are pretty much all incredibly easy to checkout and compile, it's one of the big selling points of those languages. And at the end of the day how often are javascript developers fixing the tooling they use even when it's written in javascript?
I've always felt learning new languages give me not only new tools to use but shapes the way I think about solving problems.
It's definitely more of a pain to figure out rustup than to use the Node.js environment that's already installed. As noted in the article, you can quite literally go edit the source of your NPM packages without downloading or compiling a single thing.
Minor speedbumps like installing Rust don't stop me now, and probably don't stop you either, but they might have at the start of my career. You have to think about the marginal developers here: how many people are able to debug the simple thing who would be unable or unwilling to do it for the complicated thing? As you note, it's already quite rare to fix up one's tooling, so we can't afford to lose too many potential contributors.
I like learning new languages too, but not to the extent that I'd choose to debug my toolchain in Zig while under time pressure. This is something I've actually done before, most notably for FontCustom, which was a lovably janky Ruby tool for generating font icons popular about a decade ago.
That’s not objectively true at all. I learned to use Rust long before I ever touched a Node setup, and the first time I wanted to run a JS app it took me a lot longer to figure out how to do it than it did to type `cargo run foo`.
Neither is easier than the other. Whichever one you already know will be easier for you, and that’s it.
Sorry, I think we might be talking across each other. I am saying from the perspective of someone who is already using a full Node.js environment, adding Rust must necessarily increase complexity. I am taking this perspective because in the article we're talking about, the examples are exclusively JavaScript tooling like Rollup, Prettier, and ESLint, where the only people using those tools are JavaScript developers who are already running node.
I have absolutely no interest in getting into a pissing match about whose language and ecosystem is better, and I in fact agree that the Rust tooling is less complicated than JS to start with. Nevertheless, the article is not about choosing either JS or Rust, it's about rewriting tools for working with JS in Rust, which necessarily makes you learn Rust on top of JS if you want to modify them.
I agree with you on the easy part, but it’s definitely not as fast. In JS you get instant hot code reload and even without that the interpreter starts up pretty fast. In comparison Rust takes a while to recompile even with simple changes, and if you have more changes in many files (eg. switching between branches) then it’s really slow.
I wonder if author is aware that Node.js is not written in JavaScript.
Probably: he is a contributor to Servo
> It’s very forgiving of types
I lost you here. JavaScript doesn't work around type issues, no language really can. It just pushes the type issues to a later time.
Here you have benchmark of programming languages: https://benchmarksgame-team.pages.debian.net/benchmarksgame/
On top of that some languages don't have support for SIMD/NEON and parallel libraries or GPU processing libraries - those things can significantly improve performance
the big issue here is the debuggability by having all your dependencies in the same language, and it's not even like these rewrites will all be in the same performant language for you to learn, so essentially if you are using a wasm compiled dependency you are not likely to be able to go into that dependency's code and figure out where the library author has messed up or what you have misunderstood from the documentation.
The solution to that is dependencies that work
Does the dependency that always works and has no bugs also come with a free rainbow and unicorn?
I sure hope so - otherwise how would I know the dependency I installed was going to always work?
Ask the unicorn.
exactly, which is why I was hoping I would get one?
I recently discovered Rspack, which is a compatible rewrite of Webpack in Rust by a guy at ByteDance. It is genuinely 5x-10x faster across the board on my large/complicated project. I've been using Webpack for 8 years, and I was absolutely blown away to be able to easily swap Webpack out for something so similar (written in Rust) and get such a massive performance improvement. This has made my life so much better.
I’m continually surprised at JavaScript’s speed. Seeing JS sometimes nipping at the heels of C/rust/etc in performance benchmarks blows me away. V8 is such an incredible piece of engineering.
In my work, it’s hard to justify using something other than JS/TS — incredible type system, fast, unified code base for server/mobile/web/desktop, world’s biggest package ecosystem for anything you need, biggest hiring pool from being the best known language, etc.
It’s just such a joy to work with, ime. Full-stack JS has been such a superpower for me, especially on smaller teams.
The dissonance between how the silent majority feels about JS (see, e.g the SO yearly survey), vs the animus it receives on platforms like HN is sad. So here’s my attempt at bringing a little positivity and appreciation to the comments haha.
I want more people to understand how much people are working on JS performance. Google, Apple, Microsoft, Mozilla - all have incentive to make it as fast as possible.
Too bad JS is not the best candidate for many optimizations.
I wonder if we'll get to the point of having a compiled version of JS that allows more static optimizations to be done.
WebAssembly might occupy that niche if it gets nice standardized runtime.
Seems to me that the article and many of the comments conflate JS with Node. Personally I abhor Node and work with both Bun and Deno. In both cases avoiding the Node compatible bits.
> I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster
Rewriting in more performant languages spares you from the pain of optimization. These tools written in Rust are somehow 100× as fast despite not being optimized at all.
JavaScript is so slow that you have to optimize stuff, with Rust (and other performant languages) you don't even need to because performance just doesn't bubble up as a problem at all, letting you focus on building the actual tool.
I think there’s a lot of bias in the samples one tends to see:
- you’re less likely to hear about a failed rewrite
- rewrites often gain from having a much better understanding of the problem/requirements than the existing solution which was likely developed more incrementally
- if you know you will care about performance a lot, you hopefully will think about how to architect things in a way that is capable of achieving good performance. (Non-cpu example: if you are gluing streams of data with processing steps together, you may not think much about buffering; if you know you will care about throughput, you will probably have to think about batching and maybe also some kind of fan-out->map->fan-in; if you know you will care about latency you will probably think about each extra hop or batch-building step)
- hopefully people do a bit of napkin math to decide if rewriting something to be faster will achieve the goals, and so you only see the rewrites that people thought would be beneficial (because eg you’re touching a lot of memory so a better memory layout could help)
I feel like you’re much more likely to see ‘we found some JavaScript that was too useful for its own good, figured out how to rewrite it with better algorithms/data structures, concurrency, and sims instructions, which we used rust to get’ than ‘our service receives one request, sends 10 requests to 5 different services, collects the results and responds; we rewrote it in rust but the performance is the same because it turns out most of what our service did was waiting’.
Only semi-relevant, but there's also the fact that lower level languages can auto-optimize more deeply -- but that's also more my intuition (would love to get learnt if I'm wrong).
For example, I'd expect that Rust (or rustc I guess) can auto-vectorize more than Node/Deno/etc.
Javascript should introduce integers and structs and it will have 10-100x the performance it has today without spending another $100 billion on VM optimization.
I really don't think the problem is JavaScript in all these cases. I've seen codebases using webpack where the JS was being run through babel twice in a row, because webpack is a complicated nuisance and nobody on the team had gotten around to fixing it. You can't blame that on V8 or node being slow.
Someday soon I hope webasm gets another decent compiled language targeted for JS speedups. Something interoperable with JS.
For analogies, look no further than ASM in the early days and the motivations that brought us C, but with the lessons learned as well.
Rust is fine for this, except for interoperability.
It looks like Rust can interop with JS via WebASM?
https://stackoverflow.com/questions/65000209/how-to-call-rus...
Of course that's why we're discussing it. I'm referring to stronger interop like how you can embed ASM in C, and therefore CPP.
Like a JS/TS that can have compiled blocks specified in the same language, preferably inline? I'm reaching here.
Being a statically-typed compiled language has its perks (especially when doing systems programming). Regardless, JS runtimes can and will push forward (like JVM / ART did), given there's healthy competition for both v8 & Node.
JavaScript, Python, Lua, I don't see any dynamic language with good performances. Do you have examples?
"Good" compared to what? All the mentioned languages keep getting more performant year-over-year, but in the medium future scripting languages are unlikely to reach the performance levels of C, Rust or other low-level languages.
Wouldn't it be amazing though? Maybe some combination of JIT and runtime static analysis could do it.
Personally, I never assign different types to the same variable unless it's part of a union (e.g. string | HTMLObject | null, in JS).
It would probably require getting rid of `eval' though, which I am fine with. On average, eval() tends to be naughty and those needs could be better met in other ways than blindly executing a string.
Javascript is screamingly fast compared to the vast majority of other dynamic languages (scripting type, not something like Objective C). This is with the V8 engine of course. I’m not sure where you’re getting that it’s slow?
Lua with LuaJIT has pretty good performance. With that said, I spent today writing in C++, so I do agree with the overall sentiment.
Common Lisp (SBCL)?
Don't forget Scheme (Gambit, Chez, Racket).
That's true, though I'd argue these are not as dynamic.
>JavaScript is so slow that you have to optimize stuff
This raises the question, is JavaScript more prone to premature optimization?
Well, can we really call it premature optimization if it's needed?
I guess if folks write JS with the idea that optimisations are needed in mind, then the chances of premature optimisations may go up along with those of the required ones
Reminds me of using Ruby ten years ago and having to contend with folks who wanted to default to using the string literal style over another because it was known to be more performant at scale. That awkward stuff surfaces earlier with some languages than with others.
> I should also acknowledge: there is a perf hit from using Wasm versus pure-native tools. So this could be another reason native tools are taking the CLI world by storm, but not necessarily the browser frontend.
I didn't know about this before, I wonder how much overhead?
The reason I am reluctant to rely on JS tools for anything CLI is because of Node.js instability due to version sensitivity and impossible-to-fix-without-reinstalling-the-os low level LibC errors.
Compared to go, rust, or python, the odds that any given CLI.js program will run across my (small) fleet of machines is very low, by factor or 10x or more compared to alternatives. Some boxes I don't want to reinstall from scratch every 4 years, they're not public facing and life is too short.
Deno is fixing this with their standard library and JSR.
JavaScript is a terrific language: more ubiquitous than BASIC ever was; nearly as easy to learn and use as Python; syntax that is close to Java/C/C++. And it only uses 10x the CPU and memory of C or C++.
I'm not sure if JavaScript supports it, but some Python libraries allow you to choose whether to install a more optimized binary version or the pure Python implementation.
For example, if you install psycopg you'll get a pure Python implementation which is easy to debug and hack. But you can also install psycopg[binary] to obtain a faster, compiled version of the library. https://www.psycopg.org/psycopg3/docs/basic/install.html
That typically means two totally different implementations, and pure Python versions are often unusably slow, so it doesn't help much to hack that.
While the skeptical's stall in decision making, new comers who do not think twice about rewriting. Rewrite software on a smaller budget in experimental attempts. Then management decides to chose the cheaper option available, because lean startup is promising. Then in next 10 years the new comers become the new skepticals. I don't know if there's a case that this cycle is not repeated, at any time frame.
I've read your comment several times and still don't know what it means. Can you clarify?
I've rewritten it for clarity: "While the skeptics stall in decision making, newcomers will not think twice about rewriting software on a smaller budget as an experiment. Then management will decide to choose the cheapest option available, because the lean startup was more competitive. Then in the next 10 years, the newcomers become the new skeptics. In my experience this cycle is always repeated, albeit across different time frames."
I made the difficult choice to rewrite it in English again, even though French might have been more performant.
Thank you so much, you taught me how to express this "albeit across different time frames". It is difficult to use any language to simplify complex narrations.
Imagine developers as the choosing (management) part and if you are involved with webdev in last decade. Compare webpack and vite. As pricing parameter consider the time to bundle (faster=cheaper). So, what webpack did not do by not rewriting itself, vite came in offering.
If you want to steel man _for_ writing in Rust or Zig or Go, previous discussion here: https://news.ycombinator.com/item?id=35043720
Yeah, i agree. I think there is a time where rewriting in a faster language is useful (just like how handcrafted assembly is still a thing), but most of the time you are very far away from the point where that is neccesary.
I also think there is an element of, "rewrite in rust" is just easy to say, where changing data structures or whatever requires analysis of the problem at hand.
It is analogues discussion to C vs Rust. Sure Rust is memory safe, but whole ecosystem I am using today is C based. Compiler, SDK, drivers, RTOS, ... Nobody sane is going to rewrite it for the sake of rewriting it into a different language.
I would disagree with that comparison. Rust really does provide an improvement in memory safety that is hard to achieve by other means. That's not to say you should always rewrite in rust, there are plenty of situations where that doesn't make sense. However its not analgous to the performance situation in my opinion.
Sometimes it seems that people who write these kinds of pieces forget that not everyone in the world does web or even web-adjacent work, and node.js is something we don’t even consider to be part of our ecosystem. Rewriting useful things in non-JS has the benefit of letting folks like me who avoid JS like the plague use useful tools. Stop assuming everyone wants to get anywhere near the JS ecosystem: I’ve gone 30 years without touching it, and plan to continue that streak. Rewriting stuff is great from my perspective.
> Stop assuming everyone wants to get anywhere near the JS ecosystem
The author is writing about JS ecosystem tools.
> Stop assuming everyone wants to get anywhere near the JS ecosystem
I have been dragged, through straight misrepresentation, into the Node.js world.
OMG, awful hardly begins to touch it.
I have not used Go, but as far as I can tell every thing the Node.js people do is done better in Go.
I do not recommend Rust. I have a lot of experience with Rust, and unless you actually need the real time responsiveness it will bog you down.
The biggest reason to be skeptical is that these tools are not open to extension in the same way that JavaScript is.
Webpack has an enormous community of third-party plugins, it would be very hard to do something similar with e.g. Go or Zig.
Right, because tooling is standardized in eg Go. There’s no custom build pipeline, transpilation hell, or experimental language features that are selectively enabled randomly. I’m not even against JS, like at all, and I think the majority of perf issues can be resolved. However, JS tooling is the prime example of where things get truly nightmarish from a software development perspective. Webpack being a perfect example of this horror.
It's also a breeding ground where the best ideas often end becoming a sort of standard not only for javascript devs but for other langauges as well.
Well curious as to what some of these ideas might be.
NPM has done a pretty great job of showing everyone else what to avoid doing.
The mere mention of “web pack” sends most of the FE devs I’ve met into borderline trauma flashbacks.
There’s seemingly half a dozen package managements tools, some of which also seem to be compilers? There’s also bundlers, but again some of these seem integrated. Half of the frameworks seem to ship their own tools?
You can ship a 20MB Go program and no one blinks.
Go programs start at 20MB. The Go AWS Terraform provider is something like 300MB.
A massive amount of the complexity/difficulty in webdev build tools space has to with optimizing delivery sizes on the web platform.
Node.js tooling is straightforward comparatively.
This is funny to me. Go and zig are built with the Unix shell in mind - the most extensible and modular system around.
The webpack ecosystem on the other hand is it’s own OS.
Maybe for some the appeal of JS is in (hopefully) never having to learn Unix?
I’ve heard several folks say that about Kubernetes, but in my experience the *nix core always resurfaces the second things get weird.
That certainly can be a benefit. But as we see here it also limits your thinking to that ecosystem.
Can you now write client and server js code without installing npm? I guess you'd be reinventing a lot of wheels that the packages provide.
> For another thing: it’s straightforward to modify JavaScript dependencies locally. I’ve often tweaked something in my local node_modules folder when I’m trying to track down a bug or work on a feature in a library I depend on. Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Yeah, JavaScript is sloppy, but you can always monkey-patch it by modifying tool-controlled files. Great idea. Not.
JS is just not a good language. The JIT and the web of packages made it slightly more usable, but it's still Not Good. There's no real way to do real parallel processing, async/await are hellish to debug, etc.
It's unavoidable in browsers, but we _can_ avoid using it for tools. Look at Python, a native PIP replacement improved build times for HomeAssistant by an order of magnitude: https://developers.home-assistant.io/blog/2024/04/03/build-i...
> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.
Or you could use the source code already downloaded by a package manager and do similar tweaks locally with the build manager picking them up and compiling for you
IMO the biggest win when Phoenix switched to esbuild wasn't about _speed_ exactly, it was about not having to install&debug things like node-gyp just to get basic asset bundling going.
> I’ve written a lot of JavaScript. I like JavaScript. And more importantly, I’ve built up a set of skills in understanding, optimizing, and debugging JavaScript that I’m reluctant to give up on.
It's not that hard to do the same for a less terrible language. Choose something markedly different, i.e. a low level language like rust, and you will learn a lot in the process. More so because now you can see and understand the programming world from two different vantage points. Plus, it never hurts to understand what's going on on a lower level, without an interpreter and eco-system abstracting things away so much. This can then feed back into your skills and understanding of JS.
I think we’re reading too far into the authors impostor syndrome.
He’s making contributions in Rust already. His opinion isn’t invalid just because he has a bias, he opens by acknowledging his bias.
Hopefully the lot includes that writing stuff in low level languages isn't worth the pain most of the time.
Curious what you mean by "most" (I'm agnostic/unlearned on the statistics tbh). I "feel" like it doesn't happen too often when it's not either already low-level or the supposed extra performance is likely worth it.
Like, I can't imagine most people using Javascript would want to rewrite in Rust without some decent reason.
> It's not that hard to do the same for a less terrible language.
I miss that brief era when coding culture had a moment of trying to be nice, of not crudely shooting out mouths off at each other's stuff crudely.
JS, particularly with typescript, is a pretty fine language. There's a lot of bad developers and many bad organizations not doing their part to enable & tend to their codebases, but any very popular language will likely have that problem & it's not the languages fault.
It's a weakness & a strength that JS is so flexible, can be so many different things to different people. Even though the language is so so much the same as it was a decade & even two ago, how we use it gone through multiple cycles of diversification & consolidation. Like perl, it is a post-modern language; adaptable & changing, not prescriptive. http://www.wall.org/~larry/pm.html
If you do have negative words to say, at least have the courage & ownership to say something distinct & specific, with some arguments about what it is you are feeling.
I’d normally agree with you, but JS is more or less designed to be terrible. It was hacked together by Brendan Eich in literally 10 days, who originally wanted to do something more Scheme-like. It was a quick and dirty hack that got stretched way beyond what it was even meant for.
It then literally had decades of ECMAscript committee effort to shape it into something more useable.
I could repeat the numerous criticisms, but there’s enough funny videos about it that make a much better job pointing out its shortcomings and, sometimes, downright craziness of it.
> but any very popular language will likely have that problem & it's not the languages fault.
No, sorry, just no. I get where you are coming from, but in the case of JavaScript, its history and idiosyncrasies alone set it apart from many (most?) other languages.
Perl for example was made with love and with purpose, I don’t think it’s comparable.
JS wasn’t created in 10 days. It was prototyped in 10 days, and the prototype contained very little of the stuff people complain about.
Hillel Wayne posted about this recently:
https://www.linkedin.com/posts/hillel-wayne_pet-peeve-people...
Okay, I stand corrected. So this prototype didn’t ship, or did it ship and evolve?
Brendan Eich himself calls JS a “rush job” and with many warts though, having had to add aspects that in retrospect he wouldn’t have. This snippet from your link is consistent with that:
This anecdote about the double equality operator might have originated from Eich's chat with Lex Fridman where he states (at about 5 minutes and 26 seconds) that during the original 10 day sprint JavaScript didn't support loose equality between numbers and strings: https://www.youtube.com/watch?v=S0ZWtsYyX8E&t=326s
The type system was weakened after the 10 day prototyping phase when he was pressured by user feedback to allow implicit conversions for comparisons between numbers and serialized values from a database. So it wasn't because he was rushing, it was because he caved to some early user feedback.
The implicit type conversion is good for a very funny conference video ("wat") but man, it's just so overplayed as a weakness especially versus how much real world impact it has on anyone.
And with TypeScript or linting, many of the strange comparison/conversion issues go away.
I struggle to find any substantial arguments against the js language, in spite of a lot of strong & vocal disdainful attitudes against it.
The implicit coercion and its weird behavior is absolutely a major footgun, not just fodder for the “wat” video. It’s something that can get you into serious trouble quite easily if left unchecked, for example by just looking at a list wrong. For someone to say that it has never caused them surprising pain in plain JavaScript is probably disingenuous. This is something that most other languages plainly don’t have as a problem, at least not as baffling.
Other things worth mentioning are the unusual scoping (by default at least), prototypes, “undefined”, and its role versus "null"... the list goes on.
I give TypeScript a lot of credit for cleaning up at least some of that mess, maybe more. But TypeScript is effectively another language on top of JS, not everyone in the ecosystem has the luxury of only dealing with it, and across all layers and components.
Is my knowledge about JavaScript outdated and obsolete? Certainly. Is the above stuff deprecated and turned off by default now? Probably. I left web development more than 10 years ago and never looked back. I’m a bit of a programming language geek, so I’ve used quite a few languages productively, and looked at many more. But not many serious programming languages have left quite the impression that JavaScript and PHP have.
In the meantime, I have always remembered that one conversation I had with someone who was an ECMAscript committee member at that time: They were working really hard to shape this language into something that makes sense and compiles well. Maybe against its will.
EDIT: Dear god, I completely forgot about JavaScript’s non-integerness, and its choice of using IEEE 754 as its basic Number type. Is that still a thing?
I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.
OP is a Servo contributor
> Any application that can be written in JavaScript, will eventually be written in JavaScript. - Jeff Atwood (2007)
i swear some non js devs will go to extreme lengths to demonstrate solutions that will never run on another machine instead of writing js
Why would they never run on another machine? It's not that hard to write portable code, and done very often. Nowadays for example, you rarely ever think about whether you're on arm or x86.
If you write non-portal code, there might be an important reason (like writing OS components, which you won't do in JS).
almost every time code doesn’t run on my machine, the root cause is a political disagreement with a c-compiler author three layers below my actual problem.
javascript doesn’t have a compiler is my main point.
Bit rich to complain about that when all the major browsers have just as significant differences, and that’s before we bring node into the equation, let alone talking about a good 30% of websites I visit with any quantity of JS in them are either perpetually broken in some way, or so jank as to be effectively broken.
totally agreed about all of the above and i take credit for none of that code
i write plaintext at uris, progressively enhance that to hypertext using a port with a deno service, a runtime that unifies browser js with non browser js.
that hypertext can optionally load javascript and at no point was a compiler required aside from the versioned browser i can ask my customers to inspect or a version of deno we get on freebsd using pkg install.
node is not javascript would be my biggest point if i had to conclude why i responded.
microsoft failed at killing the web with internet explorer and only switched to google’s engine after securing node’s package manager overtly through github and covertly through typescript.
microsoft is not javascript is my final point after circling back to my original point of microsoft is also one of the aforementioned reasoned c-compilers are politically fought over instead of things that just work.
It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? I guess not making tools for say, c# devs in c# would also be bad?
> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS?
Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though.
The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts.
That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.
Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.
Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough.
Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.
It's funny you mention C# since VS Code is a perfect example of JS devs rewriting existing tools in JS.
> I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.
The JStockholm syndrome.
I also love JavaScript.
It's true, it has some really bad parts but you can avoid them.
If I could design the perfect language for myself, it would have the syntax of JavaScript and the portability of JavaScript but it would use Python's strong duck typing approach.
What have static type systems ever done to you, that you avoid them so much?
Not the OP, but the appeal of languages like JS has a lot to do with developer productivity. I write gobs of JS and Python code and the finished programs and libraries can be strongly and statically typed end-to-end. I just don't want to be forced to do it in cases when it doesn't really make a difference, and I don't want to waste time on it when I'm still figuring out the design.
My hope is one of the Next Big Things in programming languages is the widespread adoption of incremental typing systems.
So during the early stages of dev you get the productivity benefits of dynamic and loose/duck typing as much as you want, and then as the code matures - as the design firms up - you begin layering in the type information on different parts of the program (and hopefully the toolset gives you a jump start by suggesting a lot of this type info for you, or maybe you specify it only in places where the type info can't be deduced).
Then those parts of the program (and hopefully eventually the entire program) are strongly and statically typed, and you get all of the associated goodies.
most static type systems are verbose, probably due to linguistic verbosity, so one obvious thing that static type systems have probably done to a lot of people is given them pain from typing so much.
Not sure what languages you are thinking to with "most static type systems", but in languages like TypeScript or Rust (and I guess modern Java/C#, haven't touched those in a while), most of the types are inferred by the system such as you don't need to write them. You type your functions arguments (and return values in Rust) and that's about it.
I don't feel it's so much typing. Especially for the clarity and, most importantly, safety and correctness I get back. I'd rather type 3 1/2 seconds more than debug a dumb type issue for half an hour.
It gets really old to get something like "NoneType does not have blah" in a deeply nested, complicated data structure in python, but obviously only at runtime and only in that hard to hit corner case, when all you did is forget to wrap something in the right number of square brackets in some other part of the code.
I haven't fully given up on python, but I only deal with it using mypy, which adds static typing, anymore.
A bit of extra verbosity as added by static typing can also be immensely helpful for trawling through and/or learning an unfamiliar codebase, especially in the absence of an IDE or debugging environment (e.g. browsing code on GitHub or in a filemanager).
For instance, take function definitions. By just adding types to the function's arguments, you're potentially saving the reader a ton of time and mental overhead since they don't have to chase down the right the chain of function calls to figure out what it is exactly (or is supposed to be) that's getting passed in.
JavaScript isn't really all that portable? Heck just making it run on the different JS engines and runtimes is a big pain sometimes
I can't even figure out how to write typescript that conditionally uses browser-only or node-only libraries depending on which environment it's in. My current best guess is to write 2 completely independent typescript projects that happen to point to the same source files?
Let me cross-compile a C++ project any day ...
This guy is not competent to talk about what he's talking about.
>"JavaScript is, in my opinion, a working-class language. It’s very forgiving of types (this is one reason I’m not a huge TypeScript fan)."
Being "forgiving of types" is not a good thing. There's a reason most "type-less" languages have added type hints and the like (Python, Typescript, etc) and it's because the job of a programming language is to make it easier for me to tell the CPU what to do. Not having types is detrimental to that.
It's not forgiving of types at all. Reality is not forgiving of type errors. The only thing JavaScript does is move the moment where you find out reality is not forgiving of type errors to when your code is running in prod rather than at compile time, and makes them more implicit. That doesn't make it a bad thing per se to be forgiving of type errors. For example, if you really like fixing errors in production rather than before pushing them to production, this faux forgiveness is precisely what you should be looking for. It's all up to personal preference. Personally, I prefer knowing early on if there's problems with my code, and having a higher degree of certainty regarding it working or not.
All of this is under the assumption that whatever you're writing has some degree of complexity to it (an assumption which is satisfied very quickly). Five line python glue scripts don't necessarily benefit from static typing.
> There's a reason most "type-less" languages have added type hints and the like (Python, Typescript, etc)
I would like to clarify that even without typing python is a LOT less "forgiving of types" than javascript. It has none of the "One plus object is NaN" shenanigans you run into with javascript.
Types are guidelines and strictly useful and a good thing. That said, one can wonder why languages like basic, python, scheme or php (dynamic, implicit types) have grown popular. Maybe for bad reasons but there IS an added value for implicit types. C++ (maybe even C !) has grown the auto keyword and other typed language have type inference. Which is not the same as "typeless" (it always is typed) but it defeats one of the "double check" security of types. And it's sometimes not needed (yes, if I initialize it with "abc" it may be a string)
sure. one is strongly typed and the other weakly typed.
Python is not "type-less" it is strongly typed. It will raise a TypeError if you do something like 1 + "1".
Please, preferring dynamic typing is not a sign of "incompetence". Stop this nonsense. Also, I won't question your competence because you called Python and JavaScript "type-less". The type-less languages (other than assembly) that were ever used were BCPL and B (predecessors of C).
There are plenty of good things written in languages with weaker type systems than TypeScript (Linux, your browser, HN). Using C/C++ or a dynamic language doesn't immediately make you incompetent.
while I'm a fan of TypeScript and using type hints in Python from an autocomplete and linting perspective, I am curious...
... has either language leveraged these to better tell the CPU what to do? presumably for perf.
PHP does but the types actually mean something. If your types can be stripped out to make the program run, I have a hard time believing that there is any optimization occurring there.
python ignores type hints
Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.
Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.
As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.
> Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.
This is one of the biggest falsehoods in the software engineering I know.
Language is a collaboration glue and influences way of thinking guiding solution development. As an analogy: you can make a statue from a glass or from ice, but while both can be of the same shape and be equally awed upon, the process and qualities will differ.
For the prototypes and throwaways context doesn’t matter - That’s why all short lived contests, golfs and puzzles ignore it. Yet, when software is to be developed not over the week but over the decades and (hopefully) delivered to thousands if not millions of computers it’s the technological context (language, architecture, etc.) that matters the most.
Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. Sometimes it really is the programming language.
In the JavaScript world a lot of speed up comes from 3 major things as far as I can tell:
- easier concurrency. - the fact that things are actually getting rewritten with the purpose of speeding them up. - a lot of the JS tooling getting speedups deals with heavily with string parsing, tokenizing, generating and manipulation of ASTs. Being able to have shared references to slices of strings, carefully manage when strings are copied, and have strict typing of the AST nodes you enable things to be much faster than JavaScript.
Python is really really slow compared to JS though.
Node is so slow to start that python script can complete before Javascript even begins to execute.
For extremely simple scripts maybe. I get around 70 ms difference in startup time.
I once worked on a Python system that had 50 machines dedicated to it. We were able to rewrite it in a more performant language such that it easily ran on one machine. This also allowed us to avoid all the issues distributed systems have.
So yeah, Python is not great for systems programming
CPython is (though it's slowly getting better). Pypy is amazingly fast
This is a very nice counterexample, but it's not actually a counter example without an example.
Also, this was a thing before Rust. I've rewritten several things in C or Cpp for python back ends, and most pytbon performance-critical code is already an API to a shared library. You'd be surprised to run OR tools and find Fortran libraries loaded by your python code.
Ruff is one example https://astral.sh/ruff
But can I write plugins for it? My understanding it is only implements a subset of the common plugins (and does not do any of the linting that pylint is useful for), so it avoids scanning the filesystem for plugins?
Choosing the right algorithm effectively means optimizing runtime complexity. Then, once runtime complexity is fixed with the right algorithm, you're still left with a lot of constant factors that O-notation deliberately ignores (it's only about growth of the runtime). Sometimes, optimizing those constant factors can be significant, and then the choice of language matters. And even some details about the CPU you are targeting, and overall system architecture.
Often languages like Javascript and Python don't allow optimal runtime complexity, because the types baked in to external interfaces fundamentally disallow the desired operation. And these languages are too slow to rewrite the core logic in the language itself.
(but of course, the vast majority of the code, even in widely used tools, isn't properly designed for optimization in the first place)
I only dabble in javascript, but `tsc` is abominable.
> Lots of very smart people have worked very hard on Python tools written in Python
Yes, I agree that is very sad
Python is achingly slow. I know the Python people want to address this, I do not understand. Python makes sense as a scripting/job control language, and execution speed does not matter.
As an application development language it is diabolical. For a lot of reasons, not just speed
> Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster.
So?
Some tool got written and did its job sufficiently well that it became a bottleneck worth optimizing.
That's a win.
"Finishing the task" is, by far, the most difficult thing in programming. And the two biggest contributors to that are 1) simplicity of programming language and 2) convenience of ecosystem.
Python and Javascript are so popular because they tick both boxes.
Don’t disagree about finishing the task, but personally I don’t find more performant languages any less productive for the sort of programming I tend to do.
Congratulations on being a programming god. This discussion isn't for you.
From my point of view, I'm happy if I can convince my juniors to learn a scripting language. Okay? I don't care which one--any one. I'd prefer that they learn one of the portable ones but even PowerShell is fine.
I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language.
Those folks who program but don't know a scripting language far outnumber the rest of us.
> I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language.
> Those folks who program but don't know a scripting language far outnumber the rest of us.
What domain are you in? This sounds like the complete inverse of every company I've ever worked at.
Entire products are built on Python, Node ect, and the time after the initial honeymoon phase (if it exists) is spent retrofitting types on top in order to get a handle, any handle, on the complexity that arises without static analysis and compile time errors.
At around the same time, services start OOM'ming left and right, parallellism=1 becomes a giant bottleneck, JIT fails in one path bringing the service performance down an order of magnitude every now and then etc...
> Congratulations on being a programming god. This discussion isn't for you.
On the behalf of mediocre developers everywhere, a lot of us prefer statically typed languages because we are mediocre; I cannot hold thousands of implicit types and heuristics in my head at the same time. Luckily, the type system can.
Quite the opposite, for most cases you don't hit the scale where asymptotic algorithmic performance really makes a big impact (e.g., for many small set comparisons, iterating over a list is faster than a hash set, but only by 10-50% or so), vs switching to a compiled language which instantly gets you 10x to 100x performance basically for free.
Or perhaps another way to look at it, if you care enough about performance to choose a particular algorithm, you shouldn't be using a slow language in the first place unless you're forced to due to functional requirements.
And anyone who expands the horizon to the real world, instead of focusing on the artificial one of contests, knows that the language matters a great deal
In higher level languages your code may allocate memory or trigger a GC pass or other smartness in unexpected places. This may cause slowdowns you may not have control over or may change from version to version or vendor to vendor. It is often easier to manage in "faster" languages. Good algorithm may not be enough.
The types of problems in those contests are meant to highlight algorithms. In the real world you might have a trivial algorithm but a huge input size, where the constant factor matters much more.
Here’s the thing: languages like C#, Java and Rust all have extensive libraries and packages that implement many common data structures and algorithms well. With all due respect to the incredible work that goes into projects like lodash, JavaScript does not. (Nor does C, for that matter.)
That's why almost every thing important in python is in C
> knows that the language doesn’t matter so much as your algorithm.
I know what you’re referring to but these problems have also taught me a lot about language performance. python and JS array access is just 100x slower than C. Some difficult problems become much harder due to this limitation.
JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.
> JS is easily within magnitude of C
Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.
In benchmarks JS is usually well within magnitude (i.e. under 10x slower).
E.g. C++ vs Node.js here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Couldn't find C vs JS easily with the new benchmarksgame UI.
> Couldn't find C vs JS easily
Try:
A) Find JS in the box plot charts
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
or
B) Find JS in the detail
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I guess so. I clicked on the code for the first one. It’s using a C library to do the computation:
> mpzjs. This library wraps around libgmp's integer functions to perform infinite-precision arithmetic
And then the “array”:
> Buffer.allocUnsafe
So is this a good JavaScript benchmark?
That's the only benchmark on the page that uses such wrapper.
Buffer.allocUnsafe just allocates the memory without zero-initializing it, just like e.g. malloc does. Probably usually not worth it, but in a benchmark it's comparable to malloc vs calloc.
Yeah and using byte buffers isn’t JavaScript array access. But it is for C.
The n-body looks most like canonical JS to me. It’s a small array, but’s it’s accessed many times.
Unfortunately the c++ version is simd optimized, so I don’t think that’s a fair comparison.
I'd guess using typed arrays or even normal arrays wouldn't slow the code much, and the slowdown will be probably a small constant factor.
If the JIT detects the array as homogenous it will compile it to low level array access. JS JITs are very good.
There are plain C++ programs: n-body C++ g++ #3
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It's not just a matter of “picking the correct algorithm”. Algorithmic-interview exercises are algorithmic-interview exercices. They are barely related to real-world software engineering.
While picking the right algorithm seldom comes up in most programmers day-to-day activities, being aware of big-Oh and the performance guarantees/characteristics of the libraries you use most certainly should.
I don't care if you don't know how to write a merge sort from scratch. I do care about you knowing not to write an O(n^2) loop when it can be avoided.
I don't.
Let me rephrase that.
I do, but only in very, very rare circumstances. Basically only when you a) know that the typical use case is going to involve large ns, like millions to billions, b) the loop body takes a long time per invocation, or c) have profiled a performance issue and found that improving it would help.
If you're working with sets of 10 items, just write the damn nested loop and move on. Code jockeying is unlikely to be faster, and even if it is, it doesn't help enough to matter anyway.
Computer science theory likes to ignore constants. Big-O notation does that explicitly. But in the real world, it's usually the constants that kill you. Constants, and time to market.
> If you're working with sets of 10 items
If you are working with a hardcoded 10 items, and you are certain that won't change significantly, sure.
If not I strongly disagree, because I've seen way too often such cases blow up due to circumstances changing.
Now, if it is very difficult to avoid a nested loop then we can discuss.
But it can simply be due to being unaware that some indexed library call is in fact O(n) or something like that, and avoiding it by using a dictionary or some other approach is not hard.
While constants matter to some degree, the point of big-O is that they don't so much if you get handed two orders of magnitude more data than you expected.
I'll gladly sacrifice a tiny bit of performance for code that doesn't suddenly result in the user not being able to use the application.
Choosing the right algorithm is usually the prerequisite for fast code. Optimizing the constant factors is often pretty useless if you pick an algorithm with a runtime that grows quadratically, when there are much better options available.
What makes you think that the sluggishness of these tools is in any way related to not “choosing the right algorithm”?
What makes you think they're not? I don't know why these tools are sluggish, but I disagree with the notion that algorithms don't matter for "real-world software engineering".
The world is full of slow software because one chose the wrong algorithm: https://randomascii.wordpress.com/2019/04/21/on2-in-createpr... https://randomascii.wordpress.com/2019/12/08/on2-again-now-i... https://randomascii.wordpress.com/2021/02/16/arranging-invis... ...
Exactly. What do you do when you have the right algorithm and it’s too slow (very typical for linear problems that require visiting each item).
You optimize the constant factors, e.g. the runtime of the inner loops. But this requires you to choose a sane algorithm in the first place.
Some problems are much more complicated, where you have to take, for example, locality (cache hierarchy etc.) and concurrency considerations like lock contention into account. This may affect your choice of algorithm, but by the time you reach that, you've almost certainly thought about the algorithm a lock already.
[flagged]
[flagged]
I’ve worked on some huge nodejs projects, it’s a great language for “serious projects”. It has costs and benefits like any other language. If you use TypeScript then IME many of the costs are mitigated.
What exactly makes JavaScript so unsuitable?
> What exactly makes JavaScript so unsuitable?
Pretty much all the usual, boring offenders everyone's familiar with: truthy/falsey, errors passing silently, exceptions, and differences in importing behaviour with bundlers and runtimes. These things are admittedly quite simple to fix when it's your code, but when you multiply that by 1000 dependencies, which is a conservative number for a JS project a whole host of difficult to detect issues will rear over time.
> If you use TypeScript then IME many of the costs are mitigated.
TS meaningfully helps, but it still falls short of the mark imho. Turning on 99% of TS lints to error is the only solid way I've found to prevent a lot of the issues I've encountered. But that's really hard to introduce into existing codebases. It's doable, but with a lot of friction and effort.
> What exactly makes JavaScript so unsuitable?
If you look at JavaScript's history (especially for backend development), it reads like a series of accidents: First, the JS language was hacked together at Netscape in the space of a few months in 1995, and after that it was quickly baked in into all web browsers and therefore became very hard to change in a meaningful way. Then, Google developed the V8 engine for Chrome, and someone thought it would be a great idea to use it for running JS in the backend. My thoughts on that were always: "just because you can do something doesn't mean that you should"...
In addition to what is mentioned by the other comment, also threading and io.