[-] FizzyOrange@programming.dev 3 points 2 days ago

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.

[-] FizzyOrange@programming.dev 8 points 4 days ago

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.

[-] FizzyOrange@programming.dev 1 points 6 days ago

Ok that was maybe a bit unfair!

[-] FizzyOrange@programming.dev 1 points 6 days ago

I think you're being way too harsh.

  1. 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.
  2. 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.

[-] FizzyOrange@programming.dev 66 points 2 weeks ago

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

[-] FizzyOrange@programming.dev 74 points 1 month ago

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.

[-] FizzyOrange@programming.dev 54 points 1 month ago* (last edited 1 month ago)

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

[-] FizzyOrange@programming.dev 53 points 2 months ago

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!

[-] FizzyOrange@programming.dev 53 points 2 months ago

It's because

  1. They're old and they don't want to have to spend time learning something new.
  2. They spent a lot of time learning C and getting moderately good at it. They don't want that knowledge to become obsolete.
  3. They currently don't know Rust, and don't want to feel like the thing they do know is no longer the best option.
  4. 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.
  5. 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.

[-] FizzyOrange@programming.dev 57 points 6 months ago

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!

[-] FizzyOrange@programming.dev 55 points 7 months ago

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.

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago