But you'd still be crazy to use it for either of those purposes, given how safety critical they are. I expect it would be more likely used in robots like Spot, or manufacturing robots.
It's not too bad if you strictly enforce Pyright, Pylint and Black.
But I have yet to work with Python code other than my own that does that. So in practice you are right.
Ok that was maybe a bit unfair!
I think you're being way too harsh.
- His recommendations to disable debug info and PIC are not "bad". He isn't suggesting that should be the default. He actually only suggested that split debug info should be made the default on Linux which is a sensible suggestion.
- There are gazillions of other posts talking about codegen-units, cranelift and so on. I don't think we need a repeat (though he could have linked to them).
The focus on linking was because this post is introducing his liker project.
OP ignore this naysayer.
Ok after reading the article this is bullshit. It's only because they are counting JavaScript and Typescript separately.
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.
Definitely agree with tech debt. Seems like nobody except me cares about improving things, which is surprising given this survey!
Also definitely agree about reliability of tools/systems, but again it feels like it's just me that cares about robustness - everyone else is very happy to churn out hacky Bash scripts, dynamically typed Python and regexes with abandon.
Either you're all a bunch of hypocrites or the SO survey is quite a biased sample!
It's because
- They're old and they don't want to have to spend time learning something new.
- They spent a lot of time learning C and getting moderately good at it. They don't want that knowledge to become obsolete.
- They currently don't know Rust, and don't want to feel like the thing they do know is no longer the best option.
- They aren't the ones with the idea to use Rust, and they don't want to lose face by accepting that someone other than them had a good idea. Especially not some young upstarts.
- Supporting Rust is extra work for them and they don't care about memory safety or strong types etc.
In order to avoid losing face they'll come up with endless plausible technical reasons why you can't use Rust in order to hide the real reasons. They may not even realise they're doing it.
Some of the reasons might even be genuinely good reasons, but they'll come up with them as an "aha! So that's why it's impossible" rather than a "hmm that's an issue we'll have to solve".
It's not just Rust Vs C. This naysaying happens wherever there's a new thing that's better than the established old thing. It's a basic human tendancy.
Fortunately not everyone is like that. Linus seems in favour of Rust which is a very good sign.
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.
Why? I've worked in two companies where IT allows Linux as an option and people are constantly having issues (including me). And these are highly technical people. Two people who are not stupid managed to break their laptops by uninstalling Python 2 which Gnome depended on.
Yes that's technically a UX issue, but there are plenty of good old bugs too, e.g. if you remove a VPN connection that a WiFi network autoconnects to then that WiFi network will entirely stop working with no error messages to speak of. Took me a long time to figure that out. Or how about the fact that 4k only works at 30fps over HDMI, but it works fine over DisplayPort or Thunderbolt3. The hardware fully supports it and it works for other people with the same OS and laptop. I never figured that out.
That's just a taster... I almost never have issues like that on Windows or Mac.
Windows may cost more than "free" but the additional support costs for Linux are very far from free too.
Maybe something like Chromebooks makes sense if everything is in the cloud.