Login
You're viewing the discuss.systems public feed.
  • Oct 14, 2026, 1:37 PM

    To explain what I mean by this: for a long time the Perl community took great pride in how difficult and terse the language was. The old joke that well-written perl was indistinguishable from line noise wasn't just a joke, it was a badge of honour.

    That attitude was sustainable when the internet was small and alternatives were scarce. But the moment tools appeared that prioritized things like human ergonomics (python) and human interaction (ruby) the perl community started aging out and dying.

    💬 5🔄 5⭐ 0

Replies

  • Oct 14, 2026, 1:48 PM

    Today the number of people under 50 who'll reach for perl or raku or who cares what it's called as their first choice of tool for anything new is zero. In practice Perl is an esolang now.

    Torvalds' position is that contributing to the kernel should be _more_ difficult for everyone else, but, through LLM usage, easier for existing kernel developers.

    Ted Tso's adamant position that "you can't make us learn Rust" is the same insularity.

    If the kernel was a country, we'd recognize this.

    💬 5🔄 7⭐ 13
  • Oct 14, 2026, 2:00 PM

    There are plenty of good alternatives to driving your community off a cliff like a gaggle of demographic lemmings, but if you're still convinced that mailing lists and insularity are the path to durability in this godforsaken year of our lord two thousand and twenty six then I'm not sure what words will convince you that there's nothing past the edge of that cliff but sharp rocks and seawater.

    If your community isn't accessible and welcoming to new, learning participants, the clock's ticking.

    💬 4🔄 17⭐ 54
  • Oct 14, 2026, 2:14 PM

    And for Linux as a plausibly community-managed meaningfully open as in open project, that clock is definitely ticking.

    The end of this road is some corporate-funded retirement home for understaffed and underfunded projects once enough of the current devs have aged out without anyone growing into those roles, with private forks at companies that relied on the kernel, also privately relieved there's no need or reason to deal with antediluvian developer processes or bother giving back anymore.

    💬 2🔄 2⭐ 0
  • Oct 14, 2026, 2:23 PM

    Anyway, funny story but remember when the discussion was about The Cathedral and The Bazaar?

    There's a second axis to that graph, and it's ends are labelled "A Community" and "A Cult".

    💬 1🔄 7⭐ 1
  • Oct 14, 2026, 3:20 PM

    @mhoye the demographic parallels are spot-on. My quippy take has been for a while that if a project/community/company hasn’t undergone and thrives after a change of top leadership, it’s still immature.

    Sounds like that immaturity will persist into old age for most of the popular things these days.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:22 PM

    @mhoye I don’t know that it matters if it’s hard to contribute with the amount of funding surrounding the kernel being so vast. It’s also telling that “contribute” in this context is usually restricted to a very small subset of contributions (that is: shipping code and enduring abuse from code maintainers)

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:22 PM

    @mhoye Linus and his posse have been elitist unwelcoming jerknobs for decades though. If an alternative were to appear, I agree that people would leave them to wither and die. But so far no reasonable alternative has appeared. *BSD, Plan9, etc have all failed to gain traction.

    💬 3🔄 0⭐ 0
  • Oct 14, 2026, 2:26 PM

    @hal_pomeranz If it's up to me to pontificate, I think it will happen sooner than people might expect. It will either an explicitly anti-AI OS like NetBSD or a pure fork that focuses on a welcoming community and modern tooling.

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 5:14 PM

    @mhoye @hal_pomeranz hardware support is I guess the biggest stumbling block. A few years back someone in .. I think? .. the redox community was talking about running linux in a VM to use its drivers with hardware passthrough, then copying data back and forth. The *BSD world seems to have the "rump kernel" idea as a similar thing. I'd love to see something like that, I wish I still had the energy & skills to attempt to contribute :(

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 14, 2026, 6:38 PM

    @hal_pomeranz @mhoye indeed, the moat of Linux was always hardware support, which was there because people got paid to make it happen. Community isn’t a competitive advantage until you have software most folks can even run on their machines. Linux being anti-community is nothing new, as you pointed out. It’s being run as a business, and from what I can tell quite a profitable one. Perl of course had nothing like that.

    That’s not to defend any of that. It’s just… what it is.

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 5:11 PM

    @mhoye I have many deep criticisms of the modern kernel community, but conflating mailing lists with insularity might be a tough one to argue. Email is still just about the most widespread, open comms platform - most of the alternatives people jumped to instead were more or less proprietary. Isn't the issue more a failure to build better tooling on top of that platform? (Which tbf a fair amount of effort in recent years has been going into remedying.)

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:19 PM

    @mhoye the kernel is a country and it is the united states of america which is actively waging war upon another sovereign state

    💬 1🔄 2⭐ 0
  • Oct 14, 2026, 2:24 PM

    @hipsterelectron @mhoye you know, I keep beating parts of this drum in conversations with euros

    all this "sovereign" tech talk and yet all of them do not seem to have done the slightest bit of analysis on transitive dependency chains

    "sovereign distribution, built in europe on european infra" -> look under the hood -> ubuntu

    one of the best examples I reach for: "what happens the day you can't reach qemu/kvm source anymore?"

    💬 2🔄 1⭐ 0
  • Oct 14, 2026, 2:28 PM

    @froztbyte @mhoye it puzzles me frankly particularly the rust part. rust is a microsoft fucking product now but nobody listens to packagers about bootstrap deps. i used rust for 10 years and made the zip crate the safest and fastest zip impl ever and i cannot contribute code to that system again until gccrs is complete

    💬 2🔄 0⭐ 0
  • Oct 14, 2026, 2:35 PM

    @hipsterelectron @mhoye ito puzzlement, my thesis as to how we got here is: 12~15y of "developer ease"

    over the years of flush vc cash shartups, so much focus has shifted from the _outputs_, instead moving to the _personal_. many good engineering things got traded out, simply to "be comfortable"

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 2:39 PM

    @froztbyte @mhoye having worked on python packaging until they suddenly released "oh wait this guy is going to make things actually good" web.archive.org/web/2025021815 and then having astral steal credit for my work and sell to openai and then seeing uv pop up fucking EVERYWHERE having fucking EVERYONE rave about HOW FUCKING FAST IT IS when I FUCKING DID THAT SHIT—i think labor needs rights and protections

    💬 2🔄 0⭐ 0
  • Oct 14, 2026, 6:49 PM

    @mhoye @froztbyte @hipsterelectron fun fact I was using uv to manage things for a work project (idek why I normally use poetry) and then found out they ship Tk support but they don't bind with Xft which means the fonts look fucking awful

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 7:06 PM

    @hipsterelectron @froztbyte @mhoye This shit right here is why I am not working on my seL4/Idris crap in public. Giving your shit away to comrades is fundamentally different from giving your shit away to the people in the power structures above you, and we need a way to encode and defend that distinction before we can have free software that doesn't feed the monsters.

    💬 1🔄 1⭐ 0
  • 💬 0🔄 0⭐ 1
  • 💬 1🔄 0⭐ 0
  • Oct 14, 2026, 7:22 PM

    @hipsterelectron @froztbyte @mhoye Yeah, your work sounds awesome and I am only pursuing the route I am because it seems like a good fit for my relatively limited abilities. These are the pieces I can see and use, and things feel like they are on fire right now so I'm doing what's in front of me. seL4 is juuust beyond the already-available, and I can reach that. You're reaching farther than I am; one day maybe I'll be building atop your work, but laying that groundwork is beyond me.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 14, 2026, 6:57 PM

    @mhoye @hipsterelectron @froztbyte recently I started trying to make a pure Rust Nixpkgs style bootstrap. Assuming you have a Rust compiler binary because that's a given we accept for C ++ (I think an older version of GCC was the only pure-C implementation that was reasonably modern? Less confident on that I thing there might be a C based EDG thing).

    But guess what? That's nearly impossible even assuming you start with a binary! First you have to use Cranelift (still billed as experimental, doesn't ship unwinding by default because it possibly bloats binaries though I didn't encounter it) because otherwise you need C++ for LLVM. And even then you don't have an assembler which you need. So okay you write that because I don't think any currently exist.

    And then I'm sure you hit some new issue but that's where I stopped for now.

    Meanwhile somehow, incredibly, even with the rise of LLM produced projects redoing all kinds of things (I get it, it's a fun exercise) nobody has made a full C compiler in Rust yet. The closest is some Anthropic demonstrator that's been abandoned and isn't finished and a project @jyn started as far as I can tell.

    So even if you get there and want to bootstrap from C to a whole compiler chain afterwards to get LLVM support for your Rust, too fucking bad.

    I won't accept any issues people claim because you need a compiler binary I think it's arbitrary to allow the C++ compiler but not Rust, but holy shit if your language is going to be self hosting why on earth isn't that actually a full stack even on one platform?

    💬 2🔄 2⭐ 0
  • Oct 14, 2026, 7:06 PM

    @Lunaphied @mhoye @froztbyte @jyn gcc has a reasonably well-documented bootstrap path from C99. even if i'd like it to be shorter the project takes it seriously and discusses bootstrapping as a concern on the mailing list which i really appreciate. i'm looking to improve the story for emacs atm

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Oct 14, 2026, 7:30 PM

    @Lunaphied curious about this since that is generally my experience with gcc. personally my build system will be maintaining an entirely acyclic bootstrap path from C99 and i absolutely agree that should be a goal for every language

    💬 2🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Oct 14, 2026, 7:39 PM

    @wyatt @Lunaphied haven't heard this before and not quite sure of the distinctions but that should probably work. unfortunately i will be cheating by building the whole gcc bootstrap chain which since nobody does that may break in practice

    💬 3🔄 0⭐ 0
  • Oct 14, 2026, 7:42 PM

    @wyatt @Lunaphied possibly more concerned about OS support but i'm not gonna be doing anything non-POSIX and since i'm doing weird shit to virtualize i/o with patches to gcc i also won't require too much OS support for the fun parts

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 7:45 PM
    @hipsterelectron @Lunaphied the main difference for most people is using /* */ for comments

    you can use uint8_t and other "standard sized" things and just let the person define them per computer since c89 doesn't standardize them

    there are other differences but that gets you like 80% of the way there for no effort
    💬 2🔄 0⭐ 0
  • 💬 4🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 2🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Oct 14, 2026, 10:13 PM

    @wyatt @Lunaphied @navi @SRAZKVT i implemented functionality equivalent to #include with sed and then made a shell script compiler with more and more sed even though sed is obnoxiously limited and i realized i was building the shell language with built in parsing framework i had always wanted and then resolved to just make that language as a programming language instead of hacking it together

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 14, 2026, 10:11 PM

    @hipsterelectron @Lunaphied
    That's what I'm trying to do though I am adding shims to allow some C23 things to work even on a C99 compiler.
    ...
    Is shims the right word? I've seen the term "polyfills" used for the web but never seen it used for C versions.

    💬 0🔄 0⭐ 1
  • Oct 14, 2026, 10:17 PM

    @kirtai @Lunaphied as the lone remaining coffeescript contributor i would like to see "polyfills" as a term taken up more broadly. i would also argue "shim" to me evokes OS compat whereas "polyfill" tends to be associated pretty specifically with language versions

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 10:18 PM

    @kirtai @Lunaphied i have this awful idea about coffeescript for c i.e. a transpiler generating C89 because it would be terribly simple to implement rust's surprisingly basic unsafe mechanism

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 10:32 PM

    @kirtai @Lunaphied it also kinda pisses me off that lifetimes have such complicated inference machinery because it produces terrible fucking error messages and i don't actually want the compiler to infer lifetimes for me in the first place. i've also come to find the mutability restrictions incredibly obnoxious for the single type of code i write all the time i.e. buffered i/o and string search operations

    💬 1🔄 1⭐ 0
  • 💬 1🔄 0⭐ 0
  • Oct 14, 2026, 10:54 PM

    @kirtai @Lunaphied here's another thing i don't like about lifetimes which is that they're bound to a mysterious rust-specific concept that essentially translates to nested scopes in the form of stack frames, which like, fine, but rust leaves it to LLVM to actually calculate pointer provenance so information like "this returns a pointer from the same contiguous allocation as provided in argument 1" is not expressible as a type annotation

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 11:01 PM

    @kirtai @Lunaphied also coming from coffeescript where the only way to get any type safety at all (i actually implemented JSDoc type annotations which was heroic and nobody cares somehow) is to ensure you dereference a field by name from an enclosing object, it's remarkable to me that rust not only requires a macro to perform struct->field address offsets, but doesn't have a distinct type for "field name X from struct Y", or indeed "offset of some multiple of struct X from address A". these would be really useful to have as visible type annotations imho

    💬 1🔄 1⭐ 0
  • Oct 14, 2026, 11:06 PM

    @kirtai @Lunaphied one thing coffeescript does that is extremely important is variable hoisting at function scope which also happens to be required by C89 and i would argue is furthermore a really useful thing for a C transpiler to do (in my emacs i have a keybinding that compiles the current file to js and jumps to the corresponding point in the output and this would be very useful for C imho)

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 14, 2026, 8:03 PM

    @froztbyte @hipsterelectron @mhoye this question puzzles me because the nature of git is that every checkout is complete. “you won’t be able to run Rust’s CI” makes sense to me (because the infra is deeply tied to US companies) but “you won’t be able to get Rust or QEMU sources” doesn’t, there’s already so many copies of it.

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:22 PM
    @mhoye The "under 50" edit to this just feels like twisting the knife. It's not like it was inaccurate before, but then you had to make it worse.
    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:25 PM

    @fedward Sorry. We hosted a Perl users group meetup at my old shop more than a decade ago, and even then I was the only person under fifty in the room. And now, I'm not under fifty anymore.

    💬 1🔄 0⭐ 0
  • Oct 14, 2026, 3:47 PM
    @mhoye heh. Perl syntax never bothered me, and I still probably think about most programming problems as Perl problems, even if I'm using another language. This occasionally bumps me up against the ways other languages aren't as capable, flexible, or dwimmy as Perl, but I also have to be real about the fact that the gum I like just isn't coming back in style.
    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 3:52 PM
    @mhoye also I think almost everybody who regularly came to DC Perlmongers meetings in the day has moved on to other languages (if they're still programming at all), so it seems unlikely that even the olds who used to use Perl first would still make that choice.
    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 6:50 PM

    @fedward @mhoye I've started sometimes trying to length it but very much I treat it as an esolang >.> I do hear that Raku is actually quite genuinely good and fun though

    💬 0🔄 0⭐ 0
  • Oct 14, 2026, 2:19 PM

    @mhoye Skimming the report back (lwn.net/SubscriberLink/1099594) and I see “A properly trained LLM is a useful tool, but it takes a lot of time to reach that point.”

    If that’s true, then every commit that uses one or more LLMs should include specific disclosure of what model(s) including their versions since they change ALL THE TIME, as well as the prompts used (because that matters a lot!) But they are removing “Assisted-By” tag and you have to dig thru email to find out.

    💬 1🔄 0⭐ 0