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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

191–200 of 319 posts

Re: A Rust shaped hole

#191

Post by Expurple »

blub wrote: post #178
tialaramex wrote: post #46

Earlier quoted context omitted.

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

Because they’re both complicated languages, but for different reasons. Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. Furthermore some programmers really like complicated languages like Rust, Haskell, etc others like straightforward languages like Go, Python, etc.

Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere.

Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas.

Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear working at first. They are good for learning programming, but terrible for production.

> Rust didn’t really solve memory safety, it just pushed all the complexity into the type system.

Yes, that's what it did, and that's the right tradeoff in most cases. Where the compiler can't make a reasonable default choice, it should force the programmer to make a choice, and then sanity-check it.

> If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks.

It's nice for those struggling with uncaught exceptions, null pointer bugs, mutithreading bugs, and confusing stateful object graphs in Java.

Re: A Rust shaped hole

#192

Post by blub »

tialaramex wrote: post #163
jcranmer wrote: post #118

Earlier quoted context omitted.

Having developed a fair amount of expertise with both C++ and Rust, C++ is on a completely different level of complexity from Rust. In Rust, for most users, the main source of complexity is struggling with the borrow checker, especially because you're likely to go through a phase where you're yelling at the borrow checker for complaining that your code violates lifetime rules when it clearly doesn't (only to work it…

The C++ 11 move semantic is definitely an example of C++ programmers being sold a "pig in a poke"† The claim in the proposal document was that although this isn't the "destructive move" which programmers wanted (and which Rust had by 2015), the C++ 11 move feature can be realised with less disruption and is just as good. In reality it left significant performance on the table and you can't get it back without signifi…

Copy by default is the right way to go. Even if less performant, it’s safe and super-easy to understand. Let the people that want to squeeze the last drop of performance worry about moves…

Move by default is the thing which complicates Rust so much.

Re: A Rust shaped hole

#193

Post by lblume »

jplusequalt wrote: post #23

>There is an apocryphal story about Euler in elementary school solving all the math problems that the teacher gave to the class in a jiffy, so the teacher tells him to sum up the numbers to a thousand to get him to stop pestering for more. The expectation was that Euler would go through the numbers "imperatively", like C, summing them up. Instead, what Euler did was discover the summation formula and solved it "decla…

Yes. In Germany the formula n(n+1)/2 is actually called the Gaussian sum formula, or even the "small Gauss". [0]

[0] https://de.wikipedia.org/wiki/Gaußsche_Summenformel

Re: A Rust shaped hole

#194

Post by Ygg2 »

pjmlp wrote: post #181
tialaramex wrote: post #46

Earlier quoted context omitted.

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

Because of the type system, with its ML influence, two macro systems, the stuff on nightly that many folks enjoy using, having to rely on external crates for proper error handling and async/await features. Additionally, given its ML influence, too many people enjoy doing Haskell level FP programming in Rust, which puts off those not yet skilled in the FP arts. Also the borrow checker is the Rust version of Haskell bu…

> Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind,

Eh. Haskell monads are a math-centric way of performing operations on wrapped types (stuff inside a monad). Rust borrow checker is way more pragmatic-centric, i.e. how can we prevent certain behaviors.

The difference being you don't see Monads being replaced by Tree-Monads, without impacting the code.

> and when one gets it, it isn't that easy to explain to others still trying to figure it out.

So is going from 0-based to X-based arrays (where X is an integer); Or learning a new keyboard layout. Just because it's hard (unfamiliar) doesn't mean it's impossible.

Re: A Rust shaped hole

#195

Post by junon »

> Rust, from what I've heard, has a similar abstraction level as TypeScript, perhaps even closer to Haskell but that's good, I could do with a bit more help from the compiler. But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me.

Eh.... yeah? I suppose technically? But not _really_. Rust gives you the option to do that. But most programs outside of "I'm building an operating system" don't really require thinking too hard about it.

It's not like C where you're feeding memory manually, or like C++ where you have to think about RAII just right.

Re: A Rust shaped hole

#196

Post by pjmlp »

Ygg2 wrote: post #194
pjmlp wrote: post #181

Earlier quoted context omitted.

Because of the type system, with its ML influence, two macro systems, the stuff on nightly that many folks enjoy using, having to rely on external crates for proper error handling and async/await features. Additionally, given its ML influence, too many people enjoy doing Haskell level FP programming in Rust, which puts off those not yet skilled in the FP arts. Also the borrow checker is the Rust version of Haskell bu…

> Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, Eh. Haskell monads are a math-centric way of performing operations on wrapped types (stuff inside a monad). Rust borrow checker is way more pragmatic-centric, i.e. how can we prevent certain behaviors. The difference being you don't see Monads being replaced by Tree-Monads, without impa…

In a way you're right, hence my last sentence.

Re: A Rust shaped hole

#197

Post by myaccountonhn »

tayo42 wrote: post #150
lmm wrote: post #94

If they're serious about their criteria they should go with OCaml (or maybe, like, Swift, or any of dozens of languages in that space). (Of course they actually do want Haskell but they probably need to get there gradually)

Does ocaml have a mature ecosystem of libraries and dependencies? And easy way to manage them? Even rust with all its hype lacks in this area imo.

Depends on what you're doing and how you structure your program. It certainly does not match the ecosystem of Go, Rust or C++

Re: A Rust shaped hole

#198

Post by lblume »

sgt wrote: post #165
Expurple wrote: post #152

Earlier quoted context omitted.

Fair enough. That's what they seem to be saying. But then I want to chime in and argue that the repetitive syntax isn't even close to being the main problem with Go: https://home.expurple.me/posts/go-did-not-get-error-handling...

So, while on that subject; does Zig get error handling right?

It does seem to: https://pedropark99.github.io/zig-book/Chapters/09-error-han...

However errors do not seem to commonly wrapped, tagged or contextualized as is the case in Rust. This might weight lower verbosity as more important than extremely structured error handling which definitely constitutes an interesting approach.

Re: A Rust shaped hole

#199

Post by shim__ »

_mlbt wrote: post #35
uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

Swift is a great C++ and Rust alternative that doesn’t get enough attention outside of Apple platforms. It’s a performant, statically typed, compiled language that feels almost like a scripting language to write code in. It’s memory safe, cross platform, has a fantastic standard library, and has excellent concurrency capabilities. Even the non-Xcode tooling is maturing rapidly. The big weak spot really is lack of com…

Swift seems more like an Go or Python alternative

Re: A Rust shaped hole

#200

Post by pavlov »

> “Rust, from what I've heard, has a similar abstraction level as TypeScript, perhaps even closer to Haskell but that's good, I could do with a bit more help from the compiler. But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me.”

The Rust compiler does manage memory and lifetimes. It just manages them statically at compile-time. If your code can’t be guaranteed to be memory-safe under Rust’s rules, it won’t compile and you need to change it.

Post reply on HN