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

121–130 of 260 posts

Re: Why is Rust difficult?

#121

Post by [deleted] »

Manishearth wrote: post #56
Animats wrote: post #50

Rust's problem is not correctness. The borrow checker is the good part of the language. It's feeping creaturism. The language started out as imperative, and then became semi-functional. It started out as thread-oriented, and now is acquiring "green threads"/coroutines/cooperative multitasking. The generics system and library started where C++ and Boost left off. The "trait" system was more "objects bad, must do somet…

Er, no, Rust started out pretty solidly as a functional language. It used to look like an ML variant, with purity and stuff. And it had a GC. It's lost most of that now. It also used to have green threads up till 1.0 (they were removed pre-1.0), we're now adding them back . And they're being added back as a library, not as part of the language. It moved away from both of these.

[deleted]

Re: Why is Rust difficult?

#122

Post by manveru »

vlovich123 wrote: post #117
majewsky wrote: post #87

Earlier quoted context omitted.

> In terms of correctness, I've never heard claims about improving security issues I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues. > As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;) Alternatively, writ…

> I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues. I think perhaps I didn't communicate my meaning clearly enough. Rust does significantly reduce the risk of a certain class of security problems (reduce not eliminate since it's highly unlikely you'll have 0 unsafe{} blocks anywhere in your dependency chain). That's not disputable since that's part of the langua…

I think Elm has some of the best engineering around that: http://elm-lang.org/blog/compiler-errors-for-humans and http://elm-lang.org/blog/compilers-as-assistants

While it's also not perfect or can correctly identify all possible syntax/intent errors, it's a valuable tool to learn the language nonetheless.

Re: Why is Rust difficult?

#123

Post by jonathanstrange »

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 performance guarantees and therefore work well with way more convenient garbage collected languages like Go, CommonLisp, and Racket.

That being said, Rust is already so obscure that it can easily replace C++ and I predict it a great future. Programmers love obscure programming languages with steep, long learning curves that allow them to show off.

Re: Why is Rust difficult?

#124

Post by pjmlp »

vardump wrote: post #113
pjmlp wrote: post #88

Earlier quoted context omitted.

Thanks for pointing it out, I wasn't aware of it and it does look good, but they clearly state the uses cases which it isn't fully ANSI C compliant on page 24 of the documentation.

I think you're nitpicking. That's close enough in my book. Those MCUs are tricky targets and I can certainly live for example with not being able to pass structs as return values. Or without re-entrancy. Perfectly understandable once you take into account limited IRAM space, 128 or 256 bytes, where stack, register banks and most of your temporaries and globals need to reside.

Which validates my point of using C on 8 bit CPUs being a challenge.

Re: Why is Rust difficult?

#125

Post by jonathanstrange »

jules wrote: post #114
adwn wrote: post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

Why does GC make it harder to call libraries in other languages?

Because you have to add support for GCing of foreign structures from these libraries, or keep the interface low-level and force the user of the GCed language to manually manage these foreign objects. Adding support for GC can be difficult if not impossible, because GCs often arrange memory in special ways (different pools, etc.) whereas the foreign library probably just uses malloc.

Re: Why is Rust difficult?

#126

Post by humanrebar »

jules wrote: post #114
adwn wrote: post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

Why does GC make it harder to call libraries in other languages?

Languages interfacing through an ABI implicitly need to agree on their memory models, calling conventions, exception unwinding, etc.

There's lots of detail in the D language garbage collection docs:

https://dlang.org/spec/garbage.html

The whole thing might be instructive, but 28.3.3 has a bunch of particular expectations of the D GC.

Re: Why is Rust difficult?

#128

Post by kqr »

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…

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 makes sense

- Access types are obvious in hindsight

- Correct terminology for procedures and functions does help a lot in communication

- RAII in the shape of controlled types feels a bit bolted on but it works very well

- Named blocks and explicit closing is easy but very useful

- Class-wide types are deemphasized the way polymorphism should be

- The -gnatyy flag is almost as good as gofmt.

- Tasks and protected types form a very intuitive and safe concurrency mechanism

- Having contract-based programming as an option built into the language is way superior to relying on asserts in the procedure

- While not always budgeted for, when there is time to spend, SPARK is uh-mazing. Strong guarantees at relatively low cost, and reasonably easy to learn as well.

Re: Why is Rust difficult?

#129

Post by always_good »

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…

On the other hand we ripped out channels and went back to mutexes. And my experienced Go-developer friends seem to have all the same reluctance to use channels after ending up in channel hell.

There are good aspects of Go concurrency like how the whole ecosystem is async by default (like Node's), but truly praising the model is something I mainly hear from beginners.

Re: Why is Rust difficult?

#130

Post by jcelerier »

johnnyanmac wrote: post #110
majewsky wrote: post #87

Earlier quoted context omitted.

> In terms of correctness, I've never heard claims about improving security issues I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues. > As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;) Alternatively, writ…

Ugh, C++ template errors, the bane of my existence (and why I personally avoid using anything beyond dead-simple ones unless I have to interface with STL). Only thing worse are Java generics, if only because they literally tried to tack them in 10 (heck, getting close to 15 years now) years ago and we are still feeling the consequences of those design choices today, (unless Java 8+ made major fixes to this. Haven't u…

template errors blurb a big wall of text, but if you know how to read it it only takes a few second to find in your code where your problem is. You generally just have to look at the "required from here" (in clang and gcc at least) message which points to your own code 9 times out of ten.

https://my.mixtape.moe/xdkchm.webm

Post reply on HN