Hacker News Reader

Comment by LAC-Tech | Hacker News Reader

For me the biggest features of rust are:

- great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev

- unit tests built into the lang

- tooling is great

- docs are top notch

The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which simplifies a lot of stuff and lets you make cyclical data structures without a lot of hoop jumping.

View on HN

Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe.

However, I appreciate that Rust tries to achieve safety through improving program correctness, not merely crashing sooner.

Of course Rust has run-time panics (hasn't solved the halting problem yet), but it also has many patterns catching problems at compile-time. For example, a hardened allocator can detect use-after-free bugs when they happen, but borrow checking can prevent them from existing in the code in the first place.

> Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe.

That was my concern that I had when I started learning the language. I think it is true, but I was surprised how quickly I managed to get used to the Rust way.

It's also worth noting that the "Rust way" often ends up being clearer and better structured, in hindsight. Rust forces you to think through questions of ownership and identity more than most languages, and a lot of "structuring programs the Rust way" is just expressing these things.

Of course, that's just "often," not nearly "always." There are many valid programs that the borrow checker struggles with, and in those cases, the "Rust way" is just needlessly convoluted. There are many problems for which the most common answer is "just store all this data in a list and use list indices like pointers." (Thankfully there has been a lot of progress on a new borrow checker that's less easily startled.)

The "Rust way" is very close to the safe variety of the "experienced C++ way", so many people adapt promptly.

I'm surprised at how slowly I'm getting used to it!

I mean I've improved but I still have a lot of "wtf" moments. End up doing a lot of deep copying and heap allocations just to shut the compiler up, which makes me question just how "zero cost" the safety is.

Are you able to store that data in reference-counted RC/ARC types? Those can help you avoid dealing with lifetime issues, though you'll still have to think about mutability and concurrency.

What I like about this language is the crazy amount of creative and insightful discussions about language features and stabilization.

It's because Rust hits the spot for MANY different domains and people. System programmers, functional programmers, backend, db engineers, GUI, devs from the formal verification/mission critical camp, OS devs, graphics and even frontend with WASM.

For me personally, the thing I miss in Rust is better const fn/comptime/metaprogramming (like in C++). Without them, I find writing generic high-perf data structures quite tedious (and proc macros just aren't a suitable replacement for generics)

I love Rust, but I kind of believe in the conspiracy that comptime code features are less loved by the Rust language maintainers because they increase compile time even more.

This isn't the case, it's just that the approach to bring comp time evaluation to Rust is difficult because we're trying to side step potential back compat or ambiguous restrictions that we otherwise would have. Rust follows the "when it's ready" delivery approach wich means that some eagerly awaited features take much longer than us, as users, would want.

Which I appreciate. I don't want Rust turning into another C++ in 20 years.

That directly contradicts in-progress efforts to make `const` better. Things like `const trait`, `const Allocators`, etc are all in progress.

Some const features seem like big anti-patterns though. One example is the unstable feature `generic_const_exprs` which I think is a bit short-sighted.

What seems short-sighted about that to you? I'm not super familiar, but it seems like something you'd want if you're using const generics.

"In progress" does not (by itself anyway) contradict "less-loved". Something can be in progress but making slower progress than it would if people were really excited about it.

I write a lot of Rust these days and unfortunately really great FP stuff is pretty damn cumbersome to write.

I found this viewpoint about FP in Rust pretty interesting. Can you elaborate?

One, the lack of support for HKT isn’t great. There are some work arounds, but they aren’t particularly safe and end up being pretty cumbersome to implement.

Another big one is while the language supports lambdas and closures, it’s highly recommended to not perform any currying.

Honestly, my favorite parts about rust are:

- It has the best parts of C (code generation is predictable, no mandatory extra thread for GC or similar, interoperates very well with C code)

- It also has some of the niceties that were popularized after C (type inference, an equivalent of unions that isn't terrible, macros that are not terrible, functional features)

- The thread safety stuff. Async has issues, but the core thread safety constructs (send, sync, mutex vs atomic, etc) are just so well designed that rust is by far my favorite language for writing synchronous, shared-memory threaded code. It's quite possible to mess it up, but it's far easier to keep that system in my head than any comparable one that I've used. Of course shared-nothing is even easier, and rust lets you do that too!

I don't use it for everything, but when I do encounter a thing rust is good at, it's just a treat.

Rust has some amazing libraries, too. I recently found out about `rayon`, and I applied it to a compute-heavy program I was writing. It was literally a one-line change (as promised!) to go from sequential to parallel, and I didn't need to worry at all that there might be some data race somewhere (unlike, say, #pragma omp parallel).

Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try:

    traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO ()

Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see http://smallcultfollowing.com/babysteps/blog/2016/11/09/asso...) but it really caught my eye that you called `try_for_each` obscure; it could have been an everyday function if it had a bit more expressiveness.

In my opinion a very good point about Rust is that it is built by people who know these functional programming concepts and why they are yseful, but are pragmatic enough to give them names that are easier to grasp for folks who don't know these concepts.

And it's possible the lack of higher kinded types, forcing reimplementation, actually gave the opportunity to look for frindlier names.

The lack of HKT is the only disappointing thing about the lang for me.

There are some ways to get around it, by simulation and using ‘as’ but it isn’t particularly safe.

I guess what I really meant was - they've captured a lot of common patterns in the iterator library so I don't have to write them myself.

No experience with haskell - sometimes I try and learn it and give up when stack complains about version conflicts - but regardless I try not to get too many hangups about functions not being super generic, just that they are there when I need them.

Reply on news.ycombinator.com