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

391–400 of 459 posts

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

#391

Post by camgunz »

ModernMech wrote: post #357
camgunz wrote: post #327

Earlier quoted context omitted.

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)

The median number of users across all programming languages is zero. Millions of people around the world use Rust and Swift, so it seems like a stretch to say they're far from popular. If Rust isn't a popular language compared to Java, we might just as well say Java is not a popular language compared to Excel.

I don't think millions of people use either Rust or Swift.

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

#392

Post by ActorNightly »

IshKebab wrote: post #276
ActorNightly wrote: post #120

Earlier quoted context omitted.

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

This isn't true in practice. People don't write impossibly comprehensive test suites in C, and they don't use extremely loose types in Rust either. It really does matter which language you choose if you want correct code. > programming in something like C is going to be more efficient, whereas the second language will force you write a lot more code for basic things. Like how string manipulation is so much simpler an…

Also practice, most of Rust codebases are filled with `unsafe`, for interface with system libraries.

Also the argument of forcing a language onto a project based on the lowest common denominator of programmers never plays out - this is how you get insanely messy Java codebases. Language choice will never solve poor programming style.

>Like how string manipulation is so much simpler and easier in C compared to Rust? Hmm.

Plenty of libraries for C for this.

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

#393

Post by ChadNauseam »

fpoling wrote: post #221
ChadNauseam wrote: post #115

Earlier quoted context omitted.

My interpretation of the post is that the rule is deeper than that. This is the most important part: > Here is the most famous implication of this rule: Rust does not infer function signatures. If it did, changing the body of the function would change its signature. While this is convenient in the small, it has massive ramifications. Many languages violate this. As another commenter mentioned, C++ templates are one e…

Lifetimes for a function signature in Rust are never inferred from the function code. Rather Rust has implicit lifetime specs with straightforward rules to recover the explicit full signature.

I was speaking about variance specifically. They are not inferred from function bodies, but I think it's fair to say that it's a soft violation of the golden rule because variance has a lot of spooky action at a distance (changing a struct definition can change its variance requirements, which then has ripple effects over all type signatures that mention that struct)

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

#394

Post by ActorNightly »

JambalayaJimbo wrote: post #245
ActorNightly wrote: post #120

Earlier quoted context omitted.

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

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 to shit codebases.

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

#395

Post by Boxxed »

> Use fewer references and copy data. Or: "Just clone".

> This is generally good advice. Usually, extra allocations are fine, and the resulting performance degradation is not an issue. But it is a little strange that it allocations are encouraged in an otherwise performance-forcused language, not because the program logic demands it, but because the borrowchecker does.

I often end up writing code that (seems) to do a million tiny clones. I've always been a little worried about fragmentation and such but it's never been that much of an issue -- I'm sure one day it will be. I've often wanted a dynamically scoped allocator for that reason.

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

#396

Post by Kranar »

af78 wrote: post #293
Kranar wrote: post #185

Earlier quoted context omitted.

I can't substantiate your claim about Erlang or weird syntax, is that either a proper quote or some kind of paraphrasing because nothing remotely close to it comes up. There are numerous interviews with Rob Pike about the design of Go from when Go was still being developed, and Erlang doesn't come up in anything that I can find other than this interview from 2010 where someone asks Rob Pike a question involving Erlan…

The parent comment does not say that Go derives from Erlang, but that both Erlang and Go implement CSP ( https://en.wikipedia.org/wiki/Communicating_sequential_proce... ), with the advantage for Go over Erlang that its syntax is more familiar to programmers who know C.

Erlang does not implement CSP, and if you review the very Wikipedia link you presented it should be clear. Erlang implements the Actor model, which is more flexible for distributed, fault-tolerant systems, but lacks CSP's strict formalism and synchronization semantics. The very Wikipedia article you linked to has an entire section on how CSP differs from the Actor model. Similarly Go also does not implement CSP either, although it certainly is influenced by it.

The point of my comment is that to say that Go is basically Erlang style CSP without the weird syntax is not justified as an actual quote nor as a paraphrasing or summary of anything that anyone involved in the design or promotion of Go has ever said. It's best to reserve quotes for situations where someone actually said something or as a way to summarize something for which there are ample references available.

One should not use quotes as a way to present mostly original claims that are presented as if it's some kind of already well established knowledge.

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

#397

Post by tialaramex »

camgunz wrote: post #368
tialaramex wrote: post #347

Earlier quoted context omitted.

You seem to be arguing that Go is more popular than Rust, but that's not what we're talking about. The claim made was "Go is the only popular modern language (ie from this millennium)" That's a binary, either a programming language is "modern" (from this millennium) or not and either it is "popular" (undefined) or it is not, Go is popular and modern according to the claim. On your lists you find Go is anywhere from 7…

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 about? I don't think you have to squint too hard to invent the gap between Go and Rust (et al).

Likewise for Go and Python or Javas, so why the "top 10" ? Arbitrary.

> TypeScript is JavaScript

No. Javascript is (very bad) Typescript, but Typescript is not Javascript. That's why they have a transpiler.

If you contend that the similarity means they're the same language that makes C++ also C and I don't think you want to start that fight.

My pithy response to the Stroustrup argument is a T-shirt I own which says "Haters gonna make some good points". Yes of course people will criticize your popular language, but this observation does not make the criticisms untrue, and resorting to Stroustrup's argument is best understood as an admission that he has no response to the actual criticism.

C++ is remarkably bad. You're looking at popularity lists. What else is on those lists which has similar levels of criticism? Go is a long way short of perfect but it's nowhere close to C++. If Go is the Stallone "Judge Dredd" then maybe C++ is "Batman & Robin".

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

#398

Post by Groxx »

timmytokyo wrote: post #97
jltsiren wrote: post #25

This reminds me of something that was popular in some bioinformatics circles years ago. People claimed that Java was faster than C++. To "prove" that, they wrote reasonably efficient Java code for some task, and then rewrote it in C++. Using std::shared_ptr extensively to get something resembling garbage collection. No wonder the real Java code was faster than the Java code written in C++. I've been writing C++ for a…

If using indices is going to be your answer, then it seems to me you should at least contend with the OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. From the post: "The Rust community's whole thing is commitment to compiler-enforced correctness, and they built the borrowchecker on the premise that humans can't be trusted to handle references manually. Wh…

That seems rather easy? There's still plenty of safety. It's not an `unsafe` trick or worse, you still have bounds checking and safe concurrency and well-defined behavior, and you can trivially guarantee that (while mutating the vec) it cannot be changed unexpectedly while you hold ownership of the vec. The extreme ease of making that guarantee is kinda the core of their complaint.

The dangling-pointer equivalent is an issue, but it's still safe (unlike in C-like langs) and there are ways to mitigate the risk of accidental misbehavior (e.g. generational pointers, or simply an ID check if you have a convenient ID).

That's quite a bit different than what you get in almost any other widely-used language - e.g. some will at best be able to claim "concurrent access won't lead to undefined behavior" via e.g. the GIL, but not prevent unexpected modification (e.g. "freeze" doesn't deep-freeze in the vast majority of languages).

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

#399

Post by pyrale »

fooker wrote: post #153
pyrale wrote: 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…

> hundreds of millions of dollar Yes. > in advertising No, in hiring 500 compiler and tool developers, developing and supporting libraries, optimizing it for niche use cases.

The Java ecosystem has benefited from way more than that. I was specifically refering to advertising. For instance this kind of headlines [1].

[1]: https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...

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

#400

Post by Kranar »

camgunz wrote: post #391
ModernMech wrote: post #357

Earlier quoted context omitted.

The median number of users across all programming languages is zero. Millions of people around the world use Rust and Swift, so it seems like a stretch to say they're far from popular. If Rust isn't a popular language compared to Java, we might just as well say Java is not a popular language compared to Excel.

I don't think millions of people use either Rust or Swift.

Millions of people don't use Go either.
Post reply on HN