[–] 2 points 6 months ago*

That is not just a book about how to "cut potatoes". That is "A Creative Cooking Guide for Exercising Knife Skills", using potatoes as a medium. Similarly, your Rust book is an book on concurrency using Rust as a medium, as per the title: "Low-Level Concurrency in Practice". Both are complex topics, and both have picked a medium. Thus, they do not necessarily reflect on the underlying complexity of the medium, though concurrency in Rust is a complex topic due to the fact that the core language itself does a lot of work to make it "safe". Async would probably be an even better example of that.

However, in the case of initialization in C++ and in the case of move schematics in C++, these are topics that are complex because the core language has been accumulating complexity for a long time, and because the language designers cannot afford to break backwards compatibility. Which makes implementing and using move-schematics in C++, as an end-user of the language, much, much more complicated than in a language like Rust, that did not have to bolt this behavior on top of an already complicated language. Similarly with initialization, where C++ has accumulated many, syntactically overlapping forms of initialization, for both member and non-member variables variables

  • source
  • parent
  • context
  • [–] 9 points 7 months ago (5 children)
    1. Crazy initialization That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I’ve never seen used in the wild.

    Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject: https://www.cppstories.com/2023/init-story-print/

    I plan to read it after finishing this 260 page book on move schematics in C++: https://www.cppmove.com/

  • source
  • parent
  • context
  • [–] 6 points 7 months ago (1 child)

    But GCC did not improve their error messages (much) prior to Rust, despite Clang's error messages comparing favorably to GCC even before Rust 1.0 was released, as for example discussed in

    https://gcc.gnu.org/wiki/ClangDiagnosticsComparison?action=recall&rev=1

    Rust itself is 14 years old, slightly older than above wiki page, and even back then it had great error messages, though they've also improved since. Here's a fun site where you can see how error messages have evolved through Rust's life:

    https://kobzol.github.io/rust/rustc/2025/05/16/evolution-of-rustc-errors.html

    It's only very recently that GCC has started to catch up, for example with some nice improvements in GCC 15:

    https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15

  • source
  • parent
  • context
  • [–] 17 points 7 months ago (1 child)

    What do you mean, he “admitted” that?

    It’s quite literally the first thing he wrote in his pull request to systemd:

    Stores the user's birth date for age verification, as required by recent laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.

    And the second paragraph of his pull request to arch:

    Recent age verification laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc. require platforms to verify user age. Collecting birth date at install time ensures Arch Linux is compliant with these regulations.

  • source
  • parent
  • context
  • [–] 2 points 7 months ago (1 child)

    Development stopped not because LILO didn’t need any changes, but because of its limitations (source):

    NOTE: I have finished development of LILO at December 2015 because of some limitations (e.g. with BTFS, GPT, RAID). If someone want to develop this nice software further, please let me know ...

    Also, I dunno what your position is on this, but it is amusing to see calls for Canonical to replace GPL licensed software, with something with a more lenient license (BSD-3-clause). Normally that would cause outrage around here

  • source
  • parent
  • context
  • [–] 3 points 7 months ago* (last edited 7 months ago) (3 children)

    I guess they have their own fork of it?

    Upstream hasn’t seen a new release, nor any commits, since 2015: https://lilo.joonet.de/

    ETA: It is also my understanding that LILO fundamentally does not support reading filesystems, while Canonical want to keep SquashFS, among others. Adding support for that to LILO, along with whatever other features are missing, would likely be a major undertaking

  • source
  • parent
  • context
  • view more: ‹ prev next ›