Right, I'm not saying it isn't simpler in terms of syntax. The point I was making is that the syntax is simpler but in a way that makes it worse because while it's easier for computers to read, it's harder for humans.

it was only later discovered that they can be compiled down to native code.

That sounds extremely unlikely. I think you're misinterpreting this quote (which is fair enough; it's not very clear):

Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today ...

As far as I can tell Lisp was always intended to be compiled and executed. That quote is about compiling the eval() function (which was just meant to explain how Lisp is executed) into a binary and using that as an interpreter.

Also I skimmed the paper that is from, and in fact Lisp was intended to be targeted by AI (in the same way that we get AI to write and execute Python to solve problems), which explains a lot. It wasn't designed for humans to write, so why bother with nice syntax; just have the machine write the AST directly!

(I expect that was only part of the motivation tbf, but still!)

This comment perfect captures why I don't like Lisp. Essentially "it's simple, this easy to read code transforms to this AST". Lisp basically says "we can make parsing way easier if we force programmers to write the AST directly!" which is really stupid because computers can perfectly well parse syntax that is easy for humans to read and turn it into ASTs automatically.

It makes it easier to parse for computers at the cost of being much harder to parse for humans, which is really the wrong choice in most cases. (The exception is if you're DIYing your compiler, e.g. if you're teaching how to write a compiler then Lisp is a good target.)

I'm not a fan of Lisps either. But I also thing the Nic language is kind of awful... So maybe in comparison it's ok?

Yeah it's great for little scripts. There's even a cargo script feature that's being worked on so you can compile & run them using a shebang.

I'd use a shell script if it is literally just a list of commands with no control logic or piping. Anything more than that and you're pointing a loaded gun at your face, and should switch to a proper language, of which Rust is a great choice.

It's definitely a growing problem with Rust. I have noticed my dependency trees growing from 20-50 a few years ago to usually 200-500 now.

It's not quite as bad as NPM yet, where it can easily get into the low thousands. Also the Rust projects I have tend to have justifiably large dependencies, e.g. wasmtime or Slint. I don't think it's unreasonable to expect a whole GUI toolkit to have quite a few dependencies. I have yet to find any dependencies that I thought were ridiculous like leftpad.

We could definitely do with better tooling to handle supply chain attacks. Maybe even a way of (voluntarily) tying crate authors to verified real identities.

But I also wouldn't worry about it too much. If you a really worried, develop in a docker container, use a dependency cooldown, and whatever you do don't use cryptocurrencies on your dev machine.

The real costs are the ~$100m they spend a year on developing GitHub and providing it for free to most people - including free CI.

They charge 3x the cost price for runners so that they can actually make money. This change is so that they can't get undercut by alternative hosted runner providers.

I do think they could have just explained that and it probably would have been more palettable than their "we're making it cheaper!" lie, but I guess there are also a lot of people that still think the only moral pricing is cost plus.

I'm surprised there aren't more companies offering managed Forgejo instances.

Best option is to switch to C++ and use QtWidgets. You don't need to know much C++ for that - if you want to tediously micromanage strings you can still do that in your business part of the program.

He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.

This is the kind of silly stuff that just makes RISC-V look bad.

Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.

Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:

We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.

This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.

Linux should absolutely not implement this.

His point could be valid, if C was working fine and Rust didn't fix it. But C isn't working fine and Rust is the first actual solution we've ever had.

He's just an old man saying we can't have cars on the road because they'll scare the horses.

Ok after reading the article this is bullshit. It's only because they are counting JavaScript and Typescript separately.

Actual blog post.

Great accomplishment. I think we all knew it must happen like this but it's great to see real world results.

I think this is probably actually the most useful part of the post:

Increasing productivity: Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++.

I think anyone writing Rust knows this but it's quite hard to convince non-Rust developers that you will write fewer bugs in general (not just memory safety bugs) with Rust than with C++. It's great to have a solid number to point to.