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

501–510 of 811 posts

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

#501

Post by synergy20 »

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…

using c++17/c++20 with g++'s sanitizers(e.g. undefined behavior) and static analyzers, along with clangd the LSP, they too caught most if not all coding errors at editing time and compiling time. In recent two years once my c++ program compiles warning free, it seems bug-free at the same time.

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

#502

Post by crabbygrabby »

wheelerof4te wrote: post #318
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

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.

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 Europe, the Linux kernel itself (the only other language allowed there is C - think about it). It's really not all hype, people like it because it solves a class of problems from never happening while still performing very well.

I invite you to join the community and learn it. It's a lot of fun once you get proficient with it.

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

#503

Post by LaGrange »

wheelerof4te wrote: post #318
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

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.

What I'm about to write isn't to pick at you - I think it's a systemic issue, and "professional programmers" unfortunately have limited influence on it, at least right now - though I believe "we" could change it - but not while acting as individuals.

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

See, I don't think Rust makes that _harder_ - I think it surfaces the real complexity, makes is undeniable. So far in my - by now 20 year old - career, when I've seen most teams faced with complexity that might either slow down a project, or be swept under the rug, the latter was always chosen.

There are _business reasons_ for that, software projects don't live in a vacuum - but those reasons are... _depressing_ at best - by far the biggest one I've seen is that a correctly estimated project would never be approved. Let's just say that figuring that out is a cognitive hazard that can easily increase risk of burning out - literally the sort of knowledge you're better off ignoring.

So ultimately my line of thinking is, Rust's problem in the business sense is basically the same as when you try to code in it: it _tells you that you're trying to sweep something under the carpet_. It tells you that your feature's cost is under-estimated. And to be fair: what can you do about it? The feature wasn't truly estimated by you. It was, almost certainly, estimated by your boss to be "one sprint at most," before he even asked you, and "please estimate this" has an expected answer, and giving any other one has a high social cost. And goddess protect you if your answer might call the entire business model into question.

I don't think any of us can change this, nor that the software engineering workforce is ready to push for changing this. Because even if we convince _our boss_ - the investors will just pick someone else, after all.

--

Anyhow, now you'd be excused in expecting me to advocate some sort of gatekeeping - but no, what I like about Rust is that it attempts to make programming more accessible in a _very different way_ to how many high-level programming languages did. For example:

- it's not _just_ a systems programming language. It doesn't divide programming into "stuff for anyone" and "eldritch monstrosities for the Chosen Ones" - eldritch stuff is just around the corner, in the same language, - it doesn't try to hide the complexity - it tries to give you tools to _explore it_, - and, expanding on the latter, its community values documentation and teaching over restricting use cases.

I don't think Rust is entirely _successful_ at that - but I think that the different model for accessibility is, if anything, more interesting than the borrow checker. I don't think we really need a single language - a garbage collector can be performant and useful, for example, and does it really _have to_ actually result in sweeping complexity under the rug?

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

#504

Post by zaphar »

FiberBundle wrote: post #378
411111111111111 wrote: post #287

Earlier quoted context omitted.

I'm just an average web developer, so I could be wrong here, but that's not my understanding of it. Your application has n threads to begin with, if you use async, these will be utilized to schedule tasks. You're basically trusting your language to properly pause and restart the procedures. If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algor…

> If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algorithm to pause and restart them, so you're not really wasting a lot of resources. Thread context switches are pretty expensive. If you use an async runtime such as tokio, all your tasks will be spawned on a fixed number of threads and you won't have any context switches on a task switch.

    Thread context switches are pretty expensive.
Opinions are pretty divided on this one these days. There was a time when this was very much true but there is some evidence that it is no longer, practically speaking, an issue except in extreme cases. You do pay a cost but it's not immediately obvious that the cost is material. I reach for a threadpool first and async when it becomes clear that I need the extra performance. 99% of the time the threadpool is more than good enough.

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

#505

Post by LaGrange »

rowanG077 wrote: post #466
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 sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."

I mean, while my understanding of the construction market is rudimentary at best - isn't it actually the case that construction often _does_ end up rushed, or compromised at design level, exactly because of that?

It's not good, and when a bridge falls over the results are a bit more... dramatic and undeniable - but it's not really my impression that other branches of engineering are particularly immune from corner-cutting and deliberate under-estimation.

Edit: though I'll say, just having someone "at random" say they expect better in their industry is an anecdotal evidence that it is at least a bit better. Also, you get to work outside. Truly, grass is greener on the other side of the road.

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

#506

Post by dchftcs »

alkonaut wrote: post #261
Animats wrote: post #21

Earlier quoted context omitted.

> If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way.…

> The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO The ecosystem, or the ecosystem where network IO is a thing? Surely that's just a corner of the Rust library ecosystem. I have almost never used network IO (databases, http,...) in 20 years of programming, and zero times in Rust. There is a big (and might I say extremely com…

There are many use cases of raw socket programming in the C++ niche. Anything that requires high and predictable network performance .

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

#507

Post by hirrolot »

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…

> without touching async

The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all.

However, when you write networking code, you typically use async. The worst role is being an async library author (me).

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

#508

Post by crabbygrabby »

karmakurtisaani wrote: post #441
avidphantasm wrote: post #434

Earlier quoted context omitted.

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful).…

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, sometimes it makes sense to clone it, sometimes you want to pass it by value and return it by value. In the case of doubly linked lists you probably want to drop into unsafe code.

I get it though, GC languages are more zen in that regard.

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

#509

Post by jstx1 »

crabbygrabby wrote: post #497
jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

Its so hard for me to think someone actually thinks this. Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. The rust community is the least toxic programming community I've ever seen. Leaps and bounds away from go lang, python, and light years away from c, etc. Like use your head, is vba therefore the language whi…

I’ve hardly said anything about Rust (and I’m actually learning it at the moment). My point is that stackoverlow’s most loved metric can be misleading. It’s more of a least-wanting-to-jump-ship-right-now metric.

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

#510

Post by crabbygrabby »

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.

Bingo, it's a true systems language. That said, the fact that people can and do write web applications(for practical reasons) with it kind of says something about it's breadth.
Post reply on HN