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

441–450 of 811 posts

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

#441

Post by karmakurtisaani »

avidphantasm wrote: post #434
roblabla wrote: post #333

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

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). For now I stick with languages with GC.

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

#442

Post by pjmlp »

tucnak wrote: post #405
pjmlp wrote: post #313

Earlier quoted context omitted.

> Go is the new Java. I hope not, it might have some generics now, but still has a lot to catch up with. I surely don't miss coding in Java 5 (2004). > Rust is the new C++ Rust might become the new C++, and while being safe by default is great, there are plenty of C++ use cases where Rust has zero presence in 2022.

Generics were around for some time now, and people don't seem too keen on using them for anything aside from data structure specialisation, because frankly dynamic dispatch via interfaces hits such a sweet spot where you get a lot done with a very minimal overhead. The added syntactic complexity is very rarely justified, and containers is perhaps one of those cases where it is the case. Otherwise, from what I observe…

Yet even Objective-C, eventually got generics in 2015, despite protocols and categories.

The good reason is the target demographics as Rob Pikes puts it, people that don't care about learning what programming language can be like.

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

#443

Post by jeroenhd »

jandrewrogers wrote: post #190
jeroenhd wrote: post #53

Earlier quoted context omitted.

Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…

In fairness, for the kind of software that C++ is particularly suited, the idiomatic software architecture is thread-per-core, which has the distinction of being almost entirely single-threaded at the code level. Race conditions aren't a meaningful concern because data virtually never crosses thread boundaries. The bigger issue, particularly and mostly for C code, is object lifetime management. If maximum performance…

You're not wrong, but the crux of the problem described in the article is that Rust's object lifetimes are very hard to get right (even for the people working on the compiler) when working with cross-thread code.

I'm no professional Rust dev but I wouldn't have written the code like this; I know Rust isn't particularly suited for this style of callback mechanism and I know not to try and force this paradigm into Rust the same way.

For example, I think the author would have had a much raiser time if instead of passing async futures, they'd use channels or some other message passing mechanism in combination with a bunch of blocking threads to communicate events. Such a mechanism would also translate into Go quite easily (less so for other languages, though).

This example was deliberately picked to show a complex problem with writing Rust. I don't think this represents a challenge you'd face very commonly if you were programming Rust all day, at all. It's not bad criticism, but it appears to imply a much wider problem than there really is, in my opinion.

I don't really know what kind of programs require such an elaborate callback system commonly enough where it even makes sense to use Rust. C#, Java, and Go are fast, easy to write, and each have libraries to do almost anything you want. That 10-30% speed boost you can achieve with well-written Rust is probably not really worth the effort, especially with upcoming AOT compilation features in C#.

Rust isn't a solution to all problems, and neither is any other programming language.

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

#444

Post by DeathArrow »

kaba0 wrote: post #429
DeathArrow wrote: post #226

Earlier quoted context omitted.

It's at most 50% faster than Java and C# and not faster than C++. An order of magnitude would mean 900%, not 50%.

In practice, on bigger applications Go very much fails to be faster than Java or C#.

The point was about Rust. Go is on par with C# and Java.

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

#445

Post by mindri0t »

dgb23 wrote: post #382
HacklesRaised wrote: post #294

Earlier quoted context omitted.

I did ok with Rustlings and I read the 'The Book', I'd say I am largely struggling with async and lifetimes. I have spent most of my career in C, C++, Objective-C and have recently tried Zig, which I enjoyed, possibly because of it's brevity, and I read through the Jakt programming language docs, which was much more familiar to me but I think if you only used Rust with ARC it would be a simple language to adopt so th…

There are some very practice oriented books for rust: zero to production, rust in action. And a third one that I didn’t read, it is game programming focused and seems pretty good. Something with “handmade”.

I believe the game programming one you are thinking of is “hands on rust” by Herbert Wolverson. I haven’t read all of it, the parts I have read are quite good but I’m not big into games so I switched over to rust in action.

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

#446

Post by EugeneOZ »

kaba0 wrote: post #435
EugeneOZ wrote: post #416

Earlier quoted context omitted.

Does it have a borrow checker and mutability control?

It is a GCd language, a borrow checker is very seldom needed outside of that (and frankly, one should just use try-with and similar constructs for other kinds of resources), so why would it need one? As for mutability, it is not enforced on a language level (only shallowly), but the standard library, the language primitives and basically everything makes control over mutability very good. In practice it won't be much…

“Side-effect” of borrow-checking - there is always only one who can write to a variable. It's much more important than GC.

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

#447

Post by sai_c »

Dowwie wrote: post #391
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.

It's not a matter of smarts but grit. Modern society cultivates short attention spans, impatience, and a need for instant gratification. It's really uncomfortable, and costly, for many to spend hundreds of hours cultivating a new skillset. So, many give up shortly after starting to pursue it. However, those who persist and achieve capabilities come to value what those capabilities offer over alternatives.

If you ask an embedded developer (as in bare metal, no OS), who is also into electronics, instant gratification and especially instant feedback, is what actually makes you choose this path of interest in the first place.

It's a matter of style and character how you cultivate new skills, and Rust wants you to cultivate them in a certain, some people are just not made for. YMMV.

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

#448

Post by kaba0 »

DeathArrow wrote: post #444
kaba0 wrote: post #429

Earlier quoted context omitted.

In practice, on bigger applications Go very much fails to be faster than Java or C#.

The point was about Rust. Go is on par with C# and Java.

Sure, just many people do believe that Go is somehow faster than the other two, so I thought it would be worth to chime in.

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

#449

Post by [deleted] »

tcfhgj wrote: post #415
blub wrote: post #398

Earlier quoted context omitted.

Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.

I have been way more productive with Rust than with C++. For instance, I haven't yet had to debug weirdly muting memory, deal with the immense nuanced possibilities of doing the same thing (there's a reason for CPP core guidelines), stuff like the rule of five, writing cross platform cmake files that include various libraries, ... Not proof for a general statement, but another example from a Rust adaptor

[deleted]

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

#450

Post by kaba0 »

EugeneOZ wrote: post #446
kaba0 wrote: post #435

Earlier quoted context omitted.

It is a GCd language, a borrow checker is very seldom needed outside of that (and frankly, one should just use try-with and similar constructs for other kinds of resources), so why would it need one? As for mutability, it is not enforced on a language level (only shallowly), but the standard library, the language primitives and basically everything makes control over mutability very good. In practice it won't be much…

“Side-effect” of borrow-checking - there is always only one who can write to a variable. It's much more important than GC.

Oh I see. No it does not have it enforced at the language level, but it relies heavily on immutable data structures, and the type system is strong enough to express a complete actor-based concurrency library.

But since it is interoperable with Java and that exposes low-level primitives of concurrency, it can’t really be made guaranteed data-race free.

Post reply on HN