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

31–40 of 102 posts

Re: Tell HN: Rust Is Complex

#31

Post by jasfi »

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…

I've had the same concerns. I made a Nim web framework, but I don't think anyone else has written a web app with it except for myself.

My thinking now is to combine Nim with other languages and their frameworks. For example a NextJS/React front-end with some GraphQL servers in Nim. Alternatively Nim and Python mix quite well.

Re: Tell HN: Rust Is Complex

#32

Post by howinteresting »

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.

No, the selling point of Rust is that it exposes the full complexity of systems while providing safe memory management. Being able to dereference a null pointer without a clear override isn't complexity, it's just bad language design.

Re: Tell HN: Rust Is Complex

#33

Post by howinteresting »

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.

Re: Tell HN: Rust Is Complex

#34

Post by howinteresting »

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.

Re: Tell HN: Rust Is Complex

#35

Post by Cloudef »

I too program in rust, however I don't like programming in rust. It feels like C++ on steroids. I consider all the meta-programming and traits mostly read only. There's too many concepts you have to understand and wrappers on top of wrappers. And even when you know what you want to do, it's sometimes a huge fight to get rust to understand what you are doing. Even with unsafe this process can be really annoying and frustrating. Compile times are slow and binaries big.

For example, recent struggle with rust I had. Was storing something pre-computed into a global variable (in C terms think of pointer to binary data). And after it's stored this variable is never mutated anymore, just read, so it's completely safe. Unfortunately it felt almost impossible to get rust to understand this, and it always wanted to copy the damn thing, or preaching me how it's unsafe.

That said, rust is still very much good tool to have in pocket when you have to program high-performance and secure software. But I would not ever program a huge project with it, perhaps use it only in critical parts.

Re: Tell HN: Rust Is Complex

#36

Post by allisdust »

Cloudef wrote: post #35

I too program in rust, however I don't like programming in rust. It feels like C++ on steroids. I consider all the meta-programming and traits mostly read only. There's too many concepts you have to understand and wrappers on top of wrappers. And even when you know what you want to do, it's sometimes a huge fight to get rust to understand what you are doing. Even with unsafe this process can be really annoying and fr…

For your issue there are two ways to achieve it:

1) Use lazy_static crate 2) Use a arc wrapped rwlock

Re: Tell HN: Rust Is Complex

#37

Post by Cloudef »

allisdust wrote: post #36
Cloudef wrote: post #35

I too program in rust, however I don't like programming in rust. It feels like C++ on steroids. I consider all the meta-programming and traits mostly read only. There's too many concepts you have to understand and wrappers on top of wrappers. And even when you know what you want to do, it's sometimes a huge fight to get rust to understand what you are doing. Even with unsafe this process can be really annoying and fr…

For your issue there are two ways to achieve it: 1) Use lazy_static crate 2) Use a arc wrapped rwlock

Neither worked, it always complained about Copy trait, and no I don't need a mutex for this. I eventually got it to work with few bits of unsafe, but then I gave up when one of the apis I was using captures mutable self, and after that I couldn't force rust to move the damn thing. I decided to not cache anything at all in the end. But it just shows how some trivial things can be nigh impossible in rust, or less efficient. (Also I had to wrap the thing I was caching into yet another struct just to give it a dummy Send and Sync trait)

Re: Tell HN: Rust Is Complex

#38

Post by allisdust »

Cloudef wrote: post #37
allisdust wrote: post #36

Earlier quoted context omitted.

For your issue there are two ways to achieve it: 1) Use lazy_static crate 2) Use a arc wrapped rwlock

Neither worked, it always complained about Copy trait, and no I don't need a mutex for this. I eventually got it to work with few bits of unsafe, but then I gave up when one of the apis I was using captures mutable self, and after that I couldn't force rust to move the damn thing. I decided to not cache anything at all in the end. But it just shows how some trivial things can be nigh impossible in rust, or less effic…

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

Re: Tell HN: Rust Is Complex

#39

Post by Cloudef »

allisdust wrote: post #38
Cloudef wrote: post #37

Earlier quoted context omitted.

Neither worked, it always complained about Copy trait, and no I don't need a mutex for this. I eventually got it to work with few bits of unsafe, but then I gave up when one of the apis I was using captures mutable self, and after that I couldn't force rust to move the damn thing. I decided to not cache anything at all in the end. But it just shows how some trivial things can be nigh impossible in rust, or less effic…

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 rust becomes special kind of hell, and you have to dwelve deep into the depths of rust to get it to do what you want. Somehow the meta-programming is even more unreadable than C++.

I also get slight PTSD whenever I have to write `new`, not sure if the method will allocate or not behind the scenes. This is one of the things zig gets right I think:

- No hidden control flow.

- No hidden memory allocations.

Re: Tell HN: Rust Is Complex

#40

Post by macgyverismo »

allisdust wrote: post #38
Cloudef wrote: post #37

Earlier quoted context omitted.

Neither worked, it always complained about Copy trait, and no I don't need a mutex for this. I eventually got it to work with few bits of unsafe, but then I gave up when one of the apis I was using captures mutable self, and after that I couldn't force rust to move the damn thing. I decided to not cache anything at all in the end. But it just shows how some trivial things can be nigh impossible in rust, or less effic…

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

They need atomic operations which can still stall most of your massivly parallel machine.
Post reply on HN