[galadran]

> It is not fun but frustrating to work in Rust.

Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now.

> add a new huge dependency

Sure, but setting up Rust is much much easier than GCC with all the trimmings.

> As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions.

Assuming you are referring to pyca, you are mistaken and there has been a lot of misinformation about the change. Rust support is needed to build the module, but not install it. Pyca works just fine for users without rust and works everywhere rust does. Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.

[fnord123]

The problem with pyca cryptography was that Python users are not in the habit of using lockfiles which meant reinstalling venvs picked up more recent versions of transient dependencies. That and that they made the change in a minor update and non wheel users got caught out.

[FridgeSeal]

That people weren’t version-pinning critical dependencies was the most eye-opening thing about that whole affair. The tools to make this easy have been available and well-used for years, don’t have a lot of sympathy for them.

[fnord123]

Well people think they are pinning their critical dependencies by using a requirements.txt file. But it normally the transient dependencies are not listed. And anytime you rebuild a

You probably know this but for people reading along who think using requirements.txt is the same thing: it is not.

How lockfiles work is that you define your dependencies in a file like pyptoject.toml or Pipfile (similar to a Cargo.toml). You then use pipenv or poetry or pants to compute all the dependent versions of your dependencies and transient dependencies. Then that's saved in a lockfile. Any time you need to remake a venv for local Dev or rebuild a docker container or install deps for CI is uses the same locked versions from the lockfile. Only when you decide to recompute the dependencies do the transient dependencies change in the lockfile.

Sadly, a standard lockfile was rejected from PEP-650, held back by pip being woeful:

https://www.python.org/dev/peps/pep-0650/#a-standardized-loc...

[FridgeSeal]

That link was a very frustrating read hahaha

> Additionally, pip would not be able to guarantee recreating the same environment (install the exact same dependencies) as it is outside the scope of its functionality.

Well then, maybe fix it? Because clearly it’s an issue? A good chunk of that explanation really reads like “ehhhh, can’t really be bothered fixing this”, which makes sense given the Python devs approach to the last couple of Python versions: no fixes for anything important, just more half-baked features nobody asked for.

[fnord123]

>Python versions: no fixes for anything important, just more half-baked features nobody asked for.

Oh god, tell me about it! 'Hey guise I heard pattern matching in rust and Scala and Haskell is popular! Let's add it to python but with no compile time checks to make sure matches are exaustive!'

Some excellent and smart devs who I really do respect worked really hard to deliver a complete dog shit feature while pip languishes for almost a year with a broken version resolver [1]. It's so frustrating. :( :( :(

[1] https://github.com/pypa/pip/issues/9187

[greatgib]

> Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.

This is kind of the root of the problem, when you are kind of a hobbyist dev wanted to work with the latest shinny new version of everything, then everything is fine.

But when you try to do different things that are not mainstream or doing embedded, then you understand why sometimes you have to keep old software or hardware.

Rust like go are made for a connected world, where you are always upstream, always connected to get the latest versions, and it's ok to do breaking change to the language every few years.

Did you ever try to build a Linux from scratch? Trying to fit some build or runtime constraints? Then you learn the real cost of each dependency that is added and of their complexity.

Imagine you had that much dependencies to build a kernel, probably this much of memory, CPU and storage used. Now you need to add rust, its dependencies, other tools related to it. Each dependency possibly not supporting your system or configuration or require their own library dependencies in a new version that is maybe conflicting with older versions already used by the system. And that you can't change without breaking other existing programs in the system. And maybe you can fix these other applications to support the new version of the library but you just wanted to "update" your kernel and not spend 10 days reworking your system unexpectedly because a stupid update required it.

[FridgeSeal]

It’s worth pointing out that a lot of those “weird” old chips weren’t formally supported anyway, and the the fact that the software worked on them was a convenient fluke, and by design or intention.

[greatgib]

This is the magic of Linux so far to be so versatile and able to support so many hardwares.

But that being said, most of the time, issues are not coming from really exotic "chips" but from little variations, configuration or system library versions.

Let's say you want to cross compile from x to y, and want code to use that specific memory space. This is when things start to get messy usually.

Example of how you can lose a lot of time and get crazy, when you just wanted to compile the code of something for your case:

https://stackoverflow.com/questions/67902309/how-to-compile-...

https://stackoverflow.com/questions/31492799/cross-compile-a...

[brandonmenc]

> Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now.

How many of those votes were cast by programmers who have actually used the language?

[jkelleyrtp]

That particular metric is derived from "people who use the language outside of work and wish they could use it more at work." The survey doesn't explicitly say "which language do you love?".

[jcelerier]

Everything is more fun when you don't have to interoperate with Joe Coder (who left the company 7 years ago)'s APIs and idiosyncracies

[tialaramex]

Sure, that makes a fine hypothesis. Still though, if you're right, why does Rust report 86.1% love while Python only got 66.7% ?

https://insights.stackoverflow.com/survey/2020#technology-mo...

Maybe the Python number is smaller because those people are working right? All the Rust programmers are just working on a fun program at home, and Python is a serious language now, you're working the 9-5 with Joe Coder?

Haskell is 51.7% though. So, I guess when I wasn't looking Haskell really exploded in boring office environments and I shouldn't expect to see any more hobbyist Haskell projects everywhere... or your hypothesis was just wrong.

Maybe it's just that Rust is new and exciting, let's look at what people want to use that they don't now, surely that'll be Rust too and we'll know it's just Hype.

Huh, that chart is dominated by Python. 30% of programmers not doing Python wanted to start.

[jcelerier]

I must say I don't really understand your points

> why does Rust report 86.1% love while Python only got 66.7% ?

I mean, because python is in practice a boring office language where the immense majority of devs have to maintain Joe Coder's 2009 Django set of custom attributes.

> Huh, that chart is dominated by Python. 30% of programmers not doing Python wanted to start.

Because people believe that if they learn python they'll instead land a cool ML job which pays 100k more than what they have ? Like, I have my girlfriend who literally does not know anything about programming ask me if I could teach her python because she saw an ad about it (for a "land a CS job in 3 months" type of thin). That necessarily causes some inertia for Python, not enough to be more hyped than rust, but enough to influence results.

[tialaramex]

Anecdotes about what non-programmers believe aren't very applicable to Stack Overflow's survey of programmers. Still though, you end up with a weird conclusion where you believe "hype" drives the Loved statistic (one based on people's real experience) but not so much the Wanted statistic (based on what they heard) when by definition that isn't how hype works.

Think about the 2016 movie "Deadpool". Deadpool is a one joke character. There are no major Marvel characters in the movie, the stakes are low, there is no connection to the larger Marvel Cinematic Universe storyline. Reynolds has played this exact character before, in a movie which nobody liked. There was inevitable fan hype before it came out, "the merc with a mouth" sells comics and those fans are going to see the movie whatever, but fans don't know anything right? But, both critics and audiences seem to have liked this movie, a lot more than its studio expected. It made a lot of money and got pretty great reviews from most quarters. Neither of those things is hype, that's called success.

The Loved result looks exactly like what I see what I talk to people about Rust. Those who haven't heard of it of course aren't looking to write Rust, for those who've only heard of it, it's on their "things to check out" list with Go, and maybe Swift but it doesn't jump out at them. But among those who've written Rust you see a spike of enthusiasm, "Hey this is really good".

When I learned Go, I filed the acquired skills away. "This may be useful in some future scenario, but I have meanwhile ceased to be employed writing TLS bit-banging code for which I thought Go would be the best option, so, never mind now"

But when I learned Rust the first thought was "I should write more Rust". I immediately rewrote the smallest interesting C project I ever published and pushed that to GitHub. Then I wrote a bunch of code to check some of my intuitions about Rust's safety when used by people who are unreasonable (misfortunate, a collection of perverse implementations of safe Rust traits). Then I started writing a triplestore, which I'd done twice before in C -- a friend and colleague left programming and went into management after his third one, so cross fingers that doesn't happen to me.

[Zababa]

You could said the same for every language.

[brandonmenc]

Yes, you could. Which is why I take the Stack Overflow survey with a huge grain of salt.

[stevekemp]

Could also be referring to the cryptography library which added a Rust dependency, which caused pain for people running ansible, and other downstream users.

[woodruffw]

> Could also be referring to the cryptography library which added a Rust dependency, which caused pain for people running ansible, and other downstream users.

This isn't true for the overwhelming majority of deployments, since pyca/cryptography was/is distributed as a pre-built wheel. There is no runtime dependency on Rust in pyca/cryptography; the only downstream change is that packagers are required to have a Rust toolchain.

[oalae5niMiel7qu]

Just because there are wheels doesn't mean you'll never need to install Rust to install Cryptography. Just this week I got a "you need Rust" build error inside of a Docker container due to Pip not being able to find a wheel for the specific Python version used by the container. Fortunately, the version of Cryptography that was being pulled in supported that environment variable to use the C version instead, so I was spared from having to do a ton of work.

For now. One day I'll wake up and a future version of this container will refuse to build because whatever library pulled pyca/cryptography in got upgraded and now needs the Rust-only version.