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

321–330 of 459 posts

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

#321

Post by binary132 »

zozbot234 wrote: post #255
mcdoogal wrote: post #205

Earlier quoted context omitted.

Yikes, language flamebait in 2025?

Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design: "The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant lang…

The more time you spend in software engineering the more you realize that this is actually brilliant and helpful, not bad. And IME, the more expressivity I have fluently at my disposal, the more complexity I tend to create. I’m not saying I don’t enjoy more complex languages, but reducing cognitive load and easing collaboration with more junior engineers are easily the best features of Go, hands down (although I can’t say the new generics necessarily always help with that).

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

#322

Post by binary132 »

jeeyoungk wrote: post #261
rastignack wrote: post #244

Earlier quoted context omitted.

I don’t think channels and goroutines suck. For example their usage in golang’s ssh server implementation is eminently readable. And performant enough. Engineers ship with them, and do not care if there’s a purer system elsewhere.

Definitely agree that goroutines don't suck; it makes go into one of the only languages without "function coloring" problem; True N:M multithreading without a separate sync and async versions of the IO libraries (thus everything else). I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the f…

The answer to your question is zero, unless there is a compelling reason for it to buffer, and if there is you’ll know it.

Non-buffering channels are much simpler to reason about and have very useful semantics in pipelines.

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

#323

Post by binary132 »

dgfitz wrote: post #181
creata wrote: post #57

Earlier quoted context omitted.

I think there are two other big differences that also helped Rust become popular: * Rust has a C++-flavored syntax, but OCaml has a relatively alien ML-flavored syntax. * Rust has the backing of Mozilla, but I don't think OCaml had comparable industry backing. (Jane Street, maybe?)

> rust has a C++-flavored syntax I do not at all agree with this. Rust is by far the most complex language in terms of syntax that has ever become popular enough to compare it to anything.

I think some of that is just that C++ doesn’t explicitly express its semantic complexity in its syntax, while Rust does. In some ways this is an advantage for Rust, although yeah I agree it makes Rust really hard to use, and I kinda hate its syntax.

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

#324

Post by jiggawatts »

zozbot234 wrote: post #315
jiggawatts wrote: post #305

Earlier quoted context omitted.

> When you move it, it's gone at the old name . (Emphasis mine.) I just had a thought! It might make languages like Rust more ergonomic if movement could also update the reference to the new location so that moving a local variable into a container could also update the variable to reference the target also. The "broken" example can be trivially fixed: fn main() { let id = Id(5); let mut v = vec![id]; let id = v[0].0…

But why add a language feature (and a new symbol, even!) when by definition you can always fix the issue by shadowing the original variable and pointing it at the new location? At most, this calls for a change in compiler diagnostics to add a hint in cases that are trivially fixable.

There are scenarios where retrieving the just-inserted value without first cloning it isn't possible. E.g.: when inserting a value into a non-empty hashset and then needing it again immediately.

But yeah... that's a bit of a contrived example and can be solved by a simple change to the insert function without specialised support from the language.

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

#325

Post by camgunz »

tialaramex wrote: post #294
camgunz wrote: post #291

Earlier quoted context omitted.

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…

> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.

Just searching for "programming language popularity":

- TIOBE [0]: Go 7 :: Rust n/a (> 10)

- IEEE Spectrum [1]: Go 8 :: Rust 11

- Stack Overflow [2]: Go 13 :: Rust 14 (they're pretty close here)

- GitHub [3]: Go 10 :: Rust n/a (> 10)

- PYPL [4]: Go 12 :: Rust 10

- HackerRank [5]: Go 8 :: Rust n/a (> 13)

- Pluralsight [6]: Go 9 :: Rust n/a (> 10)

- Redmonk [7]: Go 12 :: Rust 19

Although I admit we probably don't have great measures of this, there's clearly a sizable gap here.

Maybe you'd want to argue about TypeScript, Swift or Kotlin? I consider TypeScript JavaScript (because TypeScript wouldn't be popular unless all JavaScript programs were TypeScript programs), and I think Swift and Kotlin only survive because of their mobile platforms (they're also all below Go in these lists, on average).

[0]: https://www.tiobe.com/tiobe-index/

[1]: https://spectrum.ieee.org/top-programming-languages-2024

[2]: https://survey.stackoverflow.co/2024/technology

[3]: https://github.blog/news-insights/octoverse/octoverse-2024/#...

[4]: https://pypl.github.io/PYPL.html

[5]: https://www.hackerrank.com/blog/most-popular-languages-2024/

[6]: https://www.pluralsight.com/resources/blog/upskilling/top-pr...

[7]: https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...

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

#326

Post by jakobnissen »

burntsushi wrote: post #317
loeg wrote: post #241

Earlier quoted context omitted.

Non-UB data structure corruption and other incorrect behavior isn't like, super obviously better than UB corruption and other incorrect behavior.

Ummm. Yeah it is. I'm sure you can come up with some cases where the impact of the bugs is roughly equivalent, but generally speaking, UB is a terrible class of bug. For example, if the aho-corasick crate accidentally tries to look up a dangling state node, you'll get a panic. But if this were UB instead, that could easily lead to a security problem or just pretty much anything... because behavior is undefined . So g…

Author here. In scientific computing, there isn't much of a security implication of UB, and the most dangerous kind of error are when your program silently computes the wrong thing. And that is especially likely when you use indices manually.

You could say that UB enables all behaviour, including silently wrong answers, and you'd be right. But it's more likely to crash your program and therefore be caught.

Most importantly, the comparison to a raw pointer is not relevant. My blog post states that integers come with zero safety (as in: preventing bugs, not risk of UB) and zero language support and that is true. My blog post compares Rust with GC languages, not with raw pointer arithmetic. And it's clear that, when you compare to using GC references, manual indices are horribly unsafe.

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

#327

Post by camgunz »

Sesse__ wrote: post #296
camgunz wrote: post #291

Earlier quoted context omitted.

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…

> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Rust. TypeScript. Swift.

I wrote a reply to a sibling comment here [0], but wanted to reemphasize that Rust and Swift are far from popular. I think it bears repeating because the gap between a Rust/Swift and Go is notable, but the gap between a Rust/Swift and Java is a chasm. I would guess this isn't the intuition of an HNer (it wasn't mine until I dug in for this discussion haha)

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

#328

Post by cheshire_cat »

Sesse__ wrote: post #296
camgunz wrote: post #291

Earlier quoted context omitted.

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…

> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Rust. TypeScript. Swift.

Kotlin as well, although I think this is mostly because of Android?

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

#329

Post by testrun »

pwdisswordfishz wrote: post #283
fmbb wrote: post #164

Earlier quoted context omitted.

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.

> nicer simpler Java Ironically, Java was sold as a "nicer simpler C++".

Both can be true at the same time.

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

#330

Post by jltsiren »

nine_k wrote: post #79
eigenspace wrote: post #67

Earlier quoted context omitted.

The author is a bioinformatician writing scientific software, and often switching back and forth between Rust, Julia, and Python. His concerns and priorities are not the same as people doing systems-level programming.

Maybe Rust, a systems language, is just a wrong tool for bioinformatic tasks. Go, Java, Typescript, Ocaml, Scala, Haskell easily offer a spectrum from extreme simplicity to extreme expressiveness, with good performance and library support, but without needing to care about memory allocation and deallocation. (Python, if you use it as the frontend to pandas / polars, also counts.)

Rust is widely used in bioinformatics, as is C++. Largely because people developing new tools often have to write their own low-level algorithms and data structures.

Many tools deal with sequencing data, which means collections of strings that cannot be parsed or tokenized in any meaningful way. The collections are often very large, and the strings can also be very long. The standard algorithmic toolkit you learn when doing a CS degree (or a PhD in algorithms) is inadequate with such data. Hence, if you go to a CS conference focused on combinatorial algorithms and data structures, the presented work is often motivated by applications in bioinformatics.

Post reply on HN