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

781–790 of 811 posts

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

#781

Post by iopq »

icedchai wrote: post #576
Aeolun wrote: post #493

Earlier quoted context omitted.

Rust is really hard. So while people that don’t like Javascript still continue to use it, but people that don’t like Rust are likely to drop it like a brick.

Rust is too painful for hobby projects, IMO. Over the years, I've worked in C, C++, Go, Perl, Python, PHP, Java, Scala, JS, Tcl, ... others I've forgotten, most professionally and well as for personal projects.

I've used Rust for a hobby project, it was more painful before, but they have fixed a lot of the churn issues. The ecosystem is more or less stable right now, compared to before

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

#782

Post by iopq »

avidphantasm wrote: post #434
roblabla wrote: post #333

Earlier quoted context omitted.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

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?

Because it's a library feature, exactly the thing you should use "unsafe" in, since it should be simple enough to be obviously correct

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

#783

Post by adgjlsfhk1 »

nimrody wrote: post #775
adgjlsfhk1 wrote: post #719

Earlier quoted context omitted.

if your GC eats 70% is your clock cycles, your language has a broken GC. in modern Java/C#, GC time is rarely more than 10%

To get to a low GC overhead in Java (and perhaps other languages too) you have to pay with an increase in memory consumption. Sometimes as much as 100% additional RAM to avoid frequent full GC scans.

That's true, but malloc/free based systems also have a relatively high memory overhead due to fragmentation and programmers being worse at inserting frees than the GC. It's not at all clear that the C/C++ model of memory management has lower than 100% overhead for long running programs.

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

#784

Post by foldr »

mumblingdrunk wrote: post #777
foldr wrote: post #768

Earlier quoted context omitted.

> it is just that the borrow checker cannot verify the soundness of certain code And I was just proving examples of such code for someone who asked. Honestly, some Rust folks get so defensive it makes them very prone to misinterpret simple factual statements about Rust as criticism. Apparently you don’t disagree with any of the factual statements that I’m making. You just have some vague unsubstantiated feeling that…

I'm not fighting your claim that the borrow checker has perfectly reasonable situations it can't deal with. That's why 'unsafe' exists. I've already said that. You're adding other claims and statements that make me question if you actually understand the thing you are criticising.

If you'd say what those claims and statements were, then we could have a conversation. It's not conducive to a good discussion to reply just by saying "you're wrong and you don't get it".

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

#785

Post by int_19h »

justinsaccount wrote: post #640
dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. 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. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

As someone that writes a bunch of go but has never really gotten off the ground with rust: * Option? I don't mind if err != nil, but sure, it would simplify some things. * Result and real tuples? awesome. * real enums? sign me up. If that was all added to go I wouldn't mind at all. But what does any of that have to do with impl Execute for Dispatcher where H: Fn(&'a Update) -> Fut + Send + Sync + 'a, Fut: Future + Se…

It is a serialization of relative lifetimes, basically. Whenever you write code in any language that doesn't have a GC, you either have to maintain a mental map like this to avoid bugs, or you make the language do it for you like Rust does.

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

#786

Post by int_19h »

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…

There's no shortage of good-perf languages with a GC: F# would be one prominent example that sounds very similar to what you describe.

The usual objection is that it requires a .NET runtime, whereas Go produces a single self-contained executable. But .NET can produce self-contained executables these days.

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

#787

Post by jerf »

crabbygrabby wrote: post #108
jerf wrote: post #87

Earlier quoted context omitted.

Rust does not in general have an order of magnitude advantage over Go. 2 or 3 would be closer, and that's with some nontrivial attention paid to optimization, not "you write Rust and it's automatically always faster". Super high-end stuff can outclass Go by that much, like if you're seriously using DPDK or something, and in those cases I strongly recommend Rust over Go. There some other noches like that. But in gener…

It really depends. I agree it's not always an entire order of magnitude didn't mean to paint that picture for passerbys who don't know better. Not trying to touch the "this lang vs that lang performance" conversation with a ten foot pole...

10x improvement over Go is a reasonable expectation, in a limited set of environments, generally at a scale where you're looking at using every last bit of a 32-core or 64-core machine and doing a lot of memory work. You should also expect to be spending a lot of time optimizing that Rust to get there. But when you need that level of performance, you also basically made a mistake starting with Go in the first place.

However, by far the bigger problem is people thinking their little web service serving out 5 requests a second requires that level of optimization when in fact even a Go implementation will use It's a delicate understanding, but an important one for a professional.

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

#788

Post by ngrilly »

int_19h wrote: post #786
dgunay wrote: post #695

Earlier quoted context omitted.

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…

There's no shortage of good-perf languages with a GC: F# would be one prominent example that sounds very similar to what you describe. The usual objection is that it requires a .NET runtime, whereas Go produces a single self-contained executable. But .NET can produce self-contained executables these days.

Yes, .NET can produce binary executables, but is it a common practice? I’m asking because I think the ecosystem matters a lot. If it’s a common practice, then it’s more tested and more stable and you get more tools and documentation.

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

#789

Post by CraigJPerry »

preseinger wrote: post #774
CraigJPerry wrote: post #725

Earlier quoted context omitted.

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.

This Go code is wildly non-idiomatic. Type assertions via `.(type)` are a tool of last resort, not something that an application developer should turn to as a solution to a problem, and certainly not post-1.18, which permits generics. edit: e.g. https://go.dev/play/p/wDO5J8CElSC

Hey thanks for sharing this, I think this has lost track of the problem though, remember we're looking for the alternative to rust's:

    enum Shape {
        None,
        Circle(radius: usize),
    }
In your version we've lost the Shape concept, to make it more explicit, what's the idiomatic go version of:

    enum Shape {
        Circle(usize),
        Rectangle{length: usize, breadth: usize},
    }
https://play.rust-lang.org/?version=stable&mode=debug&editio...

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

#790

Post by int_19h »

ngrilly wrote: post #788
int_19h wrote: post #786

Earlier quoted context omitted.

There's no shortage of good-perf languages with a GC: F# would be one prominent example that sounds very similar to what you describe. The usual objection is that it requires a .NET runtime, whereas Go produces a single self-contained executable. But .NET can produce self-contained executables these days.

Yes, .NET can produce binary executables, but is it a common practice? I’m asking because I think the ecosystem matters a lot. If it’s a common practice, then it’s more tested and more stable and you get more tools and documentation.

It's a relatively recent feature, at least the "pure" implementation (what they had before was, essentially, a self-extracting binary), so it's still gaining popularity. But seems to be fairly common with containers.
Post reply on HN