Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

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

#681

Post by ncmncm » Fri, Jun 03, 2022, 9:11 PM UTC

mikebenfield wrote: post #646

ncmncm wrote: post #597

Earlier quoted context omitted.

If it is bad that C++ evolves, then it is worse for Rust, which has been evolving much faster, trying to catch up. It is still just barely possible Rust could avoid fizzling. For that to happen, it will need to change enough so that the many, many more people who reject than embrace Rust, as it is today, choose differently tomorrow. Evolution is necessary to stay relevant; the only alternative is stagnation. If your…

Rust is indeed changing pretty fast. But it's new. And most of the design decisions work well together. The language as of 2015-2016 was a reasonable language, and the changes since then have very rarely been of the form "This earlier design was a mistake, and we need to fix it all." But C++, even in its pre-template 1980s form, was already full of wrong decisions (granted, many of those decisions were done for compa…

In just another few years, if Rust does not fizzle, you will feel the same way about code in Rust as it evolves and improves.

But how C++ was coded to older Standards was not wrong at the time. That code was chosen judiciously according to features of the language as it existed then, and our understanding of it and our world.

Changes in languages are not random. Every last change in each new C++ Standard was in response to recognition that code would be better using the proposed change. Failing to use the new features as intended, after, would amount to choosing not to write code better.

Rust started at a snapshot of how problems of coding were understood at one time. Our understanding today and the world we program for have changed markedly from that time. Both will continue changing. What is good Rust will also change as the world, our understanding of it, and the language all change.

Failure to adapt is just failure.

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

#682

Post by steveklabnik » Fri, Jun 03, 2022, 9:13 PM UTC

cozzyd wrote: post #680

kobebrookskC3 wrote: post #521

Earlier quoted context omitted.

> Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-…

> i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)

That one was already reported to the tracker :)

https://github.com/rust-lang/rust/issues/32670

(To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)

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

#683

Post by moth-fuzz » Fri, Jun 03, 2022, 9:13 PM UTC

karmakurtisaani wrote: post #441

avidphantasm wrote: post #434

Earlier quoted context omitted.

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

the thing about Rust's ownership model is that a reference is not ownership, it's 'borrowing', and should be treated as such. But - and here's the kicker - the borrow happens as long as that reference is stored, not just when it's accessed i.e. dereferenced. This makes a number of data structures and patterns difficult and impossible to implement as you can't keep track of references to anything. You can't really make an opaque handle, for example, that can do operations through a stored reference. You have to store some ID or something and then when you want to do operations you need to pass the original container to the function anyway - so what's the point of even having reference types at that point?

IMHO Rust's lifetime analysis should consider borrows only at the point of dereference, not just whenever you encounter an & symbol. They already do that with raw pointers - you can have as many pointers as you want but you only need to mark `unsafe` if you actually dereference one. So at least someone on the team knows how to make that work functionally.

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

#684

Post by conradludgate » Fri, Jun 03, 2022, 9:26 PM UTC

pjmlp wrote: post #316

conradludgate wrote: post #299

Earlier quoted context omitted.

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

Scala, F#, OCaml, Kotlin,...

I have no experience with these languages. But it's worth noting that Rust is somehow more popular than all of these for a reason.

Possibly a combination of type safety + speed in one bucket makes the difference

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

#685

Post by conradludgate » Fri, Jun 03, 2022, 9:27 PM UTC

markasoftware wrote: post #671

conradludgate wrote: post #290

Earlier quoted context omitted.

Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start

What does Rust's compiler tell you that C#'s doesn't? You still have guaranteed memory safety in C#, and the type checker will verify against all type errors. I realize that Rust's compiler might catch more concurrency problems, but your comment is written as if you feel "blind" even writing single threaded code.

Rust's match is a lot more powerful than C#'s third party OneOf type alone

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

#686

Post by ncmncm » Fri, Jun 03, 2022, 9:29 PM UTC

jstimpfle wrote: post #632

bluGill wrote: post #536

Earlier quoted context omitted.

All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be. The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right…

You can also see it this way: The philosophy behind C++ is that the existance of a pointer implies ownership. In C, the existance of a pointer only implies liveness (normally; but really the code can decide on its own whether its safe to dereference the pointer). With the C++ approach I've found myself overthinking the problem many times. But with the insight that pointers are just data, and memory management can be…

You are confused.

There is no sense, in C++, in which a naked pointer implies or suggests ownership. It is the opposite: the continued validity of a pointer value depends on ownership maintained elsewhere. Nowadays libraries keep track of ownership. Most commonly the library delegates that responsibility to Standard std::unique_ptr, for familiarity. Not doing that indicates something different in play.

(It is, in fact, UB even in C to copy the value of a pointer to an object that does not exist anymore. This is the case regardless whether it had pointed to or into a stack or a heap object.)

In C, there is no way to express library ownership of a pointer. So, in C there is always potential for confusion about ownership.

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

#687

Post by ncmncm » Fri, Jun 03, 2022, 9:30 PM UTC

adjav wrote: post #617

bluGill wrote: post #536

Earlier quoted context omitted.

All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be. The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right…

I will note that Rust has all of those features you mentioned. 1) Traits 2) You have to be explicit, by implementing the Clone trait, otherwise arguments are passed by reference or moved. 3) Rust has both RAII and linear typing, which is effectively a proven-correct form of moves - you can't access something that has been moved, unlike C++. Rust doesn't have class inheritance, no, but often combining traits and deleg…

I agree that the GP comment does not capture what Rust is unable to express.

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

#688

Post by SleepyMyroslav » Fri, Jun 03, 2022, 9:33 PM UTC

Animats wrote: post #629

SleepyMyroslav wrote: post #418

Earlier quoted context omitted.

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.

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.

My interest in Rust and this topic is that i would like to see fine grained task parallel systems written in Rust. Instead of systems with separate thread for render that became a bottleneck years ago. I wish you good luck and hope to see a success story about Rust.

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

#689

Post by jules » Fri, Jun 03, 2022, 10:22 PM UTC

pjmlp wrote: post #633

jules wrote: post #474

Earlier quoted context omitted.

OCaml is great, but it lacks traits / type classes. That plus some syntactic tweaks would make OCaml amazing for most general purpose programming.

That is what functors and modules are for. And then the O in OCaml is all about OOP.

Functors and modules are nice but do not have the convenience of traits and type classes. The problem with functors and modules is that you have to manually instantiate the right functors and modules when you want to use some operation. Type classes and traits build the right instantiations for you based on the types.

I want to write `toString (1,true)` not `ToStringPair(ToStringInt)(ToStringBool).toString (1,true)`.

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

#690

Post by cozzyd » Fri, Jun 03, 2022, 10:30 PM UTC

steveklabnik wrote: post #682

cozzyd wrote: post #680

Earlier quoted context omitted.

> i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)

That one was already reported to the tracker :) https://github.com/rust-lang/rust/issues/32670 (To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)

Thanks, that was an amusing read!