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

411–420 of 811 posts

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

#411

Post by kaba0 »

FpUser wrote: post #360
estebank wrote: post #88

Earlier quoted context omitted.

In industrial machines, there's such a thing as holding it wrong. In some cases, that means getting maimed (that old-school table saw doesn't care whether it chews on wood or flesh) or precluded through a clunkier mode of operation (you need to press these two buttons separated at roughly arm length to make sure that they can't be actioned while you have an arm in the way of the heavy arm-eating chunk of metal). The…

>"You're trying to draw a comparison with a consumer product with a design flaw." Not at all. I just do not like to dance around bonfire with tam-tam and being told that this is the one and only way

It's not the only way, but if you do the tradeoff of going with manual memory management, then you should accept what the tradeoff entails. Essential complexity is non-reducible -- you either manage it automatically through a GC or choose a model that while let you ignore it quite often, will make you think about it in the end.

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

#412

Post by kaba0 »

wongarsu wrote: post #358
chombier wrote: post #307

Earlier quoted context omitted.

Can one really escape clone hell afterwards, though?

I generally go by the principle to borrow if I can without effort, otherwise I think a second of the code is in the critical path or the object is megabytes in size. If neither is the case, I clone without shame. The remaining 0.1% gets my attention (Arc, lifetime annotations, refactoring, or whatever is appropriate). The important part is perspective. Nobody cares if you clone your command line arguments ten times d…

Exactly. Even very experienced people will be easily misled to believe something is performance-sensitive -- computers are ridiculously fast. Like honestly, if it is not a tight loop chances are it seriously doesn't matter what you do. Remember, we write plenty of shell scripts that literally spawn a new process for almost every line, and yet they feel instantaneous.

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

#413

Post by withoutboats2 »

the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

> Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years.

As the primary mover of the MVP (who stopped working on Rust shortly after it was launched), I'm really sad to see this. I certainly didn't imagine that 3 years later, none of the next steps past the MVP would have even made it into nightly. I don't want to speculate as to why this is.

I also recommend avoiding async if you don't need. Unfortunately for people who don't need it but do want to do a bit of networking, a huge part of the energy behind Rust is in cloud data plane applications, which do need it.

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

#414

Post by kaba0 »

rapsey wrote: post #135
josephg wrote: post #92

Earlier quoted context omitted.

> If you have a long-running async function, then pass parameters by value! If you have a polymorphic async function, then return your result in a Box. I've taken to making heavy use of the smallvec and smartstring crates for this. Most lists and strings are small in practice. Using smallvec / smartstring lets you keep most clone() calls allocation-free. This in turn lets you use owned objects, which are easier to re…

However the constant checking if something is on the stack or heap is a big performance problem for smallvec. It results in terrible cpu branch prediction.

I don't see how is it bad for branch prediction. Like, if you use the same smallvec object in a loop and do not insert any elements to it (so that it doesn't allocate on the heap) the branch will always turn in the same direction making it easy and cheap to predict. And I would think that in most use-cases your smallvec object will either remain in one state, not changing in-between.

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

#415

Post by tcfhgj »

blub wrote: post #398
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…

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

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

#416

Post by EugeneOZ »

kaba0 wrote: post #406
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…

Scala might just be that. It has a very strong type system which is quite similar to Rust's, lifetimes are managed by the JVM's state-of-the art GC, and all in all it is a very expressive language. Think of python-level expressivity, but all statically typed with type inference. It also has a similar stance on the functional-imperative question as Rust has - it prefers functional concepts but lets you write imperativ…

Does it have a borrow checker and mutability control?

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

#417

Post by anonymoushn »

TazeTSchnitzel wrote: post #339
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.

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

I'm not sure this is true. The aliasing model of unsafe Rust seems much more difficult to write correct code for than these other aliasing models.

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

#418

Post by SleepyMyroslav »

Animats wrote: post #279
brabel wrote: post #242

Earlier quoted context omitted.

> So much of this pain is caused by premature optimization. Rust is normally used only when high performance is of uttermost importance, so it will always attract people who want to optmise everything. > Most of the time, the solution is to be less clever I've done it myself and saw performance degrade, as was expected. That's fine, but by that point you might as well just use another language that has none of the ha…

> Rust is normally used only when high performance is of uttermost importance, so it will always attract people who want to optimise everything. Which is not the way to do things. Profile, then optimize. I'm writing a metaverse client that's heavily multithreaded and can keep a GPU, a dozen CPUs, and a network connection busy. Only some parts have to go fast. The critical parts are: * The render loop, which is in its…

Coming from gaming industry i think you might want to measure how far you can go with a single threaded rendering. There is limit of content and code that can be a brick wall later. Here is an example from SIGGRAPH 2021 where Activision presents how multithreaded rendering looks like: https://youtu.be/9ublsQNbv6I ps I don't work with Activision its just a public example that illustrates industry practice.

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

#419

Post by kaba0 »

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…

Generics as a feature is almost invisible when it exists and is done well, but is a huge pain in the ass if it doesn't. It is mostly needed for libraries, so your average dev won't write them often, but there it is invaluable.

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

#420

Post by unrealhoang »

wiz21c wrote: post #328
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…

I've been leraning rust with a pet project of mine (an Apple2 emulator). That was a bit too complex for a start as I had threads and a bit of architecture to structure my code correctly. But in the end, I know understand how rust does threads and memory allocation and I'm now much less intimated by the type system. I still don't get the lifetimes. Moreover, a lot of the libraries in rust needs you to understand the t…

> Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure).

Mainly because logger is a static value, if you really want to change your logger at runtime, then you have to pay a little bit for synchronization (i.e. locking with mutex), other than that, it's not that hard.

Post reply on HN