Simultaneously too confused to be able to make their own UX choices, but smart enough to understand the backend of your infrastructure enough to know why it doesn't work and excuses you for it.
The morning national TV news (BBC) was interrupted with this as breaking news, and about how many services (specifically snapchat for some reason) are down because of problems with "Amazon's Web Services, reported on DownDetector"
I thought we didn't like when things were "too big to fail" (like the banks being bailed out because if we didn't the entire fabric of our economy would collapse; which emboldens them to take more risks and do it again).
A typical manager/customer understands just enough to ask their inferiors to make their f--- cloud platform work, why haven't you fixed it yet? I need it!
In technically sophisticated organizations, this disconnect simply floats to higher levels (e.g. CEO vs. CTO rather than middle manager vs. engineer).
I only got €100.000 bounded to a year, then a 20% discount for spend in the next year.
(I say "only" because that certainly would be a sweeter pill, €100.000 in "free" credits is enough to make you get hooked, because you can really feel the free-ness in the moment).
> In the end, you live with the fact that your service might be down a day or two per year.
This is hilarious. In the 90s we used to have services which ran on machines in cupboards which would go down because the cleaner would unplug them. Even then a day or two per year would be unacceptable.
Last actually note-worthy improvement I heard of was properly supporting import/export (although do you still need to use the .mjs hack?), but I've been out of the loop here for sometime so would be nice to know what they've added since.
Sounds like the obvious correct solution, making .cjs and .mjs obsolete - unless of course someone uses import() statements exclusively, in which case I need to ask: why?
It is surprising for me to see these features finally being added to Node after such a long time. Especially so when I remember reading discussion after discussion about how something like this wasn't possible. I touched on this in a blog post some time ago [1]. Glad Node is catching up.
I don't see in your blogpost any sources cited regarding anyone saying that ES modules were infeasible.
Additionally, io.js actually forked off due to internal drama which started with Ben Noordhuis having changed some pronouns here and there and people wanting to cancel him for that, to which he picked up his toys and left the sandbox.
It so happened that aside from being competent himself, he had competent people on his side, which eventually forced those governing Node.js to concede.
using, memory64, undici, async local storage, ESM import improvements, type stripping, local storage / session storage, env file support, built in file watching. Those are just the ones I mainly remember. There is a lot more.
> Currently the best PG driver[1] depends on a single guy.
Definitely a problem, but funding good Postgres/MongoDB/SQLite should be handled by AWS, Microsoft, Google, and other orgs that sell database services.
>> Currently the best PG driver[1] depends on a single guy.
> Definitely a problem, but funding good Postgres/MongoDB/SQLite should be handled by AWS, Microsoft, Google, and other orgs that sell database services.
A good chunk of PG development is done by employees of those companies (*). Of course they could (and probably should) always do more. But even if they invest more, it's not obvious that the marginal effort is best invested in some language's drivers...
Disclaimer: I'm paid by one of those big companies.
It's an issue, but not a new issue and not an issue introduced by NPM or introduced by package managers.
People were cuddling and pasting code from random people on the Internet they didn't understand for many years before package managers where there were zero maintainers. Many people that don't properly understand supply chain issues still are.
As a quick aside, “them” is an object pronoun, not a subject pronoun. The correct word you needed is “they”.
You couldn’t phrase your original question as a statement “Them have though.” That’s often a quick test for valid English grammar. With the correct pronoun, it makes more sense: “They have though.”
As another example, take this sentence: “Have you seen them though?”
“You” is the subject of that sentence, and “them” is the object.
It's short for "Have them [Node bozos improved it], though?"
Or, equally likely it, refers to deno and bun ("deno and bun has really made Node focus and improve", "Have them (deno and bun) really made Node focus and improve, though?")
Did you do hot updates? I ser that is mention in the post, but I thought the community has walked away from it? Or at least that its mixed feelings about it?
Hmm, context matter a lot. Im not sure on what you consider large development projects, so maybe its even bigger then what I'm thinking on. But getting the apis between apps up and ready early and getting a working setup from the database team to the frontend teams and apps teams trough some kind of backend/api team has always proven to be the correct choice for me. Also getting it as fast as possible on to a production server so its just the dns missing from beeing in production help so much for testing and highlights bug and other problems between teams. So the author mostly talks about this from a code perspective, but IMHO its even more important on larger teams.
(Sidenote: having this kind of architecture where you create layer of deps from one team to another is a bad idea from my point of view, but is still done a lot)
It's a scale. On the one extreme you have solo development, on the other you have the gargantuan code bases at e.g. Google, or the Linux kernel.
What you're describing is somewhere in the middle (if you imagine a logarithmic scale), it's at a point where working like a solo dev begins to break down especially over time, but not at a point where it's immediately catastrophic.
Startups sometimes work in that sort of hybrid mode where they have relatively low quality code bordering on unmaintainability, where they put off fixing its problems into the future when they've made it big.
I think a big big reason for that there is no Big tech companies in Europe is really that the landscape is so much more diverse then in the US.
If you are big in one state in the US. You have the same lang and most likely the same regulations. In Europe its so many languages and its no more likely that we choose a company from another country in the EU vs the US.
I think that is not true for the US. So its easier to get big in the US, and then you are so big its actually likely the a company in the EU would choose you. Maybe not over another company from the same country (everything else beeing equal), but over a company from another country in the EU/Europe
I guess darklang was too far ahead in their thinking in some areas and choose the wrong path for other. I really liked the deployless idea, but would have loved in even more on-premise. No way to get the data to stay in Europe.
Making hard connections between the editor and the lang was interesting also. Seems like they have moved away from that.
Hope there is a easy way to set it up locally, i was really intrigued when they first launched
Yes, the next version will be able to set up locally - you'll be able to install a single Darklang binary and run any darklang program without any further steps. See the explanations on https://darklang.com homepage.
The issue with the hard connection between the editor and language is that each change becomes a massive undertaking. Making a language improvement was much much much simpler than making the editor change to support it.
It was a bit hard to understand what is coming and what deprecated. As soon as i went into documentation I was send to "darklang classic".
How are the deployless senario now? Where you first serve only yourself then your team, then beta, then everyone... Or something similar to that. I really liked how that story was told and how much complexity it removed
Being the best European AI company is also a multi billion business. Its not like China or the US respects GDPR. A lot of companies will choose the best European company.
Great point. I regret not being more systematic about this. I have tried on most popular models since gpt 3.5 launched, but it’s all been very ad hoc with the same general approach of building up a language feature by feature.
