[pclmulqdq]

I think in a lot of C++ and ex-C++ orgs you see this sentiment a lot, and sometimes for good reason. Sometimes that code has security or performance reasons to worry about this. On the other hand, it often doesn't.

On the other hand, Python folks and JavaScript users (which make up a lot of emigres to Rust) probably don't care enough about their supply chain. That's how you end up with misspelled packages causing viruses in production and other disasters.

The short answer to this is that it actually depends a lot on what you are doing.

[arp242]

> That's how you end up with misspelled packages causing viruses in production and other disasters.

For all the stories about malicious packages on PyPI and whatnot: I can't recall ever seeing a story about "misspelled packages caused us problems in production". Most of these packages have downloads in the low-hundreds at best, and I wouldn't be surprised if the vast majority are from the attackers testing it and bots automatically downloading packages for archiving, analysis, etc. I've come to think it's not as much of a big deal as it's sometimes made out to be.

The closest I've seen is the whole event-stream business where the maintainer transferred it to someone else who promptly inserted some crypto-wallet stealing code, but that's a markedly different scenario (and that also seems quite rare; it was over 4 years ago).

[imran-iq]

> For all the stories about malicious packages on PyPI and whatnot: I can't recall ever seeing a story about "misspelled packages caused us problems in production".

https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

Discussed at the time: https://news.ycombinator.com/item?id=26087064

[arp242]

That's a different thing; it would (ab)use some package tools' preference of public packages over private ones (at least in some configurations). It's not really a "supply chain issue" but more of a "footgun in some package tools"-issue.

[bombolo]

Well they've been subpoenad so probably something happened.

[mr_00ff00]

This surprises me that most people that use rust come from python and JavaScript. I would think the reason rust is so popular is from people moving from C and C++ and getting all the nice modern features to do systems with.

Python and JavaScript people I would imagine find rust annoying since it’s all the niceties they are use to but with a bunch of rules on top.

[efnx]

I see people coming to Rust from all angles. It’s a nice sweet spot. I came to it from Haskell and on my team of three the other two devs came to Rust from C++. I can opine the motivation looks something like this:

* From Haskell - looking for a strong type system (with sum types, typeclasses) but is “widely accepted”. No GC.

* From C++ - looking for low-level capabilities (pointers, references) with improved safety. Improved manual memory management.

* From Python/JS - looking for performance with a familiar feeling ecosystem and a welcoming community

I think the Python and JS folks will have the hardest go of it, but they also have the most to gain.

[deathanatos]

I went Python → Rust. Rust is high-level enough for me to remain competitively productive with Python, and the type-system just helps so much. I can't tell you how nice it has been to not have to see "Object of type NoneType has no attribute 'foo'" anymore. Also,

  def foo(obj):
    # ...

And me wondering "what is 'obj'?" and then pulling that root … and pulling … and pulling …. Also "data", another just fabulous name for a variable, really narrows the possibilities. Even once you know the "type" of the variable, oftentimes I'd find that the type definition would subtle shift and morph in different parts of the program: they'd all want a Duck, but have varying opinions on what a Duck actually is. You cannot commit such BS with an actual type-checker.

There is more up-front work with the compiler, but it pays off: the code that passes the compiler is of much better quality.

Also, Option<T> is very nice to have when you need an actual Option<T> (i.e., generically), which Python lacks. (No, `None` is not it: You run into problems when T == Option<U>, and you have None and Some(None) — Python's cannot differentiate between the two.) Also sum types in general.

[mr_00ff00]

Right but you essentially just mentioned strong typing. There are a billion languages that don’t run into those issues.

Java, Go, C, Scala, Haskell, etc all fix those type issues.

[deathanatos]

Sure, I suppose, but sum types (which I mention) eliminate all but Scala and Haskell from that list.

[david2ndaccount]

Python and Javascript programmers so massively outnumber all other programmers that they are the majority of people converting to any language.