Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

241–250 of 459 posts

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

#241
post #212

Earlier quoted context omitted.

Indices can be dangling in almost exactly the same way as pointers. Worse, it's easier to accidentally use-after-free clobber some other item in the same structure, because allocations are "dense." (Pointer designs on systems where malloc/free is ~LIFO experience similar problems.)

Except for the fact that one leads to undefined behavior and the other doesn't. This is a massive difference.

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

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

#242

Earlier quoted context omitted.

Except for the fact that one leads to undefined behavior and the other doesn't. This is a massive difference.

This might not seem obvious. So allow me an attempt at expanding a bit. The difference is that a dangling raw pointer to the heap will point to anything that can be modified at any time. But indexing a dynamic array guarantees that every elements is always well formed and safe to use.

It's true that the array approach cannot suffer from type confusion.

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

#243
post #155

Earlier quoted context omitted.

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…

[flagged]

I don’t like writing golang, but I sure like reading it. It’s nearly impossible not to understand.

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

#244

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…

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.

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

#245
post #8

This post pretty much completely ignores the advantages of the borrow checker. I'm not talking about memory safety, which is it's original purpose. I'm talking about the fact that code that follows Rust's tree-style ownership pattern and doesn't excessively circumvent the borrow checker is more likely to be correct . I don't think that was ever the intent behind the borrow checker but it is definitely an outcome. So…

> is more likely to be correct. This is a moot statement. Here is a thought experiment that demonstrates the pointlessness of languages like Rust in terms of correctness. Lets say your goal is ultimate correctness - i.e for any possible input/inital state, the program produces a known and deterministic output. You can chose 1 of 2 languages to write your program in: First is standard C Second is an absolutely strict…

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.

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

#247
post #181

Earlier quoted context omitted.

> 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.

C++ is a stretch, but I sort of understand GP's point. I'm slowly learning Rust now and it feels like a deep evolution of C type syntax. Not dissimilar to Javascript in the most base sense of language constructs. But you use it more and see actionscript types of function notation, funtional language semantics where you just "return" whatever was the last expression in a statement, how structs have no bodies (and clas…

I didn't think it was that controversial a statement. For example, Wikipedia says:[0]

> Rust's syntax is similar to that of C and C++,[43][44] although many of its features were influenced by functional programming languages such as OCaml.[45] Hoare has described Rust as targeted at frustrated C++ developers...[15]

I'm not sure what "actionscript types of function notation" means, but Rust's closures syntax (|x| ...) was probably inspired by Ruby and/or Smalltalk. Anyway, sure, the expression-orientedness, implicit return, etc., are very un-C++-like, but I do think the syntax was explicitly designed to be approachable to C++ developers.

[0]: https://en.wikipedia.org/w/index.php?title=Rust_(programming...

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

#248
post #233

Earlier quoted context omitted.

I 100% disagree with this. Typescript is syntactically far more complex.

Complex isn't the same thing as hard. The rust syntax often times looks like a cat walked across the keyboard.

In my eyes, Rust code is as simple as Python code or even simpler in most cases, but it also allows to create and maintain complex pieces of abstraction, when necessary, then hide them in a library or a macro. :-/

Can you show example of "written by random cat" code you often see?

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

#250

Earlier quoted context omitted.

> OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. No it doesn't. I just don't think author understands the pitfalls of implementing something like a graph structure in a memory unsafe language. The author doesn't write C so I don't believe he has struggled with the pain of chasing a dangling pointer with valgrind. There are plenty of libraries in C that e…

Whoah, hold on, the author isn't comparing writing graph structures in Rust to writing it in memory-unsafe languages --- they're comparing it to writing it in other memory-safe languages . You can't force a false dichotomy between Rust and C to rebut them.

The comparison is contrived precisely because he's comparing it to other memory-safe languages. The borrow checker was introduced because the goal of the language was a memory safe language without a runtime. Falling back to indices isn't "ironic", its exactly how you would solve the problem in C/C++.

If your argument is "well Rust should be like Julia and have a GC", well thats not Rust. That language also exists, its possibly called OCaml, but its not Rust.

Post reply on HN