I find the irreverent tone refreshing, personally.
As a founder who built all my prototypes and side projects on Deno for two years, I personally think Deno’s execution was just horrible, and avoidably so. Head-scratchingly, bafflingly bad decision-making.
I was the first engineering hire at Meteor (2012-2016), and we made the mistake of thinking we could reinvent the whole app development ecosystem, and make money at it, so I have the benefit of that experience, but it is not really rocket science or some insight that I wouldn’t expect Ryan Dahl and team to have, in the 2020s.
They were stretched thin with too many projects, which they were always neglecting or rewriting, without a solid business case. They coupled together runtime, framework, linting, docs, hosting, and packaging, with almost all of these components being inferior to the usual tools. The package system became an absolute nightmare.
If the goal was to eventually replace Node and NPM with something where TypeScript was first-class, there was better security, etc, they could have done a classic “embrace and extend.”
Pivoting to node support and even more-so rewriting deploy really hurt momentum on top of all those projects. Coming out swinging with 2.0 and then decreasing regions and rewriting the product that makes you money soon after was certainly a choice.
While they’ve been doing that void 0 made a significantly better linter & formatter that can replace eslint, a perfect embrace and extend. Nodes improved and a lot of annoyances have been ironed out (at a user level at least), each passing day the benefits of deno reducing.
Fresh is close to abandonware despite being a framework that could be the middle ground between htmx and js framework insanity with even 1 man-day a fortnight dedicated to it.
JSR seems like it’s going nowhere and only exists to install @std.
This was the final straw for me, if they bounce back in a few years hell yeah I’m in but I’m begrudgingly back to node for now.
This piece starts off making it sound like the computer is pretty much doing all the work, while the human maybe weighs in on a matter of taste once in a while, if they like, but by the end, the list of what the LLM can actually do is really short. Implementing a sorting algorithm for you, perhaps, but not necessarily one without “egregious flaws,” and really you should still use a library for that. Replacing high-quality libraries of mature software, that have tests, etc, is obviously one of the poorer uses of vibe-slop coding.
It comes down to “adding code” that attempts to, or seems to, achieve something.
I always interpreted cathedral vs bazaar as being about the architecture of large things. Do you build to a master plan? Or does everyone do whatever they want? (Within some kind of framework, of course.) Like the cathedral of the Java SDKs vs the flea market of NPM.
This author seems to have some kind of attitude about organization in general—anything with people and process, that happens to exist around some project, that might require at least a small commitment to be a part of. Like complaining that a flea market has a form to sign.
The ability for people to functionally collaborate, with some kind of structure, is the key thing that enables building large things together.
Microsoft is a robust business, with corporate contracts going back 40 years. There are going to be exceptions and winners, and microsoft is probably a winner
Have you noticed how rapidly Microsoft is setting its own brands on fire? Most recently by abandoning the brand "Microsoft Office" and renaming that product to "Microsoft 365 Copilot App" instead.
A curly brace is multiple tokens? Even in models trained to read and write code? Even if true, I’m not sure how much that matters, but if it does, it can be fixed.
Imagine saying existing human languages like English are “inefficient” for LLMs so we need to invent a new language. The whole thing LLMs are good at is producing output that resembles their training data, right?
Upvoted because educational, despite the AI-ness and clickbait.
I’ve worked at orgs that used Postgres in production, but I’ve never been the one responsible for tuning/maintenance. I never knew that Postgres doesn’t merge pages or have a minimum page occupancy. I would have thought it’s
not technically a B-tree if it doesn’t.
As a founder who built all my prototypes and side projects on Deno for two years, I personally think Deno’s execution was just horrible, and avoidably so. Head-scratchingly, bafflingly bad decision-making.
I was the first engineering hire at Meteor (2012-2016), and we made the mistake of thinking we could reinvent the whole app development ecosystem, and make money at it, so I have the benefit of that experience, but it is not really rocket science or some insight that I wouldn’t expect Ryan Dahl and team to have, in the 2020s.
They were stretched thin with too many projects, which they were always neglecting or rewriting, without a solid business case. They coupled together runtime, framework, linting, docs, hosting, and packaging, with almost all of these components being inferior to the usual tools. The package system became an absolute nightmare.
If the goal was to eventually replace Node and NPM with something where TypeScript was first-class, there was better security, etc, they could have done a classic “embrace and extend.”
reply