The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#311

Post by hajile » Mon, Jun 05, 2023, 4:31 PM UTC

thiht wrote: post #194

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.

Honestly I blame the community. The transition was slow (Python 2 was supported in parallel to 3 for a long period of time so there was more than enough time to migrate), relatively easy to do, and brought huge benefits to the ecosystem. It could have been done and forgotten in 2 years if some community members had not been dicks about it.

I blame a lack of tools.

JS devs have been transpiling for years now and it works.

Python should have released a conversion tool that could automatically convert most stuff and identify the stuff it couldn't convert. This kind of directed upgrade would have made the process much easier for developers to actually accomplish.

Re: The Rust I wanted had no future

#312

Post by Georgelemental » Mon, Jun 05, 2023, 4:31 PM UTC

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…

Rust also gives you choices. If, for whatever reason, you need to get rid of that runtime check, you can always use `unsafe`. Safety is the happy path, but you aren't locked in.

Re: The Rust I wanted had no future

#313

Post by 015a » Mon, Jun 05, 2023, 4:31 PM UTC

_joel wrote: post #242

bazoom42 wrote: post #160

Earlier quoted context omitted.

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

And despite that, still a top 3 most popular programming language on the planet. And another in that top 3 is the universally-derided Javascript.

There's a lesson in there to learn. Its unfortunate that the people who need to learn it most likely won't.

Re: The Rust I wanted had no future

#314

Post by sapiogram » Mon, Jun 05, 2023, 4:33 PM UTC

rurban wrote: post #175

Interesting. So it looks like once he let the C++ folks in, they started to damage it. As they did with their own design decisions before.

> So it looks like once he let the C++ folks in, they started to damage it.

At least in terms of his personal preferences. I don't think it's true in terms of market share, given the massive success of Rust.

Re: The Rust I wanted had no future

#315

Post by weatherlight » Mon, Jun 05, 2023, 4:34 PM UTC

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…

I wish someone would go back and give love to Standard ML. it such a great language, small, and easy to learn, extremely fast, compiles fast, and expressive to boot.

It's tooling isn't great though. I think its syntax is a lot nicer than OCaml's for example.

There is this wonderful language that is up and coming called Roc that look promising.

https://www.youtube.com/watch?v=6qzWm_eoUXM

language examples here -> https://www.roc-lang.org/tutorial

Re: The Rust I wanted had no future

#316

Post by layer8 » Mon, Jun 05, 2023, 4:35 PM UTC

tinco wrote: post #186

aardvark179 wrote: post #153

Earlier quoted context omitted.

It is always a problem, in the same way that holding on to huge objects is always a problem. Let's think about this in terms of a memory map, so ignoring limits of physical memory. On 64bit systems we actually have 48bits of usable address space, so that's 256TB. Now, the OS is going to need some workspace, but I think we can ignore that for this argument. So if you're only going to run 4 threads then each one could…

Thanks, I didn't realise the usable address space was so "small", those numbers are well within reasonable usage so that's definitely too limiting to just say it's infinite and not worry about it.

Apart from address space, there’s also simply the question of wasted resources, because in tail-call-optimizable programs, that stack space is by definition not strictly needed (otherwise it couldn’t be optimized away), so you might unnecessarily be wasting many GBs of memory. Lastly, TCO can improve cache locality and thus potentially speed up the program.

Re: The Rust I wanted had no future

#317

Post by hajile » Mon, Jun 05, 2023, 4:36 PM UTC

unrealhoang wrote: post #257

sph wrote: post #32

Earlier quoted context omitted.

It makes me smile that my top-level comment says I would have preferred the ML-version of Rust, while you say you prefer the zero-cost-abstraction version of Rust that's more C++-like. Indeed in software engineering there is no silver bullet nor a perfect language for everybody :-)

There’s already a ML-version of Rust, it’s Ocaml

I'm pretty sure that the ML version of Rust is actually ATS.

https://www.cs.bu.edu/~hwxi/atslangweb/

Re: The Rust I wanted had no future

#318

Post by sapiogram » Mon, Jun 05, 2023, 4:37 PM UTC

bazoom42 wrote: post #171

To be successful, it is not enough for a language to be good. It might not even be necessary. What matters is if there is s significant niche where the language is a better fit than any alternative. PHP show that a language only needs to get that one thing right. Rust have found its niche. Graydons vision seem to be a more elegant language which would compromize on the points which actully make Rust succesful.

> What matters is if there is s significant niche where the language is a better fit than any alternative.

This is a wonderful comment, and puts into words something I've been thinking for a long time. The best general-purpose languages always seem to start out with a strong niche, then grow from there.

Re: The Rust I wanted had no future

#319

Post by marcosdumay » Mon, Jun 05, 2023, 4:37 PM UTC

tinco wrote: post #120

eru wrote: post #97

Earlier quoted context omitted.

Haskell is designed by committee, and it's a fairly alright language.

It suffers from the same problem C++ does though, it's got a broken "prelude" and the committee just doesn't have the courage to ever fix it. Weirdly a long time ago the opinion was that since the language was academic they weren't hindered by the demands of stability that corporate users might so they could do epic things like the switch to monadic I/O. I feel if the Haskell committee could simply pick one of the al…

They are fixing it... it's just happening at committee speeds.

I would really like to be able to specify what prelude I want at the .cabal file. AFAIK, that's one change that wouldn't break anything.

(Anyway, Haskell is one case of a language asking for a fork. Maybe it takes the form of Idris or some other derived language having some sudden growth instead, but you are right, the committee currently isn't as fast as the community.)

Re: The Rust I wanted had no future

#320

Post by dathinab » Mon, Jun 05, 2023, 4:38 PM UTC

estebank wrote: post #241

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.

The problem is that it's not that simple to make it work nicely you need to design you language around such constraints. Trying to do it the other way around is even harder.

For example rust in it's current design relies quite a bit on the combo of: generics monomorphisation + inlining + dead code elimination. But this reliance doesn't play well with an stable ABI. Similar features like generic associated types and similar do not make the story easier. Like an rust stable ABI likely would only support `dyn Trait` and no generics or "on the fly" provide a `dyn` variant for generic method where possible. But even that isn't really good enough for a lot of use cases in a lot of different ways. Additionally a ton of important rust things are not `dyn` compatible at all.

Even some of the "easy" to solve things aren't that easy for non-technical reasons. E.g. a lot (but not all) of `impl Into`, `impl AsRef`, `impl Borrow` etc. cases are best handled for a stable ABI context by aplying the single function of the trait (`.into()`,`.as_ref()`, etc.) _before_ calling the function and only having an ABI stable version for that. The side of which traits qualify for this is easy (you annotated the traits) the "when not apply it even if it seems valid" part isn't that easy not for technical reasons but for communication/documentation/avoiding unexpected outcomes reasons.