The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.

Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.

I guess if you are formatting strings constantly this is important, but you can also use a bump allocator in rust if you really wanted to.

I am able to write rust on a moto g power (a cheap android smartphone) inside of termux, running on battery, in battery saver mode, and cached compile times for every single one of my projects is under 5s easily, if not faster. Fast enough that I don't notice it at all.

Even a "cold" compile was under 1 minute for me, and I have a decent amount of deps.

I guess my projects are fairly small compared to others though so idk.

Does anyone even use tkinter in modern times anyways?

People experience "blue screens" and kernel panics and such pretty often.

The rest of the system for example chrony, sysklogd, cron, etc run fine on upstart systems, because they aren't tied to systemd and are fully modular.

It's okay to be a monolith, that doesn't make it inherently bad or anything, but we should be honest about it, and it does come with some tradeoffs.

Memory safety related security exploits happen in a steady stream in basically all non-trivial C projects, but supply chain attacks, while possible, are much more rare.

I'm not saying we shouldn't care about both issues, but the idea is to fix the low hanging fruit and common cases before optimizing for things that aren't in practice that big of a deal.

Also, C is not inherently invulnerable to supply chain attacks either!

It actually is for a lot of subtle reasons, assuming you were going to check the executable checksum or something, or blindly downloading + running a script.

The big thing is that it can serve you up different contents if it detects it's being piped into a shell which is in theory possible, but also because if the download is interrupted you end up with half of the script ran, and a broken install.

If you are going to do this, its much better to do something like:

    sh -c "$(curl https://foo.bar/blah.sh)"

It's NOT loosely coupled in any way. Try running any part of the systemd software suite on an openrc system and see how that works out?

I have no idea why people are so insistent on claiming that its not a monolith, when it ticks off every box of what a monolith is.

Also I have a wireguard vpn setup so that I can ssh between my phone and desktop computer via a VPS with a public ipv4 address. This allows me to just "ssh 10.0.0.4" to access the phones sshd, instead of having to deal with changing IP addresses and NAT traversal.

    (1) root@gentoo-server ~ # egrep 'openai|claude' -c /var/log/lighttpd/access.log
    8537094

The build system just invokes emacs and compiles org documents to HTML, and installs them in /var/www/${site}. I have a git update hook on the server that invokes the build script when I push updates.

Originally I did just rsync over HTML files though, but I like the new setup a lot.

Granted it wasn't a whole lot of money spent, but why waste money and resources so "claude" can scrape the same cgit repo over and over again?

    >(1) root@gentoo-server ~ # grep 'claude' /var/log/lighttpd/access.log | wc -l
    >1099323

That's not how you are supposed to use static typing? Python has "protocols" that allows for structural type checking which is intended for this exact problem.

I've never saw anyone claim that doing UB in Rust is okay because its wrapped in an unsafe block?

If anything I've saw the exact opposite of this, cases of UB in libraries is considered a bug almost always, vs in C or C++ where "its the users fault for doing the thing wrong".

I notice you spreading an awful lot of bs about rust lately, not sure what the deal is but its pretty childish and lame, not to mention objectively wrong.