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

81–90 of 102 posts

Re: Tell HN: Rust Is Complex

#81

Post by atoav »

cyber_kinetist wrote: post #60
atoav wrote: post #47

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…

> Otherwise you can just wrap everything in Arc, Cow and similar helpers and call it a day. … which is how we got slow, bloated legacy C++ codebases today, should we make the same mistake with Rust? If you are wrapping everything in ref-counted smart pointers it might probably be better to just use a garbage-collected language like Java or C# instead…

As I said: It depends what you are writing. If you write big libraries and major codebases that are meant to represent the foundation for something big, maybe you should not follow my advice. If however you are writing a small tool where good enough is indeed good enough (and still 10 times faster than equivalent python code), who cares.

Rust can go anywhere inbetween counting every bit and byte and doing no such thing at all. My point was that counting every bit will probably be not be the way 90% of the programs will be written if they are written in Rust (mostly due to the fact that programming in such a way is both much harder and takes longer — independent of the programming language).

So if someone who does not count bits programs a software in a field where it would be paramount to do precisely that, then this is not the fault of the programming language, but the fault of that person, their organisation or whatever.

Re: Tell HN: Rust Is Complex

#82

Post by carlmr »

1letterunixname wrote: post #19
jmillikin wrote: post #8

Complexity is relative. Go is a language for high-level application development. It has a runtime, garbage collection, and a sophisticated M:N threading scheduler that are all designed to help the programmer express themselves in terms of the problem domain. It competes with Java, C#, and (in some cases) Python or Ruby. Rust is a language for low-level systems programming. It needs far more complexity than Go because…

The issue with Go is it's a "worse is better" situation: it's easy to go from 0 to a limited amount of productivity, but then it peaks because of the impractical and unreasonable design limitations due to absurd governance decisions. It's too minimal and too limited in key ways out of design purity. Rust's syntax and verbosity sometimes leaves much to be desired or the convoluted syntax and structures to get interior…

>they either don't want to understand it or can't grasp its concepts like lifetimes (liveness) or move.

I think it's funny/sad when I hear C++ programmers complain about this. If you don't understand lifetimes in Rust, you don't understand lifetimes in C++ either. Rust however will prevent you making a mistake. That makes it less complex for you. If you can't get your program to compile in Rust, you might get it to compile in C++, but you shouldn't.

Re: Tell HN: Rust Is Complex

#83

Post by olvy0 »

joaonmatos wrote: post #68
samsquire wrote: post #55

I think I need someone to explain Rust async to me. I think I understand that await causes the half of function to be rewritten into a state machine that returns immediately to caller and the promise object implements the rest of the control flow. I don't understand waiters, pollers.

Waiters and pollers are artifacts from the fact that Futures in Rust are lazily scheduled, unlike Javascript, for example, where Promises are eagerly scheduled and executed. When you don't want to block your process and program in a reactive, non-blocking way, which is what futures and promises are an implementation of, what you are actually defining is something like this: > "our process will do some synchronous wor…

That's a great explanation, thank you!

Re: Tell HN: Rust Is Complex

#84

Post by Matthias247 »

distcs wrote: post #48
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.

In that case you hopefully have colleagues that are able to help on those questions.

And if predecessors have moved on, teams should typically be empowered to make changes to the codebase which make the code understandable and maintainable for them (but sure - I am fully aware about that these changes are not easy to get prioritized in a business sense).

Re: Tell HN: Rust Is Complex

#85

Post by howinteresting »

bsaul wrote: post #42
howinteresting wrote: post #34

Earlier quoted context omitted.

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).

Personally, I would simply use a language where such footguns just don't exist.

Re: Tell HN: Rust Is Complex

#86

Post by howinteresting »

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…

Precomputing state in a global variable works great with once_cell::sync::Lazy (which, like the rest of once_cell, is on track for stabilization). I use it all the time, and I agree that the ability to do that sort of caching is important.

Re: Tell HN: Rust Is Complex

#87

Post by howinteresting »

scoutt wrote: post #59
Cloudef wrote: post #39

Earlier quoted context omitted.

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…

I feel your pain as I started to learn Rust recently (again) and found the same problem, coming from C. In my case, after fighting for literally days, the crate OnceCell did the job (kind of), but I felt awkward retorting to an external crate to deal with a simple static-global-initialize-once-never-touch-again piece of data.

Initializing global, static state isn't simple at all -- C++ is a prime example for how a bad design for static initializers can go horribly wrong.

At the very least, you need some sort of locking mechanism to deal with the potential issue where multiple threads try to initialize the variable concurrently. And you need some poisoning mechanism to prevent panics and reentrancy during initialization. Rust makes you realize "oh, yeah, I need to think about these too".

In any case, OnceCell is a very reasonable way to do this and is on track for stabilization.

Re: Tell HN: Rust Is Complex

#88

Post by howinteresting »

b20000 wrote: post #69
cyber_kinetist wrote: post #61

Earlier quoted context omitted.

Rust doesn’t handhold you for anything low-level. It’s just that Rust hides all that complexity beneath Unsafe Rust, which is an eldritch language that no one quite knows all the rules yet (including things related to undefined behavior…) I hope the MiniRust project ( https://github.com/RalfJung/minirust ) succeeds in writing a formal spec of it someday.

ok, so you just confirmed rust does some stuff behind the scenes for you. and that comes at a cost. what is more important is to understand how to architecturally build software and achieve performance and maintainability and so on. i rather spend my limited hours becoming better in a language like c or c++ which is not going away anytime soon than learning syntax, a new way of thinking and a package management syste…

The performance ceiling of C++ is substantially lower than that of Rust. For example, it is roughly impossible for humans to use `restrict` with C or C++, while it's a completely normal part of writing Rust (and LLVM optimizations have finally been turned on: https://github.com/rust-lang/rust/issues/54878)

Also see https://github.com/rust-lang/rust/pull/103070 and https://reviews.llvm.org/D136659, which start introducing further Rust-specific optimizations.

Re: Tell HN: Rust Is Complex

#89

Post by bsaul »

howinteresting wrote: post #85
bsaul wrote: post #42

Earlier quoted context omitted.

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).

Personally, I would simply use a language where such footguns just don't exist.

That was my first conclusion with that language after my first attempt. However on the second one, much later, i came to realize this language is an absolute marvel of carefully picked tradeofs, always in favor of simplicity and maintainability. Which for industry project is a must. Go footguns are pretty easy to spot and look « stupid » ( in the sense that other languages solve them elegantly). In exchange, the really hard ones (such as overly complex concurrency patterns, or codebases made of layers upon layers or crappy abstractions) are extremely rare and need constant fighting against the language.

Re: Tell HN: Rust Is Complex

#90

Post by howinteresting »

bsaul wrote: post #89
howinteresting wrote: post #85

Earlier quoted context omitted.

Personally, I would simply use a language where such footguns just don't exist.

That was my first conclusion with that language after my first attempt. However on the second one, much later, i came to realize this language is an absolute marvel of carefully picked tradeofs, always in favor of simplicity and maintainability. Which for industry project is a must. Go footguns are pretty easy to spot and look « stupid » ( in the sense that other languages solve them elegantly). In exchange, the real…

I'd say that in my professional experience, Rust is probably the best "at scale" language that exists today.
Post reply on HN