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

The borrowchecker is what I like the least about Rust

viralinstruction.com

Post reply on HN
Print view View original

421–430 of 459 posts

Re: The borrowchecker is what I like the least about Rust

#421

Post by duped »

oneshtein wrote: post #344
duped wrote: post #183

> My examples code above may not be persuasive to experienced Rustaceans. They might argue that the snippets don't show there is any real ergonomic problem, because the solutions to make the snippets compile are completely trivial. In the last example, I could just derive Clone + Copy for Id. No, you could use destructuring. This doesn't work for all cases but it does for your examples without needing to derive copy…

What stops you from writing such data container with interior mutability, like vec_cell[0], which then enforce borrowing rules at runtime? [0]: https://github.com/alexanderved/vec_cell

If I'm writing my own data structures then why am I using Rust

Re: The borrowchecker is what I like the least about Rust

#422

Post by vips7L »

jpc0 wrote: post #374
vips7L wrote: post #335

Earlier quoted context omitted.

Here’s a great read on its quirks, and where it really isn’t “simple”: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... https://dave.cheney.net/2014/03/19/channel-axioms

> A send to a closed channel panics And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive. The read situation is literally not understanding or even looking up the interface, there is another return value that wil…

> And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing.

Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system.

> Because you don’t know how doesnt mean it’s unintuitive,

Do you know what the definition of unintuitive is? If it was intuitive you wouldn’t be able to “hold it wrong”.

Re: The borrowchecker is what I like the least about Rust

#423

Post by rstuart4133 »

forrestthewoods wrote: post #157
marcianx wrote: post #147

Earlier quoted context omitted.

To make sure I understand correctly: did you want to read a `String` and have lots of references to slices within the same string without having to deal with lifetimes? If so, would another variant of `Rc ` which supports substrings that also update the same reference count have worked for you? Looking through crates.io, I see multiple libraries that seem to offer this functionality: [1]: https://crates.io/crates/arc…

It’s deeper than that. Let’s pretend I was in C. I would allocate one big flat segment of memory. I’d read the “JSON” text file into this block. Then I’d build an AST of nodes. Each node would be appended into the arena. Object nodes would container a list of pointers to child nodes. Once I built the AST of nested nodes of varying type I would treat it as constant. I’d use it for a few purposes. And then at some poin…

I've just built a parser in Rust that seems to function in exactly the way you say. It reads the text into a single buffer, assembles the AST nodes in an arena (indexes are NonZeroU8's to save space), and all token nodes refer to the original rather duplicating the text. The things I'm parsing are smallish (much less than 64k, 256 tokens), but their is around 100M of them so was worth the effort to build it in a way that used 0 allocations (the arena is re-used).

It was a bit of effort, but it can't be that difficult given it's my first non-toy Rust program and it wasn't that hard to get going. I'd written maybe 50 training exercises in Rust before that, over the years. Yes, the same thing in C would have been faster and easier to write (I've written many 100's of thousands of lines of C over the years), but I'm not sure it would of worked the day after it compiled.

I also had to build a 2nd parser that looked at maybe 100 lines. It was clone() all the way down for that one because I could afford the cost. I think that was easier to write in Rust than C, mostly because of the very good standard library Rust comes with.

Re: The borrowchecker is what I like the least about Rust

#424

Post by oneshtein »

duped wrote: post #421
oneshtein wrote: post #344

Earlier quoted context omitted.

What stops you from writing such data container with interior mutability, like vec_cell[0], which then enforce borrowing rules at runtime? [0]: https://github.com/alexanderved/vec_cell

If I'm writing my own data structures then why am I using Rust

If you cannot write a simple data structure, you can ask/hire a senior developer to do it for you. In it current shape, Rust good for seniors, but a bit hostile against newbies, like C++, TypeScript, etc.

Re: The borrowchecker is what I like the least about Rust

#425

Post by tialaramex »

camgunz wrote: post #402
tialaramex wrote: post #397

Earlier quoted context omitted.

> TL;DR: mostly what I mean is Go is the only language from this millennium that's consistently in the top 10 most popular programming languages. So, if you don't count the lists where it isn't in the top ten, and you don't count languages like Typescript? Does that feel like an important distinction to you with the exceptions, rather than an arbitrary post doc justification ? > Isn't this exactly what we're talking…

(I've successfully resisted the urge to make my entire reply "Wait, you don't like Judge Dredd?") I feel like we both understand each other at this point so I'll ask because I'm curious, what languages are you into? I'd really like a chance to dig into Erlang, OCaml, or Racket, but I can never really justify it. Mostly I'm a boring C/Python person (believe it or not, I don't like Go all that much)

On my own time? I write only Rust for several years.

I currently get paid to write, among other things, C#, Python, PHP, Perl, and bash. Historically I have also been paid to write C, Java, and Go, among other things.

Re: The borrowchecker is what I like the least about Rust

#426

Post by jpc0 »

vips7L wrote: post #422
jpc0 wrote: post #374

Earlier quoted context omitted.

> A send to a closed channel panics And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive. The read situation is literally not understanding or even looking up the interface, there is another return value that wil…

> And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing. Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system. > Bec…

> Not having to call into ffi/c libraries to modify files is the normal use case.

A “systems” language designed by some smart people that is mostly targeted at the most deployed os in the world “cough not windows”, definitely does not need to make windows the default.

> If it was intuitive you wouldn’t be able to “hold it wrong

No unintuitive means if you understand the domain and idioms yet the interface still does not make sense. Returning multiple values when reading and passing context around (even in a wrapper) is normal intuitive golang.

So is allocating complex object instead of simply instantiating them, sure this point is slowly moving out of idiomatic golang but at the same time the history is important.

Not understanding CSP and not liking explicit return values does not mean it is unintuitive.

Re: The borrowchecker is what I like the least about Rust

#427

Post by citrin_ru »

torginus wrote: post #342
citrin_ru wrote: post #306

Earlier quoted context omitted.

But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.

Why do you need that many threads? Linux doesn't even allow you that many file handles.

> Why do you need that many threads?

In micro-service world there are many service which read request over the network (HTTP or some RPC), send multiple requests, may be read something from disk, write logs all mixed with some business logic. A significant fraction of time is spend on waiting so a single modern server can handle a large number of parallel connections to the service without saturating hardware resources.

Async allows to do the same (handle many network connections in a single thread) but: 1. It's less ergonomic (less easy to write code) IMHO 2. In pure async if you do a long CPU intensive task in between I/O all other connections in the same thread will wait, which Go solves (at least partially) by using M:N model (pure async is M:1 - connection tied to a particular thread and even if you have many threads you cannot move connections around).

I would not argue that Go concurrency model is the best we can get but it's a good fit for micro-service architecture and a good balance between performance and easy development.

> Linux doesn't even allow you that many file handles.

Not by default but it's easy to rise limits for this and if you are running a loaded server you should not rely on defaults anyway. To get to 100M descriptors you likely need to tune only ulimit (LimitNOFILE in systemd) because default value for fs.file-max is likely large (AFAIR default scaled to the RAM size).

Re: The borrowchecker is what I like the least about Rust

#428

Post by tialaramex »

camgunz wrote: post #402
tialaramex wrote: post #397

Earlier quoted context omitted.

> TL;DR: mostly what I mean is Go is the only language from this millennium that's consistently in the top 10 most popular programming languages. So, if you don't count the lists where it isn't in the top ten, and you don't count languages like Typescript? Does that feel like an important distinction to you with the exceptions, rather than an arbitrary post doc justification ? > Isn't this exactly what we're talking…

(I've successfully resisted the urge to make my entire reply "Wait, you don't like Judge Dredd?") I feel like we both understand each other at this point so I'll ask because I'm curious, what languages are you into? I'd really like a chance to dig into Erlang, OCaml, or Racket, but I can never really justify it. Mostly I'm a boring C/Python person (believe it or not, I don't like Go all that much)

Oh also, well, "Judge Dredd" was just not a very good movie. Not reprehensibly bad. Nobody involved should be sorry for making it, but not worth the price of a ticket. Swing and a miss.

In contrast "Batman & Robin" is terrible. Clooney said he didn't want friends and family to see it because he is rightfully ashamed to have done it. Sometimes an actor does good work but it's hard to see because the technicians are incompetent and the editor destroys their effort in the cut - however it's clear Clooney was not trying.

Alicia Silverstone has been in utter trash, some of which I have watched because I used to live with a guy who was obsessed with her - but it's notable that even the icky "technically this isn't pornography" stuff she did as a teenager is more competent than "Batman & Robin" for which she was presumably much better paid.

Joel Schumacher can do excellent work so why is "Batman & Robin" so awful? Did the Studio tell him nothing else matters so long as the branding is there because comic book fans will show up anyway? If so maybe it's partly their fault, but a good artist should have more pride in their own work than to do this.

I have more recently (well, this century) gone to a "live MST3K" type event where they screen the original film but talk over it. They warned us that "Batman & Robin" is too awful for this format to save it, but I didn't listen and yeah, long before the closing credits lots of people walked out because they were right and it's unsalvageable.

Re: The borrowchecker is what I like the least about Rust

#429

Post by moltonel3x »

camgunz wrote: post #391
ModernMech wrote: post #357

Earlier quoted context omitted.

The median number of users across all programming languages is zero. Millions of people around the world use Rust and Swift, so it seems like a stretch to say they're far from popular. If Rust isn't a popular language compared to Java, we might just as well say Java is not a popular language compared to Excel.

I don't think millions of people use either Rust or Swift.

According to SlashData "size of programming language communities, Q1 2025":

   28.0M JS+TS
   ...
   5.6M Swift
   5.1M Rust
   5.0M Go
They have measured Rust growing faster than Go over the years, with the overtake finally happening in Q1 this year.

There aren't a lot of reports presenting absolute numbers and not biased toward a handful of platforms or ecosystems. If you know of other good free ones, feel free to share.

https://research.slashdata.co/reports/6814fddffed4a97023eab0...

Re: The borrowchecker is what I like the least about Rust

#430

Post by [deleted] »

gdbsjjdn wrote: post #123
eigenspace wrote: post #11

I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

[deleted]
Post reply on HN