This being said, I don't think there is any requirement technically that every core method can also be re-implemented in Ruby... There are so many methods that are just thin interfaces to something written in C, whether because they are touching VM internals, or for perf reasons, or because they make system calls or call external libraries.
It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way.
I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;
Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.
So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.
I had a long conversation with a fellow parent sitting next to me at soccer practice today. Never met her before in my life, but we just started chatting about soccer logistics, and then I just started asking her about her life. I learned about her 5 kids, her tough relationship situation with her spouse of 16 years, her having moved here from Arkansas as a child, her feelings about how gentrification damaging local communities, her dream of moving out of the USA to another country, how there are the same kinds of social problems most places, how we can come to empathize more with our parents as we get older, and probably more things too I'm not remembering. These are the kinds of things you can talk about if you happen to have good rapport with someone and they feel like it...
I won't say I have conversations with strangers like that all the time, but it is 100% possible, and a lot of people really do appreciate it if you bother to talk to them. People often like being asked about themselves (I used to do cultural anthropology research so I have had quite a bit of practice too...).
There are of course reasons why it doesn't always work or becomes awkward. For example, gender is a factor - a significant part of the population is much more comfortable having same-sex conversations with strangers - not to mention other sociological factors around race, class, nationality, all the obvious things.
Counterpoint: I thought it was a useful analysis — I was very disappointed when the local Joann's closed and this added a bunch of context I would not have had otherwise.
I realized early on in my enterprise software job that if I produce code faster than average for my team, it will just get stuck in the rest of our review and QA processes; it doesn’t get released any faster.
It feels like LLM code gen can exacerbate and generalize this effect (especially when people send mediocre LLM code gen for review which then makes the reviews become painful).
I thought this was a really good piece of writing. It’s rare to do something like this because the job discourages it by putting PR filters on everything you say.
My uncle was a pretty big pop star in the 1960s. His group at one point had a big fanzine, they were household names across the country, over time they had stalkers and weird fans and all that, made movies and albums, had big parties and knew other famous people, pretty much all those things that the OP writes about (circa 50 years later, some of it has changed but not that much).
He could be charismatic and surprisingly eloquent and I could picture him writing a piece like this, if the mood had struck.
He also lost pretty much all the money through mismanagement (several times over), eventually moved out of LA, had a tumultuous family life with numerous spouses and wasn’t around much for his kids, and after his 40s was trapped in a sad cycle of reunion tours because the band still needed the money. The tours still had some level of excitement and crowd enthusiasm, even pretty late in life and I guess he always loved the stage, the performing, all that. But in the end, I kinda felt it seemed like a lonely existence. Hard to form really deep connections when you’re always traveling and often away in your head.
I misinterpreted the title and was hoping that this was going to be a post about realtime algorithmic music generation from the Postgres WAL, something like the Hatnote “listen to Wikipedia edits” project.
Agreeing with most of the other comments here that this discussion needs more context which we don't have...
If the request for additional access controls/access cleanup came from one of the Ruby Central funders, could we not know who that was and what exactly their ask consisted of? I am interested in knowing their side of the story, and what the motivation was. (But in general, cutting off long-time maintainers' access seems like a bad choice - as presumably they have long since proven their good will toward the ruby community as shepherds of these projects.)
I have a toy web application that accepts a very, very low rate of writes. It's almost all reads.
It is implemented like this:
- The front end uses react to draw a UI.
- It fetches data from a JSON file stored on S3.
- When we get a write request, a lamdba function reads the JSON file, parses it, adds new data, and writes back to S3.
The main selling point for me is that almost all of it is static assets, which are cheap and simple to host, and the tiny bit of "back end" logic is just one nodejs function.
The previous implementation used SQLite and a golang back end, but I eventually got tired of having to maintain a virtual machine to host it.
“If the devotion scholars feel toward their work is intense and sometimes irrational, it’s because this is one of the last spaces of unalienated labor”
Speaking as a former academic, I don’t really agree with this — I think academia can make you believe wrongly that it’s a kind of “unalienated labor,” but actually the alienation runs deep, all the deeper when it’s invisible at first glance.
Yes, you don’t have to make something that is sold to customers or that fits in a JIRA ticket. But when you stop and think about it, you’re going to be doing research based on topics and paradigms that other people have largely defined (advisors, peers); you have to publish in journals that are often for profit and pay you zero; when you teach you usually don’t get paid all the tuition that your students are paying per course (the institution takes a big cut); you end up doing a lot of silly things to have a solid institutional position… TLDR, it has great moments of course, but it isn’t unalienated.
Remind me to stick to my hyperlocal fast food restaurant that only has one location and probably doesn't record every conversation you have with them or use any of the other gross surveillance technology that was recorded here.
The story is really about two things. Their poor information security is pathetic, but their actual surveillance tech is genuinely kind of politically concerning. Even if it is technically legal, it's unethical to record conversations without consent.
To be clear - this isn't an endorsement on my part, just observations of why cloud-only deployment seems common. I guess we shouldn't neglect the pressure towards resume-oriented development either, as it undoubtedly plays a part in infra folks' careers. It probably makes you sound obsolete to be someone who works in a physical data center.
I for one really miss being able to go see the servers that my code runs on. I thought data centers were really interesting places. But I don't see a lot of effort to decide things based on pure dollar cost analysis at this point. There's a lot of other industry forces besides the microeconomics that predetermine people's hosting choices.
Regardless of the cost and capacity analysis, it's just hard to fight the industry trends. The benefits of "just don't think about hardware" are real. I think there is a school of thought that capex should be avoided at all costs (and server hardware is expensive up front). And above all, if an AWS region goes down, it doesn't seem like your org's fault, but if your bespoke private hosting arrangement goes down, then that kinda does seem like your org's fault.
> Information loss is an inherent property of large organizations.
That's such an interesting axiom, I'm curious if you would want to say more about it? It feels right intuitively - complexity doesn't travel easily across contexts and reaching a common understanding is harder the more people you're talking to.
Yeah, I think TFA gets a lot right about doing software engineering in large orgs.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
https://decasia.org/tech/2026/02/raise-not-a-reserved-word.h...
This being said, I don't think there is any requirement technically that every core method can also be re-implemented in Ruby... There are so many methods that are just thin interfaces to something written in C, whether because they are touching VM internals, or for perf reasons, or because they make system calls or call external libraries.