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

451–459 of 459 posts

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

#451

Post by loeg »

nullc wrote: post #432
conradludgate wrote: post #258

Earlier quoted context omitted.

The obvious upside is that it's so much easier to debug when there's no UB. Debugging UB is never enjoyable.

not sure I agree. UB has the benefit that there are a lot of tools like valgrind, memcheck, and various compiler features to detect it both statically and at runtime. And when you hit UB it is certainly an error. Non-UB errors have no such powerful tools, only what application specific tests or assertions you create. I've seen plenty of cases where people went and turned signed types into unsigned because signed over…

Also like, it's not universally true that UB bugs (broad class of problems) are all harder to debug than non-UB bugs (another broad class of problems). Null pointer dereferences are UB, and among the easiest class of problem to debug.

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

#452

Post by burntsushi »

estebank wrote: post #384
burntsushi wrote: post #334

Earlier quoted context omitted.

You're engaging in a motte-and-bailey fallacy. Your motte is your much more narrow claim about Rust's advantages in a context where you claim not to care about undefined behavior as a class of bugs more severe than logic errors. And you specifically make this claim in an additional context where a GC language is appropriate. That's an overall pretty easy position to defend, and if that were clearly the extent of it,…

> I don't think it's possible to write a tool like ripgrep with its performance profile in a GC language. I think it is possible to make a language that has both a GC and a borrow checker, treating the GC types as a third level next to the stack and the heap, where complex referencial cycles can bé promoted to the GC, but the defaults push you towards fast execution patterns. Don't know if such a language would be su…

My standard of evidence here is existence. There are many greps written in a "GC language," and none of them have a broad performance profile in the same category as ripgrep (or other greps written in C and C++).

> This is no different in concept than Python libraries implemented in native languages.

If that's true, then why isn't there a fast grep written in Python? IMO, it's for the same reason that tools like csvkit are slow. Once you get to the boundary between GC and non-GC, some kind of cost gets paid. Now maybe Python is paying higher costs here than your hypothetical language, but who knows. Without actual existence, I find this sort of hypothetical to be very uncompelling. It's too broad of a stroke.

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

#453

Post by camgunz »

moltonel3x wrote: post #429
camgunz wrote: post #391

Earlier quoted context omitted.

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://…

This is pretty intriguing but it wants me to make an account? Can I view it w/o doing that?

EDIT: also I gotta say these numbers seem kinda high. It's hard for me to imagine there's ~28m JS programmers worldwide; that's 1/286 people in the entire world, and the ratio gets less believable as you shrink down the number of people who might have any access at all to a computer/internet/etc. Unless this definition is super broad, I'm quite skeptical.

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

#454

Post by Thiez »

School-Cotton wrote: post #6

IMO, it is reasonable that in the example given: struct Point { x: f64, y: f64, } impl Point { fn x_mut(&mut self) -> &mut f64 { &mut self.x } fn y_mut(&mut self) -> &mut f64 { &mut self.y } } the returned references are, for the purposes of aliasing rules, references to the entire struct rather than to pieces of it. `x` and `y` are implementation details of the struct and not part of its public API. Yes, this is occ…

You can also do something like:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let &mut Point { ref mut x, ref mut y } = self;
        (x,y)
    }
The fact of the matter is that doing mutable getters in Rust is a bit inconvenient at times. There are various workarounds.

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

#455

Post by whytevuhuni »

Thiez wrote: post #454
School-Cotton wrote: post #6

IMO, it is reasonable that in the example given: struct Point { x: f64, y: f64, } impl Point { fn x_mut(&mut self) -> &mut f64 { &mut self.x } fn y_mut(&mut self) -> &mut f64 { &mut self.y } } the returned references are, for the purposes of aliasing rules, references to the entire struct rather than to pieces of it. `x` and `y` are implementation details of the struct and not part of its public API. Yes, this is occ…

You can also do something like: fn xy_mut(&mut self) -> (&mut f64, &mut f64) { let &mut Point { ref mut x, ref mut y } = self; (x,y) } The fact of the matter is that doing mutable getters in Rust is a bit inconvenient at times. There are various workarounds.

You can do that with less syntax, this works just fine:

    fn xy_mut(&mut self) -> (&mut f64, &mut f64) {
        let Point { x, y } = self;
        (x, y)
    }
Also, I assume this is just a super trivial example, because in this case I'd just make x and y public. After all, you're giving public access via these methods, and the caller can do anything it wants with them, so there's no real difference.

And if the fields are public, it's much easier to take mutable access of multiple fields separately.

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

#456

Post by littlestymaar »

dismalaf wrote: post #417
littlestymaar wrote: post #379

Earlier quoted context omitted.

There's no irony, bash and VB6, no matter what you think about the quality of the said languages, are also scripting language and neither are in the “hobby language” category as their use is (or was) very broadly distributed. OCaml's use is comparatively very, very narrow. And, in case you are wondering, I have absolutely nothing again OCaml. In fact, my first ever programming language was, as a significant fraction…

Dassault Systèmes makes defense software, among other things... https://www.3ds.com/industries/aerospace-defense Dassault Aviation makes the planes themselves. All Dassault companies are under one umbrella anyway. The OCaml website lists a bunch of other users. In my opinion, none of that really matters, any single one of those uses proves it's utility... Facebook Messenger alone is probably used by more people than…

There's a funny small list of true claims in your message above…

First, Dassault Systèmes doesn't fall "under one umbrella" with Dassault aviation, it is an independent public company (with the Dassault group having minority shares in the company). And just because a software company has defense related products doesn't make it a “defense company”, nobody would ever call either IBM or Microsoft “Defense Companies”.

Then Facebook doesn't seem to be using Ocaml in Facebook Messenger, and instead uses its standard tech stack for that (the Hack PHP derivative).

The fact that Facebook has a developer-facing team building internal development tools with OCaml doesn't suffice to change the status of a language: since there are barely any Ocaml developers at Facebook, an Ocaml enthusiast would have to be very, very lucky to land an Ocaml job there…

And that's the whole point of the “hobby language” status: can you land a job using it or not, and Ocaml simply isn't that kind of language. And again, France has been teaching Ocaml to at least a hundred thousands of students over the years.

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

#457

Post by arresin »

AquilaFasciata wrote: post #434
arresin wrote: post #364

Earlier quoted context omitted.

A weekend?

Yes. I learned Rust in a weekend. Basic Rust isn't that complicated, especially when you listen to the compiler's error messages (which are 42x as helpful compared with C++ compiler errors).

Damn. You are a smart person. It’s taken me months and I’m still not confident. But I was coming from interpreted languages (+ small experience with c).

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

#458

Post by notjoemama »

duped wrote: post #166
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…

About 20 years ago your choice of language basically boiled down to what you were going to pick for your web server. Your choices were - Java (popular among people who went to college and learned all about OOP or places that had a lot of "enterprise" software development) - Ruby on Rails (which was the hot new thing) - Python or Perl to be the P in your LAMP stack - C++ for "performance" All of these were kitchen sin…

Wow. By your other comments I know you "know things". But this...this you do not know.

Rails was "hot" 20 years ago? lol, and you have completely missed IIS, .Net, and (dun dun duuuuuuuuunnnnn!!!!!) PHP. I bet you don't even know what ASP was.

Also...wth with C++ or python on a web server...20 years ago? Ok maybe this is entertaining now. Since you know so much, tell me about the framework libs needed for C++ web apps 20 years ago. eats popcorn Are you an LLM bot or real person?

You're not just kind of wrong here; you're not just a little wrong; you're "having a bad day" level of wrong.

Take the afternoon off, and drink a Jamba Juice. Maybe call some family and tell them you love them.

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

#459

Post by JambalayaJimbo »

ActorNightly wrote: post #394
JambalayaJimbo wrote: post #245

Earlier quoted context omitted.

Your example is of a greenfield project rather than living code that is constantly updated, in some cases by many people simultaneously. The compiler being a gate for correctness is far superior in the latter case.

If you enforce very strict interfaces through language, no matter how many people work on them, the tradeoff still applies. For example, you can have multiple people working on a code base for the second case, and some sub team has a new requirement for added functionality. Now they have to go refactor a whole bunch of the codebase to make all the types coherent. And consequently, shortcuts happen here, which leads t…

Lazy developers are going to choose the path of least resistance. A well designed type system will be intuitive, communicate well the original developer's wishes, and add lots of friction for doing stupid things. A lazy developer will not want to refactor the whole codebase!
Post reply on HN