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

Tell HN: Rust Is Complex

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 102 posts

Re: Tell HN: Rust Is Complex

#41

Post by Gigachad »

b20000 wrote: post #20
eloff wrote: post #14

Earlier quoted context omitted.

Rust is a systems language, like C++. I don't think your comparison is fair. Also I've done a lot of C++ programming over the years, and I won't willingly go back to that. It is a horror in my opinion.

The selling point of Rust is that it hides complexity from you and gives you "safe" memory management. That comes at a price.

Rust doesn’t hide complexity. It forces you to acknowledge it and handle it.

Rust largely won’t let you write the wrong thing, but you have to fully understand the nuts and bolts to know what it will let you do.

Re: Tell HN: Rust Is Complex

#42

Post by bsaul »

howinteresting wrote: post #34
howinteresting wrote: post #33

99.99% of Rust programmers don't have to care about this issue, it's just nailing down some spots where the safety invariants can deliberately be broken. The issue isn't actually async here, it's #[fundamental]. The holes it pokes in the orphan rule system lead to many unintentional outcomes.

BTW I think the fact that in Go, your program can change out from underneath you based on whether an array gets realloced is so much more disturbing: https://utcc.utoronto.ca/~cks/space/blog/programming/GoSlice... It is genuinely shocking to me that people just live with this. This is completely inexpressible with safe Rust, as it should be.

the way arrays work and that they can reallocate on append is clearly visible by the fact that it returns the pointer to the new array.

It is something you learn very early, because the syntax is indeed a bit peculiar, and kind of a footgun. However it implicits teaches you to not try to play with the memory backing the array (which is something go programmers are very happy not doing).

Re: Tell HN: Rust Is Complex

#43

Post by rich_sasha »

xwowsersx wrote: post #29
jasfi wrote: post #25

Nim is far less complex, but isn't as popular. The community is working quite hard to change that though.

I really like Nim. I was able to build some non-trivial things in it after just a few hours of googling and reading documentation (supplemented with a few questions on IRC). I do sometimes worry though about investing in a language that, due to its lack of popularity of "catching on", may never have the richness of tooling and packages/libraries needed to use it in the context of a larger project or larger team. But…

100% agreed, to the letter.

My recent observation is that programming languages are a bit like warfare. We are drawn to discuss syntax and features, or machine guns and fighter jets, but what seems to trump these on any practical timeframe is logistics.

When coding up a new project, I need a language which gets a lot of mileage, so the bugs are stamped out. It needs good tooling so I'm not stuck making it myself. It needs robust package support, so I can just type the project-specific code. Oh and the language can't be unworkable, and vaguely needs to fit technical spec.

It's a sad chicken-and-egg situation, but users are often not in a position to take the risk.

Re: Tell HN: Rust Is Complex

#44

Post by allisdust »

Cloudef wrote: post #39
allisdust wrote: post #38

Earlier quoted context omitted.

It's a RWLock. Not a mutex. As long as no one is writing to it, readers are not blocked.

I know, but the RWLock itself also did not work. Complaining about safety and the only solution seemed to wrap the value itself into mutex inside rwlock. If I still had to go back to this, I would just write the function in C and go from there. Rust is productive when you can work with the highest level of abstraction and when it can copy values freely. When you want to work with copy-free or shared memory, is when r…

May I suggest you take some time to understand the concurrency and memory management parts of Rust a little more to figure out where your program is falling.

I agree it's not an easy language to pickup, but the use case you mentioned is a pretty common one and there are several ways to solve it. For example, any kind of config reading from a file needs it. Similarly, connection pools for DB etc are shared this way so its not an uncommon use case in day to day usage of Rust.

Re: Tell HN: Rust Is Complex

#45

Post by sidcool »

I feel it's because it's a very new kind of programming model. But the lofty aim with which Rust started, the complexity is essential and not accidental. But no doubt it's complex.

Re: Tell HN: Rust Is Complex

#46

Post by mariusor »

throwawaymaths wrote: post #27
2fast4you wrote: post #4

Earlier quoted context omitted.

Do you have more examples? I’ll admit that Go is full of weird quirks, but nothing feels bolted on. Generics were agonized over for so long because they had to fit it within the existing language

JSON marshalling is a big one

In which way?

Re: Tell HN: Rust Is Complex

#47

Post by atoav »

I get the sentiment, but one thing that probably needs to be underlined here is that one only needs to face that complexity if you really want to, however. Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day.

Even lazy Rust code can still be incredibly performant, testable and fault tolerant. The lower level you go, the more you need to know about Rust and how what it does maps to memory, because it is a systems programming language and if you wanna write the equivalent of a kernel in it you will need all power you can get. The point here however is: you rarely really need to go that deep if you are writing whatever you'd be writing in Go.

Re: Tell HN: Rust Is Complex

#48

Post by distcs »

Matthias247 wrote: post #22

Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions…

> There's nobody forcing you to use Pin.

This kind of argument does not work in community and professional projects where you do get forced to use the features that your colleagues or predecessors have used in the codebase.

Re: Tell HN: Rust Is Complex

#49

Post by zozbot234 »

Yes, Rust has very real unsoundness issues wrt. Pin and, more generally, interactions between unsafe and safe code. It's still nowhere near as complex as C++, which is a rather popular language nonetheless. Rust also has an editions system, so any such warts can be fixed whereas C++ is totally unfixable (other than via a clean start, see Carbon and Herb Sutter's new surface syntax).

Re: Tell HN: Rust Is Complex

#50

Post by sph »

toast0 wrote: post #6
RcouF1uZ4gsC wrote: post #2

Question: How much of Rust’s type system complexity is due to async? It seems Pin is mostly related to async and the official examples for GAT are for async. Given the complexities of async and how other alternatives such a Java Loom’s virtual threads, in about 10 years I am not sure that we won’t see Rust going all in on async as a mistake.

> I am not sure that we won’t see Rust going all in on async as a mistake. I'm about a month into Rust, but Rust didn't go all in to async; it only went halfway in, which is why some functions are async and others aren't. Erlang is all in on async/green threads/tasks. From what I gather, so is Loom. There's no special way to write async code, you just write regular code and it works; for Loom you just spawn your thre…

Erlang isn't async. The actor model is great because you only have to think in single threaded mode. And with immutability being a core language feature, data races and other concurrency issues are literally impossible.
Post reply on HN