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

291–300 of 811 posts

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

#291

Post by therockhead »

dagmx wrote: post #116
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…

Sounds like you're describing Swift. I'm trivializing it, but Swift is basically a higher level Rust with everything wrapped in an Arc.

As someone who does Swift 9-5 and dabbles with Rust, this statement rings true to me.

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

#292

Post by gspr »

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.

I think I'm quite fad-resistant (others would use less positive words to describe the same attribute). I still find Rust truly excellent, and the most joy I've had programming since Haskell (while at the same time being a lot more mainstream and pragmatic choice for collaborative projects than Haskell).

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

#293

Post by dochtman »

ThePhysicist wrote: post #250

Just got started with Rust and yeah, my biggest pain point so far were lifetimes and async code. I finally replaced tokio with multithreaded blocking code, which seems to be much simpler and more familiar. The problem with async was that some of the libraries I needed (e.g. for QUIC) didn't support it, so you had an unholy mixture of blocking and non-blocking code. Coming from a C++ background I appreciate Rust's nov…

Which QUIC library did you use? Quinn (the one I work on) comes with an async/await interface.

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

#294

Post by HacklesRaised »

timClicks wrote: post #278
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.

No, it really is wonderful once you make it. Which resources have you used to learn?

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 that's not really a fair comparison.

I think what I really need is a project rather than learning resources, with time being our greatest enemy, I need motivation to get over the hump so to speak.

(Like I said, I might not be smart enough, or I might just be profoundly lazy).

Thanks for your reply.

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

#295

Post by therockhead »

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.

>if you use dynamic `Arc`s almost everywhere in your code,

Right but you dont have todo this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.

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

#296

Post by HacklesRaised »

lelanthran wrote: post #285
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 a language designed by people who's favourite language is not even pronounceable. Did you think that such a group of people, who place their love for the language above practical things like readability, would come up with a new language that cared about the user-experience[1]? As we see all the time WRT to programming languages, readability is more important than the more abstract stuff. > I hear all the argume…

My CVE comment was very much tongue in cheek.

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

#297

Post by TheCipster »

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…

I have high hopes for Jakt: https://github.com/SerenityOS/jakt

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

#298

Post by gspr »

ModernMech wrote: post #121
cmrdporcupine wrote: post #66

Earlier quoted context omitted.

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

I do it because the toolchain is so nice. I just do wasm-pack build --target web And it builds a little wasm file and some js shim, and that's all it takes to get a Rust website up and running.

I find that part a hurdle, actually, despite loving Rust. I'm struggling with magic tools like wasm-pack that take over the build process. Cargo is fine – I know what Cargo does and how and why it calls rustc. But finding out what wasm-pack and friends do has been an uphill battle for me.

Why can't I just compile to wasm32 with Cargo? What's missing?

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

#299

Post by conradludgate »

cmrdporcupine wrote: post #66
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.…

I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…

We use rust for web dev purely for the type safety. Having business logic encoded as a state machine in an enum with compile time checked matches makes the world of difference

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

#300

Post by ncmncm »

tptacek wrote: post #166
armchairhacker wrote: post #40

I personally believe that Rust is an exceptional language and it’s ahead of its time. Seriously, can you think of any other language with as incredible type system, incredible tooling, incredible performance, incredible package management and general package quality, incredible compilation target support, and practically no few backwards-compatibility quirks? But Rust is a really bad general-purpose language. Because…

I spent about 10 years as a professional C programmer, userland and kernel on Linux, BSD, and WinAPI systems, and I feel like I have a pretty solid grip on "how computers actually work and how languages compile" (I've written compilers with codegen), and "the what, why, and how of threads, the stack / heap, I/O, endianness, etc.", as well as (from C++) "dynamic dispatch, references, memory management etc.." and, like…

tptacek knows whereof he speaks.

Rust has opinions. They are all at least arguably reasonable opinions. But, often enough, you have sound reasons to do things differently. Then, Rust will fight you.

Rust is a pretty good language, and is getting better, but it just takes a very long time for a language to mature. There are no short cuts.

When Rust is mature it will be very far from simple. People will talk about which language subset they are working in. It goes with the territory. Tools that adapt to the real world get as complicated as the world they serve.

Post reply on HN