Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

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

#521

Post by kobebrookskC3 » Fri, Jun 03, 2022, 1:35 PM UTC

lelanthran wrote: post #244

dataangel wrote: post #175

Earlier quoted context omitted.

Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warnings and errors on compilers don't catch it.

> Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haske…

> Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted

i dare you to find memory corruption in safe rust that isn't already on an issue tracker.

> Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly.

tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... , most likely human rights activists targeted by less-than-savory regimes. memory corruption bugs are so frequent that it is possible for nso group to sell to pretty much any regime, and not forced to be classified as top secret information.

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

#522

Post by gary17the » Fri, Jun 03, 2022, 1:35 PM UTC

pnt12 wrote: post #499

gary17the wrote: post #403

While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, mult…

I liked your thoughts but disagree with the conclusion. It seems that serverless is cost prohibitive in many scenarios, and requires lots of optimization to be cost effective. So isn't it more of a fault of serverless than a strength of rust?

I see your point, but it all depends on whether the choice of a particular organizational infrastructure architecture is a priority for you or not.

If infrastructure is a priority, (e.g., "we don't really want to hire anyone just to setup/monitor/secure that Linux box with all those REST API server/database processes, thus we prefer serverless), serverless is important and Rust performance is its strength.

If infrastructure is not a priority, (e.g., "I was gonna roll out my own VPS anyway, I love this stuff"), serverless is all about its faults and Rust is irrelevant (it is logical to choose an easier PL, e.g., the excellent Golang).

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

#523

Post by pkolaczk » Fri, Jun 03, 2022, 1:37 PM UTC

lenkite wrote: post #440

whazor wrote: post #386

Earlier quoted context omitted.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

"Things that are hard in Rust, are even harder in C and C++." Incorrect. This handler-dispatcher problem illustrated in the article is utterly trivial in C++ and many programming languages. No need to struggle and stretch your brain as if you are in the Math olympiad. I am learning Rust myself and I think Rust fans are spreading misinformation and propaganda by saying Rust makes things easier than other languages. No…

This handler dispatcher problem gets trivial if you do it in unsafe mode. Just transmute all lifetimes to 'static and call it a day. That is what you do in C++ all the time (implicitly). So C++ version of it would be easier to get compiling, but harder to get right - because you'd have to prove lifetimes are correct anyways.

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

#524

Post by spoiler » Fri, Jun 03, 2022, 1:38 PM UTC

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…

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

I'm sure you know this already, but for the people reading this: first of all "unsafe" is a very rare, and it's only "less safe" more than fully "unsafe"; ie it's still safer than C++.

And the second thing is that, often you don't have to drop into unsafe Rust, it's possible to achieve most stuff without it, but might incur a small performance cost (idk if some of those can be optimised away by compilers or not).

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

#525

Post by ipodopt » Fri, Jun 03, 2022, 1:39 PM UTC

bombela wrote: post #97

ipodopt wrote: post #39

Earlier quoted context omitted.

It has been a sec but if I were to do another multi-threaded async Rust project I would do one thread per async runtime and explicitly pass anything that needed to be shared. This should be more ergonomic as this should get rid of everything needing to have send/sync traits. I also suspect it may be more performant as I am not sure how good the async runtimes are about keeping scopes pinned to a particular core so it…

But what when you have some threads slacking off, and others too busy? It would be nice in this case to use those idle threads, even if it means a little bit of CPU cache trashing. And I believe this is what Tokio offers with a work stealing thread pool.

True, but I suspect that without a truly global prescient scheduler it is almost never worth it to core switch unless you generally have really long tasks.

For an efficient core context switch the scheduler must accurately predict that the source (current) core won't be free for the duration of the full core context switch time and that the sink core will be free by the time the meta context gets there and will have been free by the time the rest gets there. Otherwise, the scheduler ends up thrashing the cpu (it is actually a bit worse as future task might need same context so you have to be aware of the future). So, for the scheduler to know this it would need to be:

- Global: The only scheduler on the system or basically rafting with all the other schedulers on the system

- Prescient: The scheduler(s) would need to be able to predict all tasks, thier context, and work time per task perfectly. Which could really could only happen when everything is static and hence deterministic.

For example, I think most tasks people are throwing at async are web requests. Most actually take the core an order of magnitude shorter time to compute then the time it takes passing the context from one core to another and they are all unpredictable to the scheduler. In this scenario I could see the scheduler taking up the majority of computational time on the system. So turn on multi-threading + async on a quad core and you will get worse bandwidth and latency(always) for all your pains.

EDIT: Although this single data point would tell me I am wrong (see description):

https://www.youtube.com/watch?v=IG-wGXENTt8

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

#526

Post by the_only_law » Fri, Jun 03, 2022, 1:40 PM UTC

eternalban wrote: post #520

crabbygrabby wrote: post #497

Earlier quoted context omitted.

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…

> 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. Were you around when Scala was the end all be all of programming shiny things? "Early on, Scala rode a wave of hype that frankly surprised even me: hype around pushing syntactic boundaries, hype around reactive architectures, hype around functional programming, h…

I don’t like Scala, because it seems everyone who makes a library has their own little DLC I have to learn as well.

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

#527

Post by crabbygrabby » Fri, Jun 03, 2022, 1:40 PM UTC

jstx1 wrote: post #509

crabbygrabby wrote: post #497

Earlier quoted context omitted.

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.

You're not wrong. Being an exdata geek, I can say almost all metrics are flawed. We could even look at the most popular language and realize how that is flawed/not very meaningful too. Thanks for clarifying. Didn't mean to get in your case, but it just didn't sit well with me. I see a lot of people bashing rust in here, who have kind of obviously never tried to learn it.

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

#528

Post by Aardwolf » Fri, Jun 03, 2022, 1:41 PM UTC

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 because you change the type something temporarily. It'd be nice to only do the work of cleaning up such issues in the final version of your change.

These checks are enabled by default in many environments, build tools or scripts for them etc..., it's not trivial to disable it or requires full recompile.

So I wish a language or build environment would use the concept of "development time" vs "submitting time" for different sets of warnings-as-errors.

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

#529

Post by [deleted] » Fri, Jun 03, 2022, 1:42 PM UTC

LaGrange wrote: post #505

rowanG077 wrote: post #466

Earlier quoted context omitted.

> 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-cu…

[deleted]

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

#530

Post by jjnoakes » Fri, Jun 03, 2022, 1:47 PM UTC

fulafel wrote: post #238

jjnoakes wrote: post #216

Earlier quoted context omitted.

I would say most systems are either slower or less correct, yes. The nice thing about being a developer is that these costs are mostly hidden from us. The business pays for more compute if you churn out slow code, and churning out bugs just increases your job security. Imagine if you had to pay for the performance loss or production bugs directly though...

For the rare case where the small speedup is otherwise worth the lower producitivty of Rust, it can still be a worse choice because the you have a disadvantage in iteration speed to rework the code for a faster problem solving strategy / algorithm.

On the contrary, I find the speedup due to rust to be quite large and the productivity to be quite acceptable. Refactoring for me is so much easier when I can rely on the compiler to catch so much.