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

221–230 of 811 posts

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

#221

Post by hintymad »

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…

A naive question: do I have to use async to build a web service or RPC service? If I code in Java, I rarely need to worry about async since a service framework will take care of concurrency. I may throw in thread local and a scheduler here and there to handle some shared context or background tasks, or using some bounded queue to manage some boutique concurrency. Will using Rust be similar? Or I’d have to know all the async as people mentioned in this thread?

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

#222

Post by DeathArrow »

FpUser wrote: post #86
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 don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "we…

That's not my experience. I'm 3 times more productive at writing web apps in C# than in C++ and that is not even taking into account compile times and hot reload and doing unit tests.

Maybe I'm the worst C++ programmer in history and maybe I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience.

Aside from doing more boiler plate code, the language being more ceremonious, I find that I miss the tools like frameworks and libraries which are very easy to integrate with each other and which I take it for granted in C#. Probably the story is the same with any other language used for web: Java, JS, Ruby, Python and even the (in)famous PHP.

I think the situation can be much better if someone would make some nicely designed frameworks and libraries, but I guess no one is interested to as C++ is perceived as a "not for web" language. People who are into C++ are generally systems programmers who are not into Web, and people who are into Web are taught they only have to use "web languages".

That is really a shame because for some situations there would be a huge benefit of having performant web apps - scaling out is not always a solution to a performance problem.

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

#223

Post by DeathArrow »

cmrdporcupine wrote: post #91
FpUser wrote: post #86

Earlier quoted context omitted.

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "we…

I wrote plenty of vaguely web stuff in C++ at Google. A lot of services at Google are C++. But it's kind of, not how the rest of the industry expects things. And most of that stuff there is now moving to Go.

>And most of that stuff there is now moving to Go.

Go is on the same page performance wise with Java and C#. Sure, if you don't need the best performance, you can move to another language. But, then, why did you start using C++ in the first place?

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

#224

Post by nemothekid »

Hirrolot wrote: post #155
nemothekid wrote: post #72

I've been doing async Rust since the tokio 0.x combinator days, and I remember being like OP. For some reason `Arc` did not exist in my mind and it was a struggle appeasing the borrow checker. The Go version is similar to the final Rust version; except the Go version is forcing you to use Arc everyone[1]. Seriously, just use Arc (or Arc >), in 70% of cases you are wrestling with the borrow checker trying to do someth…

I do completely agree with your advice of using `Arc`s. But unfortunately, sometimes it gets very tedious to deal with all these `Arc`s: https://github.com/teloxide/teloxide/blob/ec1d41220c51872cf9... . It also blurs the advantage of Rust as a lifetime validation tool if you use reference counting anyways. But it seems that it's the only viable approach for async at the moment.

I have plenty of code like that:

    let id2 = id.clone();
    let watch_id2 = watch_id.clone();
    let id3 = id.clone();
    let watch_id3 = watch_id.clone();
    let ready2 = Arc::downgrade(&ready);
    let video_stream = async move {
        //  use id2, watch_id2, id3, watch_id3, ready2
    }
My realization is that in most cases an Arc is the right tool for the job, especially in concurrent applications. I see it as the borrow checker doing it's job, if you have two threads that need to share data and one of them may go away at any moment, the only way you can ensure the memory stays around is with "runtime borrow checking", e.g. a garbage collector.

In C++, the way this is solved is usually "just trust me, I won't use this memory here"

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

#225

Post by coderenegade »

cmrdporcupine wrote: post #69

I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times. Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experi…

>Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?!

This was my experience of rust as well. I've since forgotten exactly what I was trying to do (it was a year ago now), but a seemingly innocuous check of the variable I was using meant I couldn't use it immediately afterwards. I have no issues with move semantics in C++, but making that the default behavior in rust made it a pain in the ass to use, especially when it doesn't seem to be consistent. I ended up rewriting a week's worth of rust in C++, including the unit tests, over two days.

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

#226

Post by DeathArrow »

crabbygrabby wrote: post #76
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++…

Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.

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

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

#227

Post by fulafel »

crabbygrabby wrote: post #80
koyote wrote: post #47

As someone that has only dabbled in Rust, the post reminds me of C++ and its mind-boggling templating system. Rust even seems to provide you with the multi-page compile errors. Is it really as bad, or does the post only highlight the misery you get when you're working on the fringes of what the language is capable of doing?

It's actually really fun once you get the hang of it and realize the compiler is there to help you ship code that runs! This person hit a rough spot and got very frustrated basically... It happens, it's part of learning. The hardest thing about rust is, it tells you straight up when you don't understand something you are trying to do. For people who are otherwise productive and think they know certain things, this ca…

Though most people don't get the hang of it.

Some people also get into C++ templates and build complicated things with them for fun (eg the whole subfield of template metaprogramming came from inventing a clever abuse of the accidental power of templates as a poor man's macro system)

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

#228

Post by broodbucket »

LoveGracePeace wrote: post #157

I'm very confused. Rust is mainstream? C, C++, Java, C#, Python, JavaScript are all what I would call mainstream. Rust is not a language that comes to mind at all.

Rust has hit the point where it's in the conversation for what language you'd write a new project in, even for big companies (typically the most lethargic). I'd say it's at the level of mainstream where there's Rust being written in a significant portion of the industry, but not at the level of mainstream where it's somewhere in the stack behind most of organised society

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

#229

Post by otabdeveloper4 »

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…

You don't need async. It provides no performance benefits if you're not using a garbage-collected runtime.

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

#230

Post by DeathArrow »

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 wish there was a Rust-like programming language that was just a little bit higher level than Rust.

I think F# might fit this role.

Post reply on HN