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

261–270 of 459 posts

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

#261

Post by jeeyoungk »

rastignack wrote: post #244
gdbsjjdn wrote: post #123

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…

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 framework level. Most channels that developers interact with is the `Context.Done()` channel with Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.

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

#262

Post by zozbot234 »

zer00eyz wrote: post #143
roland35 wrote: post #37

Earlier quoted context omitted.

I'm not sure.. without the borrow checker you could have a pretty nice language that is like a "pro" version of golang, with better typing, concise error handling syntax, and sum types. If you only use things like String and Arc objects, you basically can do this, but it'd be nice to make that not required!

> without the borrow checker ... golang... concise error handling syntax Except both of these things are that way for a reason. The author talks about the pain of having other refactor because of the borrow checker. Every one laments having to deal with errors in go. These are features, not bugs. They are forcing functions to get you to behave like an adult when you write code. Dealing with error conditions at "googl…

You can absolutely "go fast and break things" (i.e. write prototype-quality code) in Rust, but it requires a lot of boilerplate that will be very visible in the code, and will also make it comparatively easy to refactor the prototype into a real production-quality implementation. You can't really say this of any other languages AIUI. What often happens instead is that the prototype is put in production more or less as-is, without comprehensively fixing the breakage. Rust makes it very clear how to avoid that.

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

#263

Post by nemothekid »

blub wrote: post #252
nemothekid wrote: post #158

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…

C doesn’t have objects, which are great for encapsulating data structures, but in C++ it’s not at all hard to write a graph data structure. One wraps it behind a reliable interface, writes automated test and runs them under valgrind/sanitizers and that’s pretty much it. It’s normal for life and software development to have a certain degree of risk and to spend some effort solving problems. Too many HN comments make i…

I don't mean to imply that writing a graph in C++ is impossible. It's clearly possible in modern C++.

My contention is treating indicies-based management as some tedious, manual workaround. Unity's ECS is written in C#, which has both a GC and the language expressiveness for an actual graph objects, but has adopted an indicies based system. It works, and is performant, so it isn't a mistake for the compiler to herd users down that path.

In a similar vein, the Linux codebase is full of completely legitimate and readable uses of goto, but we are perfectly happy with languages that force us to use structured control flow.

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

#264

Post by ashdksnndck »

ActorNightly wrote: post #220
ashdksnndck wrote: post #146

Earlier quoted context omitted.

This claim makes some sense to me if your development life cycle is: write and compile once, never touch again. Working at a company with lots of systems written by former employees running in production… the advantages of Rust become starkly obvious. If it’s C++, I walk on eggshells. I have to become a Jedi master of the codebase before I can make any meaningful change, lest I become responsible for some disaster. I…

>If it’s Rust, I can just do stuff and I’ve never broken anything. This is not true. Case and point- Java. Many times simpler than Rust, and large codebases are as horrible as C++ ones.

I have two primary complaints about Java, relative to Rust:

1. NullPointerException. I get some object with a bunch of fields and I don’t know which of them are null. In Rust I am given a struct, and usually the fields aren’t an Option unless they need to be.

2. Complicated design patterns with inheritance. Maybe it’s more of a problem with the culture/ecosystem than Java the language. But Rust doesn’t have inheritance, and traits are less complicated. So you rarely get the same smells.

Compared to C++, Java is easier to debug, but I still have a lot of “wtf” moments trying to understand what the author was thinking. It is almost like the language is so simple to write, people are making the program more complicated on purpose just to make it interesting.

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

#265

Post by TylerE »

xyse53 wrote: post #162
pif wrote: post #155

Earlier quoted context omitted.

[flagged]

I think that's harsh. IME Go excels in a business setting where the focus is on correct, performant, maintainable, business logic in larger organizations, that's easy to integrate with a bunch of other systems. You can't squeeze every last bit of low-level performance out of it but you can get ... 9x% of the way there with concurrent code that is easy to reason about.

What matters is being 100x faster than python, not 5x slower than C++ or 2x slower than Java. Performant enough that IO (or network) rather than CPU is the bottleneck (in my limited experience).

Personally I just far prefer to work in a GCed langauge. Much simpler mental model.

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

#266

Post by zozbot234 »

int_19h wrote: 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++.

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

#267

Post by Buttons840 »

luckystarr wrote: post #117
ChadNauseam wrote: post #105

> [The pain of the borrow checker is felt] when your existing project requires a small modification to ownership structure, and the borrowchecker then refuses to compile your code. Then, once you pull at the tiny loose fiber in your code's fabric, you find you have to unspool half your code before the borrowchecker is satisfied. Probably I just haven't been writing very "advanced" rust programs in the sense of doing…

I believe it. I experienced this once, as I tried to have everything owned. Now I just clone around as if there's no tomorrow and tell myself I'll optimize later.

I need to do this, but I get fixated on interesting but premature optimizations.

Just clone everything, profile, and remove the clones that take significant time.

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

#268

Post by tacitusarc »

hardwaresofton wrote: post #238
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.

> Nobody cared about Erlang back then and nobody does today. > > I write Erlang for a living. I think this is incredibly correct and obviously personally true for you but I'd like to add one more thing from the peanut gallery. No one really needs Erlang either. Turns out most problems are just fine not being modeled in the way that Erlang wants to model problems.

Just as a someone with a hammer could truthfully claim they don’t need a nail gun.

Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.

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

#269

Post by gethly »

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…

> but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages

Are these people here in the room with us right now?

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

#270

Post by one-note »

shakna wrote: post #171
one-note wrote: post #137

Earlier quoted context omitted.

React is and has always been javascript…

Not what the author of React says: > Yes, the first prototype of React was written in SML; we then moved onto OCaml. > Jordan transcribed the prototype into JS for adoption; the SML version of React, however great it might be, would have died in obscurity. The Reason project's biggest goal is to show that OCaml is actually a viable, incremental and familiar-looking choice. We've been promoting this a lot but I guess…

Sure, a prototype of an idea that would eventually become React was rewritten into JS to create the initial seed of the software that would eventually be called React.
Post reply on HN