Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

401–410 of 459 posts

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

#401
post #94

Earlier quoted context omitted.

> and yet it’s basically a hobby language. The difference between academia languages such as ocaml or haskell and industry languages such as Java or C# is hundreds of millions of dollar in advertising. It's not limited to the academy: plenty of languages from other horizons failed, that weren't backed by companies with a vested interest in you using their language. You should probably not infer too much from a langua…

You're making it sound like the success of a language is determined purely by its advertising budget by pointing at languages that had financial backing, which disregards that financial backing allows for more resources to solve technical problems. Java and C# have excellent developer tools which wouldn't have existed in their current state without lots of money being thrown around, and the languages' adoption trajec…

> which disregards that financial backing allows for more resources to solve technical problems.

No, I'm not talking about financial backing in general, I'm talking specifically about advertising the language.

There's no doubt that a big ecosystem helps a lot, Python is a good proof of that ; but this is not what i was talking about.

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

#402

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. >> 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. > You seem to be arguing that Go is more popular than R…

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

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

#403
post #351
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

Your "great read" is horrible.

From HN's guidelines:

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.

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

#405
post #24

I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…

Very tangential, but I couldn't help but remember Crust [1]. This tsoding madlad even wrote a B compiler [2] using these... rules. Or lack thereof? [1]: https://github.com/tsoding/Crust [2]: https://github.com/tsoding/b

Crust is exactly what I had in mind, but enforced on language level basically.

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

#406
post #24

I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…

If you don't want memory safety, it seems like it'd be easier to use C++ with a static analyzer to disallow the parts you don't like. I suppose the lack of a good package manager would still be a problem.

The whole point of TFA (with which I fully agree) is that Rust is just generally a much nicer language than C++, once borrow checker is out of the picture. Discriminated unions (enums) with pattern matching alone are worth their weight in gold.

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

#407

Earlier quoted context omitted.

> isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name. Exactly the opposite actually. Rust has destructive move while modern C++ has nondestructive move. So in Rust, an object is dead after you move out of it, and any further attempts to use it are a compiler diagnosed error. In contrast, a C++ object is remains alive after the move, and further use of it isn't forb…

Indeed, this is strictly worse than rust. The object is alive but in an invalid state, so using it is a bug but not one the compiler catches. In the worse case the move is only destructive for larger objects (like SSO), so your tests can pass and you've still got a bug.

C++ teachers like Herb Sutter like to jump in here and make a correction: A moved-from object is in a valid state, you just might not know which state. You can still call methods on it that are valid in any state. ("What is your length?") But you shouldn't fall methods that are only valid in some states. ("Give me your first element.")

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

#408
post #24

I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…

You can freely alias &Cell , and this would give you memory safety compared to raw pointers. AIUI, &Cell is effectively the moral equivalent (but safe) to T* in C/C++.

It works if you only ever need to reference the outer value, but it doesn't allow you to e.g. get a working mutable reference to a field inside a struct - even if you declare the field as another Cell, when you read the value from the outer cell, you get a copy, not a reference to original. And the same thing goes for arrays, which is especially inconvenient. So no, not quite equivalent.

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

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

And typescript's doesn't? They're incredibly similar syntactically except Typescripts type system is turing complete and unsound.

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

#410
> It's perfectly clear to a human that this code is fine and doesn't have any actual ownership issues.

I think there's another part of the story in a few of these examples that the author might be missing. Sometimes Rust doesn't want to infer/allow things because of the Halting Problem or whatever, but other times it's because that inference would amount to a compatibility hazard that the user might not've realized they were creating. "Types implement `Copy` automatically" is a good example of one of these. It would be an easy rule to implement (and it is in fact how `Send` and `Sync` and some other things work), but it would also mean that adding a non-Copy private field to a struct that didn't previously have one could break callers. I wouldn't call it a slam-dunk case for the rules being what they are -- and you could argue that it prioritizes the needs of library code over the needs of application code -- but anyway it's some context.

Post reply on HN