Exactly. The audience used to be tinkerers, people who liked getting their hands dirty. Now it's mostly bros of one stripe or another (AI bros, finance bros, and so on).
The link 'past' in the top bar allows you to see the front page in the past.
From 2010 ... https://news.ycombinator.com/front?day=2010-10-04 that still looks similar (though I find it amusing that Ask HN: So what's new in the world of A.I.? https://news.ycombinator.com/item?id=1754134 is on the front page "... My prediction (heh pun intended) is that you see enormous changes in the field when processing by GPU's becomes much more available. There are some algorithms that are simply difficult to research because labs don't have access to fast enough machines. ...")
There's certainly been some broification and the various reddit exoduses have been shifting the average user a bit.
I do believe you've got your top color set to ff007f rather than ff6600 if you're forgetting what the site looked like then.
I've had plenty of people throughout my life express wanting to come over to my place and hang. There's definitely a social grace of how you'd phrase it, but it's not like it's some alien concept.
> Rewrite a bundler in Rust and you haven't only made it faster. You've also shrunk the pool of JavaScript developers who can maintain it. The new tool still looks like a duck and quacks like a duck, but it's a different beast altogether. Its internals retreat behind a black box that fewer people hold the keys to. The source may still be open, but the door to contributions is closing.
Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with.
It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript.
Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.
Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.
Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.
Why are people writing critical infrastructure in [any language]?
In reality, the tools this article is referring to were written in javascript because they could be and it was the best tool for the job (according to the people who matter: the people who did the work).
If someone wants to rewrite them for speed and/or to chase the next shiny language, that's fine with me, but let's not kid ourselves that there was something wrong with using javascript in the first place.
Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
> Using the right abstractions (including the right number of abstractions) and the right data structures and algorithms is always going to trump the constants language choice can optimize.
I was with you until this paragraph, which is straight up incorrect. Language choice absolutely matters if your goal is performance.
The most obvious counterexample is that the TypeScript team pretty much did a direct port from TS to Golang, without significantly rewriting their core algorithms or changing their data structures, and it sped up the TS compiler by 10X, which is an enormous performance improvement that would be silly to dismiss as just a "constant." This is because JS is a bad choice of language for implementing a fast compiler, primarily due to its poor support for multithreading.
I still think that rewrite was ill-advised. Yes they got a 10x speedup, but now it's unclear whether the JS tooling ecosystem lives in Go or Rust or JS.
Given that we've now got a three way language schism, the story for sharing data between processes isn't really solved. Data can move nicely within Go, but not between Go and Rust or JS. Tools like ts-morph also got left behind with no replacement.
I think that in retrospect the power of the JS ecosystem was all about plugins. It's plugins that make ESLint such a powerful platform that it still can't be replaced.
From the perspective of making a efficient platform for running plugins, JS actually is the most theoretically efficient implementation language! That's why, for example, VSCode put a bunch of work into moving its core state from C++ to JS, a change which brought them big perf wins and helped them beat out Atom: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
What do you mean when you say the "story for sharing data between processes isn't really solved"? My understanding of this is mostly academic because I don't personally mix languages all that often, but aren't there many established ways of communication between languages. You have IPC, unix sockets, FFI, protobufs, and other serialising/deserialisation formats. Not to mention the classic (but probably slightly overkill) move of spinning up a local HTTP server and using REST endpoints.
Yes, all those ways exist. I was more saying that if copying between structures processes using serialization is all you need, the JS ecosystem already has that.
The thing is if you need to do big expensive copies on the input or output it forces you towards a batch processing model, which is the opposite of incremental computation.
How fast could the TS compiler have been made without changing languages? We don’t know, they didn’t do that. It sounds like the main increase was from parallelism. While not exactly ergonomic, you can accomplish that with worker threads in js, and they are a good fit for a tool like the typescript compiler. They chose to change languages and parallelize, which is fine, but a lot of that performance was on the table for javascript as well.
> When did the love of learning disappear from this field?
Like 10 years ago? When you could get a 400k/yr job after a 3 month JS boot camp. The market got flooded with people who don’t care about making good stuff. Now it’s the “AI has commodified intelligence so why learn anything” crowd
Or just write faster JS using it's lower-level language features. Nothing about whatever collection of build tools the JS ecosystem uses "requires" rust/zig/c++/go for performance. It's a closed text transform problem.
The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.
I think there's a huge spectrum between "pokes around in source code occasionally" and "maintains critical infrastructure." Learning to read and understand the open source software that powers a lot of the toolchain is a big part of the development of a lot of engineers, and said toolchain mostly not being written in a language you're familiar with is a barrier to that (not an insurmountable barrier, but still a barrier, to be clear).
I agree with you that the juice is worth the squeeze here, but I don't think it's right to pretend that there's absolutely zero cost in terms of the learning pathway for the next generation of open source contributors and maintainers.
I had to laugh about the Tiger Beetle history when hearing about it on one of my podcast feeds.
Although it is now famously one of the Zig written production deployments, the founders thought JavaScript would be a great option to write a database server, like really?!?
> In the month of July 2020, we developed a prototype of TigerBeetle in Node as a performance sketch to measure the basic components of the design (batching, TCP protocol, cryptographic checksums everywhere, fsync journalling, in-memory business logic and hash table operations).
Anyone can make an account, though, and instantly access that content, so Elon doesn't really have any leg to stand on by claiming they're private. It's not the same as Cambridge Analytica scraping stuff you had to have certain privileges to see by tricking the system into granting those privileges.
Elon unfortunately may have a leg to stand on, because it doesn't functionally matter whether "anyone can make an account and see it". I don't believe any legal ruling to date has been fine with that distinction.
It depends what you mean by "not allowed". Breaking ToS isn't a crime, but you might be sued for damages, but how can they show there were any damages?
But if they ban the nitter operator surely you can't just bypass that ban legally by making a new X account. That there are bans and the operator has to bypass bans by pretending to be a new person I think that this makes it different.
It's like a club that checks ids to ban people. I wouldn't call that club open to the general public.
Tall order. The main Nitter instances were using tens of thousands of accounts to evade detection, IIRC. Adding money to the mix creates more legal liability and a paper trail towards people who can be sued.
It's much easier if thousands of people set up their own Nitter instances.
reply