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.

It's the language and the domain. They work pretty well for the web and major languages (like top 15).

As soon as you get away from that they get drastically worse.

But I agree they're still unambiguously useful despite their occasional-to-regular bullshitting and mistakes. Especially for one-off scripts, and blank-page starts.

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.

...for people who refuse to use static types.

Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts

All 9k stars, 10k PRs, 400 forks & professional web site are fake? Come on this is about the most obviously not fake project I've seen!

How do you know when a product like this can be trusted?

The same way you tell if anything can be trusted - you look at the signals and see if they are suss. In this case:

• Lots of stars
• Lots of real code in the repo
• Professional looking website with commercial pricing
• Lots of issues
• Good English

The amount of effort it would take to fake this for very little benefit is enormous.

Maybe I’m just being paranoid.

Yeah just a little!

Seems a bit clickbaity to me. It's a flaw in Windows/cmd.exe, not Rust. Rust is just called out because it tries to emulated proper argument passing on Windows (and didn't get it perfectly right). All languages are affected by this but most of them just throw their hands in the air and say "you're on your own":

• Erlang (documentation update)
• Go (documentation update)
• Haskell (patch available)
• Java (won’t fix)
• Node.js (patch will be available)
• PHP (patch will be available)
• Python (documentation update)
• Ruby (documentation update)

It's also extremely unlikely that you'd be running a bat script with untrusted arguments on Windows.