When you start getting hate, you’ve made it. Up until then you’re a hypothetical that people like. Maybe they’ve built a side project with you or read the docs. You only get hate when people have used your tool and butted up against limitations. We saw this with Deno too where they went from beloved potential savior to realistic, limited tool. Hate is good. It means people rely on you
Do you know which project gets the most hate? Nodejs, so in that sense, Nodejs has made it and it is widely deployed but this hate was the reason that two seperate alternatives for Node have emerged as Deno and bun.
Recently Bun's latest version had memory leaks which crashed production code from my understanding and their attitude[0] of saying OSS will have no human contribution allowed, now doing these ports of zig to rust, going back for years what the decision making of using zig was and this code basically being vibed as there is no way that they are reviewing the code while being VC funded/bought by anthropic.
These are all genuine issues which cause hate. You can say people are hating because people rely on it but the true thing is that also seems like a bait and switch and that people switched from node.js to bun (maybe even being locked inside bun), only for them to do these highly questionable decisions which is the reason why people are starting to hate on bun.
Atleast that's my interpretation right now reading this whole thread.
Well yeah, it's in Zig, not a memory-safe language, so of course I'd expect memory leaks. That's why I haven't seriously used bun and instead use a runtime that actually is in a memory-safe language, Deno in Rust. It's like wearing roller skates without brakes and wondering why you keep running into things.
Both can be true? You can be doing really well and still have long term risk. Dethroning incumbents takes longer than people think and it’s possible that search growth goes 20%, 10%, -10%, -50%
A fun counter factual: try “proving” that famous scientists are their collaborators based on this methodology. Obviously Hardy and Littlewood are the same person. They’re both British mathematicians who use analysis and number theory and have similar sensibilities in politics and math.
The Hardy-Littlewood comparison cuts the other way. Two collaborators in the same subfield sharing terminology is the baseline, not evidence of anything. What makes the Back case interesting is convergence on things that have nothing to do with cryptography: the same Napster vs Gnutella analogy, the same celebrity email filtering idea, the same obscure FDR gold ban interest, the same weird hyphenation errors. Pick any two cypherpunks at random and you won't find that kind of overlap on non-technical quirks.
Then add the negative space. Back was one of the most prolific voices on these lists for a decade, especially on digital cash. Satoshi shows up, Back goes quiet. Satoshi leaves, Back comes back. Hardy and Littlewood never had that problem.
>the same Napster vs Gnutella analogy, the same celebrity email filtering idea, the same obscure FDR gold ban interest, the same weird hyphenation errors
Dunno it assumes their cypherpunk group must always discuss strictly cryptography and never discuss anything else. It could be just some off-topic ideas floating around in their community.
For me, the only solid, damning evidence would be statistical methods of text analysis like they do to prove authenticity of a literary work.
I’ve proposed that someone open a restaurant of invasive species. You could make some decent dishes with lionfish, blackberries, golden oyster mushrooms, venison, etc
Agreed. I was skeptical of Deno and I think their package management story was a mistake. But the people were still trying to make JavaScript better and doing so out of genuine love for the language. I especially feel for the employees who put in several years of their life, with the resulting opportunity cost.
I'm not fully convinced that there's a tenable model for open source devtool companies. Usually there's some handwavy plan to do hosting or code quality that never comes to fruition. Hosting is a hard business and the 800 pound gorilla in the room of AWS is even harder to surmount. Otherwise, I'm not sure what business model you can look towards. Support maybe?
People want open source software, but they do not want the compromises that come with funding it. When people try and fail then you get shitty blog posts like this one. It's sheer entitlement. I think the days of building open source tooling and expecting to be able to commercialise it are now completely gone.
Yeah, I mean Deno’s success is predicated on enterprises moving production apps from NodeJS to Deno. Node is extremely established and entrenched, and migrating the goddamn runtime of a large production server is not usually an easy project. If I have a 5-10 year old Node project, it might work well on Deno, but almost no one has the time to champion a migration when it just doesn’t have that many benefits.
Yes, it comes with batteries included, but a big node project already has setups handling things like testing, linting, formatting, and dependencies. Moving to Deno for any of those might actually be easy, but migrations in the JS ecosystem never end up being easy, so people who could sway the company to change tools don’t have the appetite to tell leadership about migration projects with minimal upside and unknown duration. And under a startup with an unknown future.
NodeJS succeeded at undermining existing server toolchains, because web devs were easily sold on writing JS for their servers, so tons of successful startups built with Node, and when Node got pretty well established, it was easier to adopt for greenfield projects in the enterprise.
Deno is Node, but better. So it’s not giving a whole market of devs access to a tool that is way easier to write for. It’s marginally easier to manage and you could maybe drop some other toolchain dependencies. But again, those toolchain things are automated/hidden away from developers directly… like they don’t care we use eslint, they just care CI catches problems before they hit prod and that the linter throws an error early in the process. It’s already easy for them to run locally. So it’s not like Deno lint changes anything about the dev user experience, it just changes what DevOps/platform teams have to manage.
> If I have a 5-10 year old Node project, it might work well on Deno, but almost no one has the time to champion a migration when it just doesn’t have that many benefits.
We inherited a 10+ year old production system with node and react; it made by a succesful company that made it with vc money in a short time and then got acquired; the system has grown to 100s of 1000s of lines of js (no ts). It runs on a cluster of VPSs on ancient versions of everything.
It took me 3 days to rewrite it to typescript and deno with zero vulns by prompting cerebras glm 4.7 with basically 'port this to modern ts, drizzle and deno' and then opus in claude code to make it work and fix it. It uses playwright mcp to test all flows; it runs production now instead of the old version; no issues so far.
Also, the 3rd day was only on writing REST and Playwright tests on both versions so we could compare if everything works the same.
And essentially one of the reasonings behind it was that people weren't taking support or buying templates etc. from tailwind because they were getting essentially both of these from LLM's.
Open core can work, but you really have to find very strong product market fit on the proprietary side--ideally with features that discriminate between users who are relatively happy to pay and users who are not. (There's a reason "SSO tax" is so common.)
And you really have to believe in open source and have the discipline to keep investing in it, otherwise the temptation is ever present to throw more and more effort and resources into the proprietary parts.
"Become integral enough to the toolchain at OpenAI or Anthropic that they buy you" seems like the new one. Normally I dislike startups built with the intention to be acquihired instead of being a sustainable business, but with open source devtools maybe that's not the worst thing. I'm pretty confident that neither bun nor uv will stop existing anytime soon, and the makers got paydays out of it.
That is incredibly short sighted though as OpenAI or Anthropic themselves are struggling to make money themselves and are on incredibly shaky foundations themselves.
> I'm pretty confident that neither bun nor uv will stop existing anytime soon, and the makers got paydays out of it.
If OpenAI stocks let's say IPO and then fall 70% (because hey a business is well, a business at the end of the day), do you suppose they will still keep the folks at uv?
Sure, its good for the makers who get paydays but they are quite far and few and this doesn't feel like a strategy much to me to rely on.
If Open source needs to thrive, we might need a better strategy long term perhaps.
I wonder if it's almost like a new version of management consulting. You hire/invest in a bunch of smart 20-somethings who seem generally intelligent with the idea that they'll "disrupt" an industry with their from-first principles approach. Do the 23 year old McKinsey consultants particularly care about their work? No, but the McKinsey name is a fast way to gain clout and access to executives. Ditto the YC name
For what it’s worth Ruby’s JIT took several different implementations, definitely struggled with Rails compatibility and literally used some people’s PhD research. It wasn’t a trivial affair
I really want to host a vibe coding competition and see what can actually be made with these systems. Like if we’re doing insane token spends, it better be in service of creating amazing stuff. Can we make an entirely new programming language? Can we make an OS?
The guy to watch here is https://github.com/Dicklesworthstone . He's rewritten SQLite in Rust with fixes, written his own Rust async engine with fixes that Tokio doesn't have, generated an insane number of tools for agentic orchestration (indexing of all sessions across all harnesses, on-demand skill storage, agent mail), and is currently building out agent orchestration terminal multiplexer stuff.
Source: been watching both these guys closely, as I've been building my own agent factory focused on security + learning: https://github.com/mieubrisse/agenc
Possible, yes. Easier? I tried to search for YouTube videos of people doing amazing things at blazing speed using Gas Town about a month ago, and couldn't find any. I for sure didn't want to spend hours reading and learning something that I don't know if it even works?
Does anyone have like, projects built using it? I couldn't find "look at the output" types of videos or articles or repos, only "look at the input" types of posts about it.
The 15 year old here used gas town to build a Simon game, but for learning Morse code. It's intended for phones. Still needs documentation touched up a bit.
Scroll the game panel up a bit, turn off the mute button and click start game. A Morse code letter will be played, key it back on the iambic keyer. Pad 1 is for dits. Pad 3 is for dahs. (Dots and dashes for those new to Morse code.) Get it right and the game plays that letter and another random letter back out to you. After successfully sending each sequence back to the game, you get a one letter longer sequence. Just like the handheld Simon game. Link's below
Forgot, use wired headphones or speaker. Bluetooth delay wreaks havoc adding delays to Morse code sidetones. Like trying to learn piano with delay between tapping key and hearing tune
That’d also be an interesting data point! What’s the upper limits of vibe coding? Can you vibe code rust? What about an entire programming language toolchain? How about an ecosystem? Can you make a parallel npm?
That would be awesome to see! If there was some prize pool like $5,000 to build an operating system through vibe coding tools only and then people could stream themselves on twitch and you could have "sorts desk" type commentators who are collating all that together. I'd watch that and donate a hundred bucks.
In all honesty, if you scoped this well, one of the big players in the LLM space could definitely host a big marketing event on this spin. Get together a bunch of well known industry folks, have them vibe code a working <thing> in a given time constraint, presentations and prizes, lots of marketing.
I am designing one, aimed at Claude Code and other AI Coding Agents, and getting the first version lex/parser/compiler was an afternoon project. It was initially a TypeScript toolchain generating TypeScript code.
I keep adding things here and there, a couple hours everyday. Then after about a week I decided to switch the toolchain from TypeScript to Rust, how much work? A 5 minute planning session and a ~20 minutes implementation phase.
reply