Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

Post reply on HN
Print view View original

571–580 of 811 posts

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#571

Post by sph »

a_c_s wrote: post #475
sph wrote: post #451

Earlier quoted context omitted.

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes. Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes,…

This feels a bit like complaining that a tank is badly designed because nobody drives them on the highway... My understanding is that Rust was designed to be a safe(er) language to write low-level system code than C/C++, not to compete with Python/Ruby/Java for web development applications.

I'm not complaining about Rust. It's a very good language.

I'm complaining about everybody on programming forums, including HN, seeing Rust as the replacement for most, if not all languages. My opinion is that Rust's ideal problem space is much narrower than people think.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#572

Post by fizzynut »

crabbygrabby wrote: post #549
crabbygrabby wrote: post #508

Earlier quoted context omitted.

So here's a weird thought, why should you ever write your own doubly linked list? Why shouldn't you use one that a community of people has vetted and juiced for performance instead? In C what I just said is for some reason heresy. But yes you are right, anytime you have two or more accesses to a data structure you do have to think a little harder about it. Usually you just want to use a reference to that object, some…

Won't let me reply to fizzynut, but this is a reply to you. Yes making data structures is important, and the reality of that is, there are people in the ecosystem creating fancy ones which can be leveraged for your use case. If that doesn't exist then yea you have to write them. Sometimes that's difficult(you need to use unsafe), sometimes it's easyish and you can use all safe(I did this for a graph type). It can be…

Lots of people writing their own data structures and libraries should be a reflection of the different needs and diversity of the ecosystem, but if it's a reflection of difficulty then it tends to lead to a much narrower ecosystem.

That isn't to say a narrow ecosystem is necessarily bad, it can often be good if a particular language is used for a specific domain as all the libraries and data structures will likely be a better fit for your problems. Going outside of those constraints can often be very punishing in those languages though.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#573

Post by shric »

Georgelemental wrote: post #515
crabbygrabby wrote: post #502

Earlier quoted context omitted.

Rust only limits you from writing nonsense code. Seriously that's what the compiler is doing, and that's what people are complaining about. "Why won't this language let me write bad code!". I get it it's hard to learn at first, but, it sounds a little silly to people who have spent the time learning the language... Believe it or not industry has and is continuing to adopt rust. Microsoft, AWS, government agencys in E…

> Rust only limits you from writing nonsense code This is the ideal, but not always the reality. The Rust borrow checker isn't perfect, so sometimes it rejects code that should work perfectly fine. Hopefully as the language matures (Polonius, GATs, HRTBs…) these cases will become rarer.

Is there a simple example you can point to of rejected code that should work perfectly fine?

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#574

Post by yencabulator »

lumost wrote: post #44
PragmaticPulp wrote: post #28

Earlier quoted context omitted.

> To be clear: using async is fine if you know what you are doing, and it can provide incredible performance. But if you do, keep it simple: avoid lifetimes and most importantly: don't attempt advanced trait shenanigans - if you do need traits, just returned BoxFutures without lifetimes, throw in lots of Arc >, clone() and call it a day. It seems like everyone doing async Rust goes through a long journey before arriv…

Anecdotally, this is the pain felt most across the entire rust language. There are more ways not to do something than to do something . This makes it hard for beginners to pickup, and difficult for projects to scale on.

That by itself can be interpreted as a good thing -- no Perl TMTOWTDI please.

The "special quality" about Rust that hurts here is that it takes a lot of time going into a dead end before you realize it's a dead end.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#575

Post by sph »

solar-ice wrote: post #473
sph wrote: post #451

Earlier quoted context omitted.

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes. Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes,…

> Most of us are writing web apps Indeed. I'm a Rust dev somewhere it actually matters (video dev - we have to process 60 frames a second, for hours/days on end, with completely predictable performance, without crashing once) and I'd never pick it if I just wanted to build a webapp where nothing really matters and if the whole thing falls over we can just put it in a retry loop. There's plenty of code out there that…

Your video app is a perfect example of where Rust shines. I'd add embedded development, data-intensive, fault-intolerant systems and game engines are perfect for this language.

But without even going as far as frontend web applications, stuff like backend services, system services, GUI applications, CLI applications, etc., don't actually need all that much memory safety and control over allocations.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#576

Post by icedchai »

Aeolun wrote: post #493
kaba0 wrote: post #397

Earlier quoted context omitted.

How is it different than in case of every other language? Also, why not another newer language tops the list?

Rust is really hard. So while people that don’t like Javascript still continue to use it, but people that don’t like Rust are likely to drop it like a brick.

Rust is too painful for hobby projects, IMO. Over the years, I've worked in C, C++, Go, Perl, Python, PHP, Java, Scala, JS, Tcl, ... others I've forgotten, most professionally and well as for personal projects.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#577

Post by yencabulator »

nemothekid wrote: post #72

I've been doing async Rust since the tokio 0.x combinator days, and I remember being like OP. For some reason `Arc` did not exist in my mind and it was a struggle appeasing the borrow checker. The Go version is similar to the final Rust version; except the Go version is forcing you to use Arc everyone[1]. Seriously, just use Arc (or Arc >), in 70% of cases you are wrestling with the borrow checker trying to do someth…

> except the Go version is forcing you to use Arc everyone

The overhead of atomic reference counts everywhere is higher than the overhead of a good garbage collector. This thinking is biased against Go for no reason.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#578

Post by sph »

Aardwolf wrote: post #528
iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

IMHO the time for doing analysis like this is before submitting code, not before compiling it. Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere becaus…

This is one recent change in Zig which really annoys me: unused variables are now errors. Languages that complain every time there's a unused variable become useless during experimentation and quick hacking. They turn my hyperfocus into a death from a thousand paper cuts.

I hate it with a passion. Please respect my mental flow, if I'm trying some ideas out, it's just rude to stop me in my tracks to tell me I forgot to comment out a variable. Who cares.

I will fight anyone who thinks this is a good idea.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#579

Post by Hirrolot »

elcritch wrote: post #428
Nokinside wrote: post #356

Earlier quoted context omitted.

IMHO it would be good for Rust to become popular niche/specialist language for systems programming. Currently Rust is not as complete or well defined as Ada/SPARK or MISRA C/C++ combined with commercial analyzers (Astree for example). At the same time Rust is "too sound and rigorous" for mainstream programmers. Rust advocates are in the losing battle of of forcing mainstream to adopt "it does not compile unless compu…

Ick, most programmers aren’t going to write MISRA C/C++ either. Even if people claim they do it seems way to easy to just turn off or ignore it. Take the recent reports on the Toyota gas peddle bugs. They’d completely abandoned. Gotta say SPARK does seem to provide much of what it claims. Interesting that NVIDIA seemed to be using it for their secure bits.

Quoting one publication about MISRA [1]:

"From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams' observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."

[1] https://repository.tudelft.nl/islandora/object/uuid:646de5ba...

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#580

Post by NoGravitas »

roblabla wrote: post #333
wheelerof4te wrote: post #318

Earlier quoted context omitted.

This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

> We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit.

Python to Rust is a pretty radical swing from one approach to language design to another. I'd expect you could solve most of the maintenance problems with Python by switching to something statically typed but with garbage collection (e.g., C#, Java, or go), without incurring the costs of moving to Rust.

Post reply on HN