Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Rust difficult?

vorner.github.io

Post reply on HN
Print view View original

161–170 of 260 posts

Re: Why is Rust difficult?

#161

Post by pornel »

titanix2 wrote: post #38
sillysaurus3 wrote: post #14

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

This is the exact reason I won’t learn Rust past looking quickly the doc: the promotion made by some very vocal people is a huge turn off. Notably by saying that everything must be rewritten in Rust, it implies that every other language is sh*t and people using them are dumb. Of course I don’t like that view for my work nor I won’t to be associated with this kind of people. This is a bit sad because the language prob…

Just for the record, the annoying vocal promotion is not coming from the Rust team. The people who actually know the language know its limitations, and discourage overhyping it. Language flamewars are banned on all forums moderated by the core Rust community.

Re: Why is Rust difficult?

#162

Post by dolguldur »

Will Swift ever be able to span all the way down to enable Rust-like performance in places where it’s necessary?

Or is it much more that it takes for a language to be a viable choice for starting new C++ type of projects with?

Re: Why is Rust difficult?

#163

Post by brightball »

josephg wrote: post #76
jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

The Elixir performance penalty compared to Go isn’t as big as people think. It largely depends on what you are doing but the perk that your get is consistency of response time.

This is one of the better articles that shows both when comparing Python, Go and Elixir.

https://medium.com/unbabel-dev/a-tale-of-three-kings-e0be17a...

Re: Why is Rust difficult?

#164

Post by nly »

jonathanstrange wrote: post #123
jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

> That being said, Rust is already so obscure that it can easily replace C++

An obtuse syntax is a big downside of C++. Implying that a steep learning curve and the ability to 'show off' helps keep the language where it is grossly misrepresents the vast majority of C++ programmers. Those traits were born out of necessity. In C++98 you simply had to be 'clever' to keep up with modern languages because the language was stagnant for a decade. If the committee can't add things, you do something clever and do it yourself.

C++ was stagnant for the dot-com era, Web 2.0, and the rise of mobile apps, and today it thrives. There's more to that than being entrenched in legacy code bases.

Rust emulating C++s difficulty as a way to cultivate an elitist community, if that's what you're implying, will not work now when C++ is moving in the opposite direction.

Re: Why is Rust difficult?

#165

Post by gkya »

josephg wrote: post #76
jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I haven't used Go all that much, but arent the interfaces meant to be used as generics, i.e. in your function you need some data X, and you'll do something with that X. The way you need to achieve this is that expect an X that satisifes a given interface, say Exampler. If a particular X does not support it, you write the method(s) on X's type to satisfy the Exampler interface. IIRC Pike said somewhere that you don't need generics because there should be at least a singleton interface that all possible values of a function parameter satisfy.

(Edit: BTW I do not necessarily agree that)

Re: Why is Rust difficult?

#166

Post by steveklabnik »

kod wrote: post #146
tatterdemalion wrote: post #20

Earlier quoted context omitted.

- We are directing material resources (as in, hours of paid work) to improving compiler performance. We consider this a serious problem, and "the compiler performance is always improving" is not an accurate gloss of the amount of work people are putting into solving it. - We would love to have a REPL but there are nontrivial technical challenges, and it has not been a major requested feature by our users. - I have ne…

Only listening to current users for feature requests is selection bias. I'm not currently using rust, and lack of a repl is a big strike against it. Not as much of a strike as the lack of a good stable async story, but still.

We explicitly reach out to willing non-users to try and counteract said bias.

Re: Why is Rust difficult?

#167

Post by narimiran »

mamcx wrote: post #159
kqr wrote: post #128

Earlier quoted context omitted.

Second the Ada note. That language is so well constructed and thought out on many levels. ...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.) It's a shame because - Ada generic packages are exactly what C++ templates should have been - Derived types and record extension is inheritance that m…

I have done pascal before and I wish to have ADA more easily available.

> I have done pascal before and I wish to have ADA more easily available

Then you might be interested in https://nim-lang.org/ as a Pascal-like Rust alternative.

Re: Why is Rust difficult?

#168

Post by pjmlp »

lmm wrote: post #154
pjmlp wrote: post #147

Earlier quoted context omitted.

Well, declaring untraced references in Modula-3 or Active Oberon, or doing native heap allocations in Nim, D, Java and C# is relatively simple. Using GC languages doesn't mean doing 100% memory allocation via GC.

I've done it in Java; it's not officially supported in the language standard (or has only recently been added if so - certainly they were talking about it for years), and the wider language does not generally have the support or idioms you would want (e.g. try-with-resources was only introduced a couple of versions ago), libraries aren't oriented towards that style.... It's certainly doable but I'd stand by it not be…

Although I mentioned Java, due to ByteBuffers and Unsafe, it is clearly not the best one of the set of languages that I mentioned.

Others on that list have specific language features for GC free allocation.

Re: Why is Rust difficult?

#169

Post by mattgreenrocks »

kqr wrote: post #128
jonathanstrange wrote: post #123

Earlier quoted context omitted.

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

Second the Ada note. That language is so well constructed and thought out on many levels. ...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.) It's a shame because - Ada generic packages are exactly what C++ templates should have been - Derived types and record extension is inheritance that m…

Thanks for the rundown. Sounds like Ada has a lot of good ideas to steal!

Re: Why is Rust difficult?

#170

Post by alkonaut »

pornel wrote: post #160
singularity2001 wrote: post #81

(for newcomers) nothing works out of the box or as expected program[0]="+"; | ^^^^^^^^^^ the type `str` cannot be mutably indexed by `{integer}` error: use of unstable library feature 'collections': needs investigation to see if to_string() can match perf error: borrowed value does not live long enough reference must be valid for the block suffix following statement 0 When you use an index operator ([]) you get the a…

Rust is especially difficult if you bring your C-like assumptions to it. You first need to learn difference between a borrow (a view, which may be read-only) and owned type, and know that Rust enforces stdlib strings to be UTF-8. Random mutation of a byte in a string is possible, but it has been deliberately put behind an unsafe function call, and there are better alternatives available (like char iterators). It's no…

> Rust is especially difficult if you bring your C-like assumptions to it.

To be fair it's very difficult if you bring your JS/Python/C#/Java assumptions there too. As a lifelong Java/C# dev, I just never imagined having objects on the stack. In C# knowing what goes on the stack is important - but the thing with everything stack is that it's copied - so it's basically just trivial values that sit on the stack. In Rust and C++ you can make entire complex applications whose data is entirely on the stack. And getting over that treshold is a big mental barrier.

I'm used to just thinking of my app state as a blob on the heap. A functional programmer or a C++ programmer thinks differently.

Post reply on HN