• 2 Posts
  • 41 Comments
Joined 4 months ago
cake
Cake day: December 16th, 2024

help-circle
  • Isn’t that sort of just the cost of doing business in C? It’s a sparse language, so it falls to the programmer to cobble together more.

    I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.









  • Yeah, the article comes off as needing so much context that the article itself is sus. Like

    Hejlsberg stated the obvious when saying that TS isn’t the fastest language. Although it can laughably run Doom at 0.0000009645 fps.

    … which is referencing an implementation of Doom in the TS type system. It’s a funny idea, but an arbitrary reader who doesn’t know about that and doesn’t bother clicking through will get a very wrong impression.

    The reimplementation (which they’ve done partially automated; Go apparently lets them do a very simple translation while Rust or C# would require more work to fit) should be a boon for TS devs, but not noticeable for those who just run stuff that happens to be written in TS.

    Would be kinda interesting to see the effect if stuff targeted deno rather than node, though.


  • One rather obvious reason is that society has a lot of greybeards in general. The baby boomer generation was named that for a reason, and people have been living longer on average. Lots of countries are struggling with the demographic effects. There’s no reason to expect that tech or something even more specific like FOSS would be exempt.

    Another aspect here is that FOSS is still kind of new in society. There’s just more people who have had the chance to age into FOSS greybeards than when those greybeards were young. (And they were thus likely to a lesser degree blocked by entrenched greybeards when they were getting started.)





  • I’ve moved on from vim to neovim, and I think I’ll continue using something in that family in the future. It’s a pretty stable experience overall, but the inclusion of LSPs and tree-sitter have been good improvements too.

    Ultimately editors are tools, similar to keyboards, os-es, screens, chairs, shoes and so on. There are some objective quality differences between a well-constructed tool and some slapdash nonsense, and there are a huge amount of subjective quality differences. What suits me may not suit you, and vice versa.

    It’s generally good to try out some new (to you) stuff and see if you like it. If you do, great; if you don’t, well, now you know. I think my worst experience was with Acme (or Wily? can’t remember), during a phase where I experimented with Plan 9 stuff. Ultimately very not my cup of tea, but apparently Rob Pike (who made it) and some other gophers still enjoy it? Which is good for them, just like it’s good for me that I can choose not to use it. It’s just personal tastes, and I still think it’s good that I gave it a go.

    The debate over holding down modifier keys vs modes is also a part of the Emacs vs vi debate from many decades ago. There might be some statistics for what works best for the most people now, but again, use what suits you. And try some new stuff when you get curious, it’s generally good for you.






  • It’s ultimately up to oneself to decide these things for oneself, but there is literature on the topic. Part of it you can just frame like the stories themselves: Is it worthwhile to read or watch a story unfold, rather than just read a summary? Is there any point to anything that ends? You know a good meal with your loved ones is going to end before you sit down—but you still choose the meal over going hungry and alone. Because the experience has value even if it ends. Some experiences are even valuable because they only existed a brief moment in time.

    There are, ultimately, some stories that are so mired in despair and suffering that anyone would close the book early, but most of the stories are kind of trudging along, with their own motivations, hopes, fears and joys.

    To quote another work on the topic: One must imagine Sisyphus happy.



  • Quotes are OK, shellcheck is happy, but, according to gtfobins, you can abuse tar, so running the script like this: ./test.sh /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh ends up spawning an interactive shell…

    This runs into a part of the unix philosophy about doing one thing and doing it well: Extending programs to have more (absolutely useful) functionality winds up becoming a security risk. The shell is generally geared towards being a collection of shortcuts rather than a normal, predictable but tedious API.

    For a script like that you’d generally want to validate that the input is actually what you expect if it needs to handle hostile users, though. It’ll likely help the sleepy users too.