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

331–340 of 811 posts

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

#331

Post by 411111111111111 »

jhugo wrote: post #309
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…

The important difference is in purpose, not implementation. Most async runtimes use a thread or more per core, and the OS is doing that thread scheduling, so it's not the either-or situation that you describe. The interesting thing about async (especially async-await) is that it is a fluent way to write a program that waits for events (e.g. I/O), without resorting to inefficient designs like thread-per-client in orde…

> The important difference is in purpose, not implementation.

I couldn't disagree stronger on that one. Abstraction is generally good, but this becomes a purely philosophical discussion as soon as you ignore the actual implementation when talking about the differences of how something actuals behaves and should be used. And philosophical discussions like that have their place but are imo pointless in the context of what should be used, when. They're generally better placed in a context of deciding wherever you want to implement an abstraction

I do fundamentally agree with the rest of your comment however. that's what I meant with trusting your language to prioritize workloads vs your OS.

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

#332

Post by pjmlp »

nyanpasu64 wrote: post #52
Waterluvian wrote: post #38

Earlier quoted context omitted.

I’m a Rust newbie. Mind if I ask: are you referring to using threads and locks and queues and such? Does Rust give you rope to hang yourself when doing it without async or does it continue to be very specific about forcing you to guarantee that you’re not going to run into races and whatnot?

Rust marks cross-thread shared memory as immutable in the general case, and allows you to define your own shared mutability constructs out of primitives like mutexes, atomics, and UnsafeCell. As a result you don't get rope to hang yourself with by default , but atomic orderings are more than enough rope to devise incorrect synchronizations ( especially with more than 2 threads or memory locations). To quote an earlie…

Yeah, but it doesn't help on shared-memory process concurrency, and we all know that in 2022 the best way to ensure secure software is to go back to processes.

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

#333

Post by roblabla »

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.

> 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 require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit.

I also never find that Rust limits or controls me in my day to day work. There are some things you cannot do easily, sure, but those things tend to not matter in application code. Linked lists are hard, graphs are hard, but when writing an app, I just use an existing dependency like petgraph or std::collections::LinkedList instead of reimplementing those datastructures. And if you need to write those things, it's not like it's impossible, you just need to drop down to unsafe rust, and ideally figure out some safe way to expose that API.

Really, the biggest disadvantage of Rust is that its learning curve makes onboarding newcomers much harder if they don't have experience in the language. For Python/Go/JS/Ruby you don't really have this problem, even if a potential recruit doesn't have experience in the language, they will probably be able to pick it up as they go without too much trouble. But in Rust, it can take a fairly significant amount of time to get up to speed and stop fighting the compiler, in the order of several months.

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

#334

Post by pas »

HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

Rust is young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.)

...

I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it.

To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-leven limitations hit in (JVM or JS).

However I don't interpret that as a sign of oh we need to go back to assembly, but more like, okay, we need to accept that our tools and the problems we use them on are not in harmony (yet).

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

#335

Post by Xevi »

pcthrowaway wrote: post #317
conradludgate wrote: post #290

Earlier quoted context omitted.

Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start

> Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler How would you compare it to Typescript? Having become a recent convert, I feel the same way going back to Javascript now

I'm not the same person that you responded to, but I feel much less secure in TS than in C# due to the fact that typing is not a requirement, and that type definitions might differ from the actual library/framework code. It's still a big improvement over plain JS though.

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

#336

Post by roxaaaane »

Author makes a claim that Rust is hard because it's a systems language, i'd like to claim that Rust is hard because it hides the systems part of systems programming. Systems Programming is just UNUX/POSIX/WIN32 Programming it's writing software that interacts with the OS, Rust hides much of this in language abstraction (for good reason) but the trade-off is that using the language becomes complicated.

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

#337

Post by kitd »

adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

D lang is incorporating a borrow-checking system. I'm not certain how far along they are with it. Walter Bright posts here often and will know. D has a wide range of GC and non-GC techniques that may meet your needs.

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

#338

Post by danielheath »

Hirrolot wrote: post #169
mwcampbell wrote: post #156

Earlier quoted context omitted.

> So much of this pain is caused by premature optimization. Part of the problem is that Rust itself has such lofty aspirations to do it all (particularly "abstraction without overhead"), and is largely successful at that. So if I compromise on efficiency, it feels like my code is unworthy of the language it's written in. Also, it's easy to feel that the slightest inefficiency puts us on a slippery slope to the bloat…

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

Being able to build on libraries that are efficient means that your inefficient rust can still be lightweight.

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

#339

Post by TazeTSchnitzel »

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.

> complex language which limits you

Rust really does not limit you. Anything possible in C or C++ can be done in Rust if you're willing to use unsafe code.

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

#340

Post by Santosh83 »

roxaaaane wrote: post #336

Author makes a claim that Rust is hard because it's a systems language, i'd like to claim that Rust is hard because it hides the systems part of systems programming. Systems Programming is just UNUX/POSIX/WIN32 Programming it's writing software that interacts with the OS, Rust hides much of this in language abstraction (for good reason) but the trade-off is that using the language becomes complicated.

Don't all languages hide OS API under their own libraries and abstractions? How is Rust special in this? IMO Rust is hard because it (the borrow checker) forces you to keep track of data and state manually. If you were aiming for practically bugless C/C++ I believe you'd have expend pretty much the same effort, but Rust forces you to do it, while C/C++ leave it up to you.
Post reply on HN