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

281–290 of 523 posts

Re: The Rust I wanted had no future

#281

Post by estebank »

logicchains wrote: post #271
chrismorgan wrote: post #158

Earlier quoted context omitted.

Are you aware of generic associated types , which landed in 1.65 (late last year)? To a considerable extent, they’re Rust’s answer to higher-kinded types. Less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature. If I’m reading your snippet right, GATs let you express exactly that, though minus `template`’s duck-typiness so you’d have to s…

>less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature They're not expressive enough to implement a monadic async library, as far as I'm aware, so they don't fulfill the role of proper HKTs in this context. >minus `template`’s duck-typiness so you’d have to spell out what contract the container must adhere to. Do you think it's consiste…

In Rust neither is duck typed. For T you must specify the traits it must have. This makes compilation fail at definition, not at the point of incorrect usage.

For an example of GATs, you can see the following:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: The Rust I wanted had no future

#282

Post by imtringued »

pclmulqdq wrote: post #198
sph wrote: post #113

Earlier quoted context omitted.

A dictator might just have terrible ideas. His dislike for functional constructs didn't do Python any favour, but now that he's gone I see Python is adding the kitchen sink as well. I haven't kept up with the language since that pattern matching proposal.

People who are deeply into programming languages seem to like FP too much. That and theories of type systems. Python is doing some great things, but also just fucking around a lot.

As someone who doesn't like Python. Python's problems have almost nothing to do the lack of functional programming. It does have the worst lambda syntax of any programming language but that is about it.

Re: The Rust I wanted had no future

#283

Post by xiphias2 »

rtpg wrote: post #7
jstx1 wrote: post #2

A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either. I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today. Very interesting article, worth a read.

I am very glad to not have Rust end up along that path (I am sympathetic to the threading idea he mentioned though). Rust as an alternative to C++ does, for me, involve all of the weird magical nonsense that you kind of need to get any of this working. The extreme use of generics to build out DSLs to get things working. General libraries being very hard to write, but still possible, to get alright ergonomics for usag…

Some Rust developer said that Rust was originally what Go has become.

So if you want to try something like that, just look at Go :)

Re: The Rust I wanted had no future

#284

Post by kaba0 »

zozbot234 wrote: post #269
kaba0 wrote: post #234

Earlier quoted context omitted.

You quickly gets into the undecidable category once you to down that road, which might be fine if you either don’t care about safety, or have runtime checks for that, but none of those were an option for rust (or at least an option that would have made it remotely interesting).

It's undecidable in the general case, but it becomes doable in non-Turing-complete languages that are still expressive enough to be useful for many practical cases. (These languages can express unrestricted recursion as an I/O-like effect that's only available outside the language proper, as part of compiling to a binary.)

Lifetimes only work because they are very restrictive - the moment you can’t decide that you end up with a non-safe language.

Re: The Rust I wanted had no future

#285

Post by dralley »

duped wrote: post #249
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. I…

>hours waiting for Rust code to link with mold because I added an eprintln somewhere

How is that Rust's fault?

Re: The Rust I wanted had no future

#286

Post by lukebitts »

PhilipRoman wrote: post #41

Haven't followed Rust too much, but I'm always surprised when I hear that Rust is too difficult or not ergonomic. As I understand it is meant to be a systems level language; something you'd use to write kernels, TCP stacks, browsers and ssh daemons. Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. In such projects churning out lines of co…

I personally really like the type-system, for any kind of project really

Re: The Rust I wanted had no future

#287

Post by xiphias2 »

bluGill wrote: post #189
twic wrote: post #121

Earlier quoted context omitted.

> Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. I've certainly seen seasoned C++ programmers saying this. Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! > Why on earth would you try to rewrite python CRUD apps in Rust? This is one of the great mysteries of our times. I…

> Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! There is a difference between understanding lifetimes and being able to keep track of them. I have a lot of objects in my more than 10 million lines of code. Most of them have simple lifetimes that are easy to track, but a few for reasons (which may or may not be valid - often the reasons are it was bu…

I think there's enough data that even the best human programmers and lifetime checkers aren't able to track lifetimes over a 10 million line code base.

That's why we're stuck with lifetimes as function contracts.

Re: The Rust I wanted had no future

#288

Post by deltaninenine »

fzeindl wrote: post #205
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it. A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

[dead]

Re: The Rust I wanted had no future

#289

Post by deltaninenine »

duped wrote: post #255
fzeindl wrote: post #205

Earlier quoted context omitted.

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it. A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

Developers should learn the difference between concurrency and parallelism because async isn't equivalent to threading.

[dead]

Re: The Rust I wanted had no future

#290

Post by imtringued »

pjmlp wrote: post #245
dmm wrote: post #237

Earlier quoted context omitted.

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

Telling people to stop using unsafe is much easier than telling people to not have undefined behaviour.

C developers like telling themselves that only people with bounded rationality make security critical mistakes. All the skilled C developers have ascended beyond the mortal realm and would never let themselves be chained up with crutches for the weak like affine types or overflow/bounds checking.

Post reply on HN