Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

241–250 of 523 posts

Re: The Rust I wanted had no future

#241

Post by estebank »

dathinab wrote: post #67

One thing I want to add wrt. "Cross-crate inlining and monomorphization. I wanted crates to allow inlining inside but present stable entrypoints to the outside." [..] is that it was in general well desired AFIK by most developers but so far out of scope that you probably would need to had the resources rust has today _before_ the 1.0 release to get it done right. At lest with the state CS research had been at during…

I think this is something that Rust might try again at some point, as part of a stable rust to rust ABI.

Re: The Rust I wanted had no future

#242

Post by _joel »

bazoom42 wrote: post #160
davedx wrote: post #61

Earlier quoted context omitted.

That being said... python had a BDFL and look how that turned out. I think designing and evolving any living programming language is just one of the hardest problems out there. Incredible blog post indeed, was awesome to read it.

> That being said... python had a BDFL and look how that turned out. One of the most popular and succesful languages, and a major force in AI innovation?

With a dodgy 2->3 migration pathway and far too many package managers.

Re: The Rust I wanted had no future

#243

Post by rirze »

jefftk wrote: post #179
viscanti wrote: post #176

Earlier quoted context omitted.

The py2 to py3 transition seems to have gone very poorly, although most of the pain from that is behind us now.

That was a seriously bad call, but it was a single one and he's made a ton of other decisions over the years.

who's "he"?

Re: The Rust I wanted had no future

#244

Post by dataflow »

hardwaregeek wrote: post #222

A lot of Graydon's ideas feel like interesting extensions to ML-style languages. I bet if he had continued down that path, it would have been a lot more of an experimental language with a hodgepodge of different ideas. Which is totally valid (you need these languages to test new paradigms and features), but definitely would not have become mainstream. Basically, I view Grayson as a leader who set the tone for Rust be…

> Rust ending up as a replacement C++ helped it

If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

Re: The Rust I wanted had no future

#245

Post by pjmlp »

dmm wrote: post #237
pjmlp wrote: post #226

Earlier quoted context omitted.

In C++ it is an error, if one bothers to enable bounds checking. https://godbolt.org/z/vYcMhE9h7 > Error: attempt to access an element in an empty container.

Someone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.

Yes, that is kind of true.

It is also what attracted me into C++ coming from Turbo Pascal and Turbo Basic, back in the early 1990's.

Although C++ culture could be much better towards safety, it is definitely better than whatever WG14 is doing, or C has brought into the picture for the last 50 years.

Also anyone that just copy pastes C like code into C++, is the kind of developer that will be using unsafe{} all over the place, on the languages that have them.

Re: The Rust I wanted had no future

#246

Post by tialaramex »

bluGill wrote: post #169
xiphias2 wrote: post #142

,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good'' If the language makes compromises in performance, it's not a real C++ competitor anymore. Some things are not about what people ,,like'', but that we need a langua…

Rust does make compromises of performance. That is not always bad so long as the compromises are minor. Fortunately Rust can do most of the checking at compile time, but it if you read from an empty vector Rust doesn't have undefined behavior and that means there is a runtime check of some sort in at least some cases. The trick is to find the right place to compromise so the cost is minimal overall even if it isn't z…

The thing is, although the check looks like work, a correct C++ solution almost always needs to do the same work. There are real world cases where it doesn't, but lots more where in C++ we need to explicitly do the work or our program malfunctions, sometimes in subtle ways - while in Rust we get this right by default.

Re: The Rust I wanted had no future

#247

Post by gardaani »

anonyfox wrote: post #143

I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the langua…

Rust borrow checker and lifetimes are sometimes so frustrating. I hope that the Jakt language will evolve to the language I'd like to see: Swift without ties to Apple and Objective-C.

Re: The Rust I wanted had no future

#248

Post by Merad »

tinco wrote: post #124
layer8 wrote: post #82

Earlier quoted context omitted.

It’s about stack size. Programs that rely on tail calls (in particular recursive ones) may cause the stack to overflow when the language implementation doesn’t actually support tail calls, for example when using tail calls to recursively process a list that is larger than (some constant fraction of) the stack. With an infinite stack, it would just be an optimization, but in practice the stack is finite (and significa…

I thought on 64 bit systems the stack could basically be infinite for all practical purposes. Is this only a problem on more limited (i.e. <64bit) systems or am I misremembering when I last learned about stacks 10+ years ago?

Yes and no. In theory it would be totally fine to "allocate" a stack that was exobytes in size (or whatever extremely large number). Thanks to virtual memory no one really cares... if that memory isn't actually being used. But as your stack grows larger and larger the OS has to find pages of physical memory to assign to that allocation, and you're simply going to run out of memory. A high end home PC or average server is only going to have 64-128 GB of RAM, a very high end server might have a few TB. Of course when you start to run out of physical memory the OS will start paging (dumping data from RAM to disk to free up memory), but that will kill the performance of your app even with high end SSD's. If you keep chugging along with your stack growth you'll probably hit OS limits on page file size next, if not you'll eventually run out of disk space.

Re: The Rust I wanted had no future

#249

Post by duped »

javajosh wrote: post #162

Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…

On top of this, there's this bogus mantra in the Rust community that "if it type checks then it works."

I've spent of hours interactively debugging Rust code, crawling through tracing output etc, and hours waiting for Rust code to link with mold because I added an eprintln somewhere, so I'm not convinced.

I love writing Rust and think it makes my life easier, but there's this stockholm syndrome about compile times. It sucks, and it's not the type system or borrowchecker's fault.

Re: The Rust I wanted had no future

#250

Post by duped »

zamalek wrote: post #164
javajosh wrote: post #162

Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…

I don't understand the big issue with build times: I have always found that they are almost instant for incremental builds (assuming you use lld or mold).

Then you're not working on big enough projects or in ecosystems where you need to regularly perform clean compiles, because afaik the "incremental" output from cargo/rustc isn't relocatable.
Post reply on HN