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

721–730 of 811 posts

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

#721

Post by jokethrowaway »

hirrolot wrote: post #507
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…

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

There are two things to mention:

1. Async for trivial things is straightforward and easy

2. Rust actively discourages some async patterns to protect you from some memory misuse edge cases

It does limit your freedom in writing code that eg. relies a lot on async callbacks, but there's a reason. The first time I did a massive async project (think a rust binary maxing all cores executing the largest possible number of async fns doing various things in parallel - from fetching data online to running tensorflow) I came at it all wrong and wrote something that would have worked in node or haskell but that was a pain to compile in rust.

After days of pain I understood what rust wanted and nowadays I use the same pattern and it's fairly easy for me. Just another tool in the shed.

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

#722

Post by Animats »

SleepyMyroslav wrote: post #688
Animats wrote: post #629

Earlier quoted context omitted.

I'm using Rend3/WGPU, where multithreaded rendering is coming, but isn't here yet. Work is underway.[1] The Rust game dev ecosystem is far enough along for simple games, but not there yet when you need all the performance of which the hardware is capable. [1] https://www.youtube.com/watch?v=DDG4bcGs7zM

Cool video that matches best practices. Reducing memory footprint is always good and laying out things in memory is also good way to speed things up without changing amount of work. I have trouble with concept of WGPU. GPUs are complex by themselves to bolt on top any abstraction that is coming from Web. But its just me, its not important since I am not a 3d programmer myself. I am more Engine / CPU optimization guy.…

We'll see how it works out.

WGPU's API is basically Vulkan. It exists mostly to deal with Apple's Metal. Metal has roughly the same feature set as Vulkan, but Apple just had to Think Different and be incompatible. I'm not supporting the Wasm or Android targets. Android and browsers have a different threading model, and I don't want to deal with that at this stage. Linux/Windows/Mac is enough for now.

Thought for the near future - will VR and AR headgear have threads or something more like the processes with some shared shared memory model from Javascript land?

(That video isn't me, it's the Rend3 dev, who also works on WGPU.)

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

#723

Post by adastra22 »

Morgawr wrote: post #319
adastra22 wrote: post #251

Earlier quoted context omitted.

> I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely Every game company ever. And Google.

The Google team I work on (ChromeOS, crosvm[0] specifically) has been transitioning to Rust for a lot of our new services (mostly crosvm and stuff that interacts with it) and I couldn't be happier :) [0] https://google.github.io/crosvm/

The claim was "continuing to use C++ indefinitely." For that not to be true they'd have to be looking at replacing C++ entirely. Moving everything to rust/go/whatever. Do you foresee Google doing that?

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

#724

Post by snthpy »

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…

Have a look at nim through the lens of this talk:

https://youtu.be/j0fUqdYC71k

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

#725

Post by CraigJPerry »

skohan wrote: post #715
CraigJPerry wrote: post #678

Earlier quoted context omitted.

>> I'm not a go expert Yeah me neither, i’ve just been dabbling for fun recently. I’ve been dabbling with rust for longer >> the Go way seems to have more boilerplate … switch t := s.(type) { case Circle: if t.radius https://go.dev/play/p/s4TTZeo7Gse Definitely less boilerplate in the rust version, but i don’t think i go along with it being incomplete or less clear.

I think this is less clear than. The rust/ swift version.

That’s fascinating, what would you say obscures clarity?

Go: https://go.dev/play/p/s4TTZeo7Gse

Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio...

For me, i reckon the Go type machinery is more verbose in this case, e.g. the isShape method to tag Circle as a shape - that just feels awkward to me.

The cyclomatic complexity is identical for both though.

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

#726

Post by Morgawr »

adastra22 wrote: post #723
Morgawr wrote: post #319

Earlier quoted context omitted.

The Google team I work on (ChromeOS, crosvm[0] specifically) has been transitioning to Rust for a lot of our new services (mostly crosvm and stuff that interacts with it) and I couldn't be happier :) [0] https://google.github.io/crosvm/

The claim was "continuing to use C++ indefinitely." For that not to be true they'd have to be looking at replacing C++ entirely. Moving everything to rust/go/whatever. Do you foresee Google doing that?

Google as a company? Not necessarily, I don't have a crystal ball.

ChromeOS as a product? Maybe. (note: not Chrome)

ChromeOS platform internals? I totally could. You don't just rewrite everything from C++ to Rust, because that wouldn't make much sense, but more and more new service/products are being spun up that use Rust (we have docs and stuff https://chromium.googlesource.com/chromiumos/docs/+/master/r...).

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

#727

Post by wheelerof4te »

steveklabnik wrote: post #636
wheelerof4te wrote: post #631

Earlier quoted context omitted.

"I invite you to join the community and learn it. It's a lot of fun once you get proficient with it." I will if the Rust community agrees on a lighter, less complex language core. "Microsoft, AWS, government agencys in Europe, the Linux kernel itself (the only other language allowed there is C - think about it)." Again, they are using only a subset of the language. Linus allowed it in the kernel once devs agreed only…

You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features. They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted…

So, what software can you make without relying on "std" library?

I think that a lot of complexity in Rust comes from many different ways to handle memory. You have your Arcs, Boxes, Cells, etc. Then you have a core "alloc" library.

Maybe if everyone agreed on a single reliable method to handle heap memory (since using stack is easy), Rust wouldn't be so hard to use.

The syntax also could be improved. Seeing or whatever nested three or more levels deep hurts my eyes.

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

#728

Post by timClicks »

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

That's actually one of the reasons that I asked. I am the author of Rust in Action and wondered if the person having trouble had investigated one of the more practical resources.

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

#729

Post by pjmlp »

adgjlsfhk1 wrote: post #720
pjmlp wrote: post #481

Earlier quoted context omitted.

It partially succeeds at that, because while it has a much better story in being safe by default, there are plenty of C++ use cases where Rust still hasn't a story to sell. HPC, HFT, GPGPU, LLVM/GCC infrastructure, GUI, console SDKs, drivers SDKs, security certification ,....

imo, Julia is a better fit than rust or C++ for hpc/gpgpu

It might someday, still lots of room to improvement regarding current workloads.

I not not seeing Fermilab or CERN doing real time beam processing in Julia anytime soon.

Or stuff like having graphical shader debugging tools for Julia.

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

#730

Post by ngrilly »

dgunay wrote: post #695
ngrilly wrote: post #655

Earlier quoted context omitted.

3 issues you listed with Go are actually about the same thing (the lack of sum types): - Go has nil where Rust has Option. - Go has weird not-quite-tuple returns & if err != nil where Rust has Result. - Go has no real enum concept, where rust has its powerful enums and matching constructs. And the point on generics coming late is unfair. All programming languages got major features introduced late (for example async/…

Yeah I don't mean to criticize Go's generics for being less featureful given how late they were introduced, but they do currently prevent me from building any kind of mapping/filtering/pipeline style code because of their limitations (no generic type parameters on methods). A Go implementation of Result or Option could paper over the lack of sum types if we only had that. The more I think about it, what I really want…

I absolutely agree with everything you just wrote and would use a language like that.
Post reply on HN