• 0 Posts
  • 116 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2024

help-circle
  • thiserror helps a bit with conciseness. But it’s still the most annoying part of writing Rust for me, even more annoying than async closure capture semantics, and one that I happily offload to deepseek whenever I have to write it. I was even thinking of making some insane proc_macro that would traverse a function and extract the list of all ?, deduce the types, and come up with the final error type (maybe with some hints). But this turned out to be too difficult for a weekend project and ain’t nobody wants to pay me to write it.

    Type-safe: can’t beat errors as enum values wrapped in Result.

    I’m talking more about the anyhow-style here. It’s not very type-safe.

    Composable: i don’t think you can beat rust enums in composability.

    Well, thiserror-style enums are composable-ish, but they can be too structured for their own good. Sometimes you want only a particular property of an error (e.g. one of the HTTP requests returned 429 or something), and don’t care about the particular branch of the call tree it came from. Rust doesn’t really have the compile-time flexibility to write such a check without a ton of boilerplate that will also break once the call tree changes.


  • I am well aware, I wrote quite a lot of Rust, including professionally. I’m not necessarily talking about the “clear happy path”, even though that is relatively nice to have (Rust sort-of allows that with the ? sugar and the pseudo-functor and pseudo-monad methods on wrappers); I’m talking more about the fine line between the overly verbose lists of all the errors that a function could produce (thiserror-style) or just a single messy error type that makes error handling difficult (anyhow-style). There surely must be something in between there that is concise, type-safe, and composable, but I haven’t seen it in any language yet.



  • In the very old times, you’d have to be born rich already to do maths. You then don’t concern yourself with making a living, because your slaves do it for you.

    In the old times, you’d live the same as artists: find a rich dude (exceptionally rarely: dudess) to pay your bills, and in exchange name shit you discover/invent after them.

    Last few decades you also have a couple new options. You can work (teach) at a university for pennies, and typically have a second job/side hustle so that you can actually survive. And/or you can write books/make a YT channel, and if you’re lucky and get popular enough, that can be your living then, but it’s probably not going to be anything too advanced. And/or, if your area of expertise has some vaguely practical application (e.g. cryptography or statistics), you can actually find a job that pays you to do theoretical research in that area in hopes of finding practical application, but you’d have to be pretty lucky to get that.


  • Nah, social division of labour is almost as old as civilization itself. It’s not possible to do everything by yourself, if you’re lucky enough not to die of hunger in a few weeks, you’ll die of a preventable disease within a few years.

    Capitalist exploitation of it (combined with faux individualism) is the issue.

    Translating to this scenario, there would be no issue if we had community kitchens with cheap/free food and well-paid workers. The issue is the capitalists extracting surplus value from a basic necessity, partly by convincing everyone to hate their neighbours and eat alone.







  • The intended use-case is for bit-banging, i.e. sending electricity to places according to certain algorithms. Think about simple automation, like the control chip in your washing machine which executes the selected program by sending enable/disable signals to the water pump, valves, and the motor. Well, the same basic principles could apply to a lot of industrial processes and such, helping us rebuild the civilization.

    It would also be really fucking great for helping post-collapse engineers do various calculations. Those chips are really slow by modern standards, but insanely fast compared to an abacus, a slide rule, and a sheet of paper.

    BTW there’s also dusk OS, which follows similar principles but is targeted for more advanced hardware, like the abundant x86 and ARM chips. It has a way more user-friendly interface, a basic GUI, filesystem drivers, and IIRC even networking capabilities, all possible to run on a PC from the early 90s. It also has great bootstrapping flow, allowing you to rebuild itself from source, flash itself to other computers, and flash Collapse OS onto microcontrollers.

    Basically like a Linux install with all the dev-tools and sources already there, except much simpler, to the point that you probably can figure out how every component of the system works yourself, and fix issues when they happen. This knowledge will also directly translate into writing programs for collapse OS, because they share the programming language and many OS paradigms.