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

581–590 of 811 posts

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

#581

Post by gspr »

ModernMech wrote: post #563
gspr wrote: post #298

Earlier quoted context omitted.

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?

As far as I know you can using the wasm32-unknown-unknown target. I think wasm-pack does extra stuff like supporting different targets like a nodejs module or a webpack compatible format, which is outside of the scope of something like cargo imo.

But what is that "extra stuff" that it does?

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

#582

Post by valenterry »

shultays wrote: post #389
valenterry wrote: post #345

Earlier quoted context omitted.

I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for as…

"good performance" is a relative term. You may consider Haskell or Scala having "good performance" but for others having garbage collection itself is a big no. So you are either left with Rust's approach where you limit the programmer, or C++'s approach where you leave memory management mostly to the programmer

I think you missed the point here.

My response was focussed on the part of the challenges of async logic. And what OP essentially said is that Rust does not only help performance because of the ownership model (vs. garbage collection), but also because it makes it easy to come up with correct and performant solution to async-related problems.

My point was that, when ignoring the performance benefits of ownership model vs. garbage collection, a language like Haskell or Scala makes a performant and correct solution for async problems easier than Rust does - at least at the current point in time.

I hope it's more clear now.

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

#583

Post by wvh »

iex_xei wrote: post #498
m25n wrote: post #467

Earlier quoted context omitted.

I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.

That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.

Sounds like Go. Just write code, then see if any obvious interfaces pop up and if you need them.

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

#584

Post by sph »

travisgriggs wrote: post #174
d3nj4l wrote: post #141

Earlier quoted context omitted.

I cannot, for the life of me, recommend Elixir enough! You write your code without every thinking of words like "async" or "await" and the VM handles it for you !

So this. You have to learn to think differently about your problem. But then when you do, so many of these other issues just go away. A small amount of our product offering is implemented in Elixir. I wish more of it was. It’s my favorite part of the whole thing.

Credit where it's due, this is all thanks to the BEAM and OTP being awesome.

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

#585

Post by CraigJPerry »

skohan wrote: post #427
blub wrote: post #396

Earlier quoted context omitted.

How you feel relates to you and your preferences and doesn't really say anything about Rust versus let's say Go. Is your software more performant and does this translate to additional customers or reduced costs? Is your software more stable and does this result in reduced support costs or happier customers? Testing effort is likewise not a decisive matter. In fact it's quite likely that what one wins time-wise on the…

Not the person you're responding to, but imo the main thing missing from Go is ADT's. After using these in Rust and Swift, a programming language doesn't really feel complete without them. That said, I think Go's simplicity has a lot of advantages over Rust for a great many use-cases. Imo Rust almost feels like a prototype for a great language which will finally get ownership-based memory management right. The goals…

>> the main thing missing from Go is ADT's. After using these in Rust and Swift, a programming language doesn't really feel complete without them

What are the differences between an ADT (plus pattern matching i’d reckon?) in Rust/Swift vs the equiv in Go (tagged interfaces + switch statement)?

One has exhaustive matching at compile time, the other has a default clause (non exhaustive matching), although there’s an important nub here with respect to developer experience; it would be idiomatic in Go to use static analysis tooling (e.g. Rob Pike is on record saying that various checks - inc this one - don’t belong in the compiler and should live in go vet). I’ve been playing with Go in a side project and using golint-ci which invokes https://github.com/nishanths/exhaustive - net result, in both go and rust, i get a red line of text annotated at the switch in vscode if i miss a case.

Taking a step back, there isn’t a problem you can solve with one that you can’t solve with the other, or is there?

To take a step further back, why incomplete?

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

#586

Post by lelanthran »

bluGill wrote: post #536
lelanthran wrote: post #363

Earlier quoted context omitted.

> Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff. Do you have any examples?

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…

Thanks, that is a very detailed answer[1].

I'm somewhat confused about why it was downvoted - there is nothing there controversial at all.

[1] In my own toy language, I'm kinda leaning towards objects with destructors. Definitely without the footguns in C++, but destructors nonetheless.

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

#587

Post by NoGravitas »

valenterry wrote: post #345
yeputons wrote: post #15

Earlier quoted context omitted.

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an…

I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for as…

You can get great performance from garbage collected languages, to be honest. I guess what you can't get is perfectly predictable latency — but that only matters for a pretty narrow class of applications.

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

#588

Post by CraigJPerry »

garethrowlands wrote: post #514
blub wrote: post #396

Earlier quoted context omitted.

How you feel relates to you and your preferences and doesn't really say anything about Rust versus let's say Go. Is your software more performant and does this translate to additional customers or reduced costs? Is your software more stable and does this result in reduced support costs or happier customers? Testing effort is likewise not a decisive matter. In fact it's quite likely that what one wins time-wise on the…

Rust and Go are surely different classes of programming language. Rust is a systems language and Go is garbage collected. That is, Go is in the camp with Ruby, Python and Javascript, whereas Rust is in the camp with C and C++. Garbage collected languages are easier to use than non-garbage collected languages, so if you can use them, you should.

Probably comes down to your definition of a systems language.

E.g. if that means implementing low level things like cryptography APIs, or being able to define the exact memory layout of objects in memory or access raw pointers or write ASM inline then obviously that disqualifies ruby, python and js but it would mean Go qualifies.

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

#589

Post by Santosh83 »

bluGill wrote: post #536
lelanthran wrote: post #363

Earlier quoted context omitted.

> Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff. Do you have any examples?

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…

> but I'll take C over C++ anyday.

Did you mean the opposite?

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

#590

Post by NoGravitas »

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…

Koka and Vale both seem to be decent (experimental) approaches to languages that learn from Rust, both what it got right, and what it got wrong.
Post reply on HN