Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#651

Post by crabbygrabby » Fri, Jun 03, 2022, 6:46 PM UTC

foldr wrote: post #602

shric wrote: post #573

Earlier quoted context omitted.

Is there a simple example you can point to of rejected code that should work perfectly fine?

A doubly linked list is a classic example. To implement this in Rust you need to use unsafe code. Come to think of it, an even simpler example is a mutable iterator for a typical data structure. Such iterators usually require 'unsafe' code to implement, even though they are perfectly safe to use. https://stackoverflow.com/questions/63437935/in-rust-how-do-...

Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. So when you do get UB from using unsafe you look at those places rather then your entire code base...

A lot of people don't seem to realize how easy it is to get UB in other languages. The C spec for example claimed not having a trailing newline at the end of a file was UB...

I also don't think this was an example of code that should compile but doesn't. Rusts' ownership rules make this task hard, but there are lots of people using doubly linked lists in rust... Yes they used unsafe code to do it, and yes it does compile .

The question was show us a case where the borrow checker was wrong.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#652

Post by nerdponx » Fri, Jun 03, 2022, 6:47 PM UTC

generic-husky wrote: post #489

nerdponx wrote: post #453

Earlier quoted context omitted.

I'm a bit surprised that Rust is really the top language here. I would have expected the top ranked languages to be nowadays-relatively-unpopular languages with dedicated long-time users, like Lisp, Tcl, Perl, and APL. Is this weighted somehow by overall popularity?

Well the second one is a LISP (Clojure), which isn't really popular (relative to more mainstream languages).

There's probably an additional layer of substantial selection bias here. But maybe that explains the effect in the first place, greybeard Tcl users possibly didn't bother to take the survey while Clojure and Rust evangelists did.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#653

Post by crabbygrabby » Fri, Jun 03, 2022, 6:54 PM UTC

steveklabnik wrote: post #636

wheelerof4te wrote: post #631

Earlier quoted context omitted.

"I invite you to join the community and learn it. It's a lot of fun once you get proficient with it." I will if the Rust community agrees on a lighter, less complex language core. "Microsoft, AWS, government agencys in Europe, the Linux kernel itself (the only other language allowed there is C - think about it)." Again, they are using only a subset of the language. Linus allowed it in the kernel once devs agreed only…

You’re confusing standard library naming. Rust has a layered standard library, “core” and then “std” on top of it. They’re using the core library, because that’s what you do in an OS context. But as far as I know they don’t restrict any language features. They also didn’t have to write a new allocator; they did extend the interface of the “alloc” library (which sits between core and std) which was then also accepted…

Thank you Steve. There is so much misinformation surrounding rust it's unreal...

It's also kind of normal to you know tweak a language so it integrates with an OS better... Even if they did change their allocator, who cares?

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#654

Post by crabbygrabby » Fri, Jun 03, 2022, 6:56 PM UTC

WuxiFingerHold wrote: post #615

rowanG077 wrote: post #466

Earlier quoted context omitted.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."

Or use a GC language with a great typesystem and have both safety and fast efficient development cycles.

That is an option, or if you don't want to deal with a GC because it's eating 70% of your clock cycles under load you can use rust get performance gains and still be writing safe code...

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#655

Post by ngrilly » Fri, Jun 03, 2022, 6:59 PM UTC

dgunay wrote: post #373

adastra22 wrote: post #241

Earlier quoted context omitted.

If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

3 issues you listed with Go are actually about the same thing (the lack of sum types):

- Go has nil where Rust has Option.

- Go has weird not-quite-tuple returns & if err != nil where Rust has Result.

- Go has no real enum concept, where rust has its powerful enums and matching constructs.

And the point on generics coming late is unfair. All programming languages got major features introduced late (for example async/await in Rust).

But I admit I'd love sum types, a less verbose error handling (but to be honest I'm not sure exactly how), and that I missed generics.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#656

Post by 0des » Fri, Jun 03, 2022, 7:00 PM UTC

justinsaccount wrote: post #640

dgunay wrote: post #373

Earlier quoted context omitted.

It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…

As someone that writes a bunch of go but has never really gotten off the ground with rust: * Option? I don't mind if err != nil, but sure, it would simplify some things. * Result and real tuples? awesome. * real enums? sign me up. If that was all added to go I wouldn't mind at all. But what does any of that have to do with impl Execute for Dispatcher where H: Fn(&'a Update) -> Fut + Send + Sync + 'a, Fut: Future + Se…

Shit like this makes my brain hurt

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#657

Post by nemothekid » Fri, Jun 03, 2022, 7:01 PM UTC

yencabulator wrote: post #577

nemothekid wrote: post #72

I've been doing async Rust since the tokio 0.x combinator days, and I remember being like OP. For some reason `Arc` did not exist in my mind and it was a struggle appeasing the borrow checker. The Go version is similar to the final Rust version; except the Go version is forcing you to use Arc everyone[1]. Seriously, just use Arc (or Arc >), in 70% of cases you are wrestling with the borrow checker trying to do someth…

> except the Go version is forcing you to use Arc everyone The overhead of atomic reference counts everywhere is higher than the overhead of a good garbage collector. This thinking is biased against Go for no reason.

>[1] I know that this is a simplification.

I don't think it's biased against Go. The an `Arc` (or garbage collector) is the correct way to model lifetimes for complex programs whose lifetimes are managed at runtime rather than compile time. In the context of both languages, rarely is overhead of an atomic add or GC going to be the limiting factor of your programs, just like Java programs are efficient. While static memory management is nice, it's not the sole reason I continue to use Rust. I've been using Go since 1.0, and there are two times where I have ever thought "My program is slow because of GC", and in one of those times, it was solved by simply upgrading Go.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#658

Post by 0des » Fri, Jun 03, 2022, 7:03 PM UTC

c-cube wrote: post #191

0des wrote: post #23

Earlier quoted context omitted.

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

Hare is not rust adjacent, sorry. It can't even represent the (small) stdlib of rust since it lacks generics, RAII... Not to mention the memory safety. It belongs in a different class of languages.

You are not correct but I'll accept your opinion as your understanding of it.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#659

Post by crabbygrabby » Fri, Jun 03, 2022, 7:05 PM UTC

eternalban wrote: post #520

crabbygrabby wrote: post #497

Earlier quoted context omitted.

Its so hard for me to think someone actually thinks this. Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. The rust community is the least toxic programming community I've ever seen. Leaps and bounds away from go lang, python, and light years away from c, etc. Like use your head, is vba therefore the language whi…

> Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. Were you around when Scala was the end all be all of programming shiny things? "Early on, Scala rode a wave of hype that frankly surprised even me: hype around pushing syntactic boundaries, hype around reactive architectures, hype around functional programming, h…

I appreciate your view on scala and rust. I was around when scala became popular and wrote it in industry for a while. It wasn't a great time.

I think rust differs from scala in what it is trying to do. I also think rusts' complexity is backed by functionality that defines it's paradigm. Scala on the other hand has a few too many 'i think this would be nice to support' features in it that make it messy to deal with.

Rust imo isn't messy in that regard. Does scala still have it's place, sure. Does rust have it's place, yes.

Also if you read the posts on here, there's a lot less hype going for rust than the other way around. It's success isn't really due to it's hype, it's because people like what it does for them. Lots of people hate on it, usually baselessly.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#660

Post by foldr » Fri, Jun 03, 2022, 7:16 PM UTC

crabbygrabby wrote: post #651

foldr wrote: post #602

Earlier quoted context omitted.

A doubly linked list is a classic example. To implement this in Rust you need to use unsafe code. Come to think of it, an even simpler example is a mutable iterator for a typical data structure. Such iterators usually require 'unsafe' code to implement, even though they are perfectly safe to use. https://stackoverflow.com/questions/63437935/in-rust-how-do-...

Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. So when you do get UB from using unsafe you look at those places rather then your entire code base... A lot of people don't seem to realize how easy it is to get UB in other languages. The C spec for example claimed n…

>Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk.

I'm fully aware of this. That's why I put 'unsafe' in quotes.

However, it's surely fair to point out that you can't implement doubly linked lists or mutable iterators in Rust without giving up Rust's usual guarantee of memory safety. If this guarantee is not actually that big of a deal, as you appear to be suggesting, then why all the hype about it from Rust advocates?

>The question was show us a case where the borrow checker was wrong.

No, that was not the question. OP just asked for 'rejected code that should work perfectly fine'. There are of course loads of examples of such code. Perhaps the simplest is the case of mutable iterators that I mentioned. A correctly implemented mutable iterator is perfectly safe, but rejected by Rust's borrow checker unless certain parts of the implementation are marked unsafe.