The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#351

Post by timschmidt » Mon, Jun 05, 2023, 5:30 PM UTC

LordDragonfang wrote: post #340

015a wrote: post #313

Earlier quoted context omitted.

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.

It's important to note that JS has an unfair advantage in that if you want to write code that runs on the universal platform, you're forced to use either it or something that transpiles to it. Python reached where it was on merits alone. (That said, JS is actually a very versatile and almost-great language, getting better all the time)

Python reached where it is because university CS programs which had previously been teaching Java reached for a new language.

Re: The Rust I wanted had no future

#352

Post by avgcorrection » Mon, Jun 05, 2023, 5:30 PM UTC

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.

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

Yep. That just goes to show that you shouldn’t put individuals on pedestals as if they are superheroes. More things than we usually think are in fact team efforts.

> I know that the main point is about governance and how having a BDFL would have led to a completely different language

That isn’t the only main point.

> > The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got.

If you would be fine with a niche language then that “Rust” would have worked for you. But if you also wanted a language with wide industry backin etc.—maybe not so much.

Re: The Rust I wanted had no future

#353

Post by FpUser » Mon, Jun 05, 2023, 5:30 PM UTC

Ygg2 wrote: post #304

FpUser wrote: post #200

Earlier quoted context omitted.

And what should be defined behavior? There are quite a few choices that depend on particular situations. Feature designers have no knowledge about what would you want so they left it up to application programmer to check the situation upfront and act accordingly to their wishes. If you want same behavior across the whole application you can always write generic function doing just that.

Return either value or an EMPTY placeholder. Look Java did it. It returns a nullable value or Optional.

Then I have to check the result anyways. Same thing

Re: The Rust I wanted had no future

#354

Post by fallat » Mon, Jun 05, 2023, 5:31 PM UTC

bfrog wrote: post #208

After reading this I'm really quite happy Graydon created Rust, but then conceded the path it has taken. It really is an incredibly language and ecosystem, in large part, because of its performance potential. To be clear, the only real options in this space were arguably C, C++, and maybe in some circles D in my mind. C++ and C by far had the mind share. Had Rust gone the way Graydon wanted I don't think Rust would b…

Zig

Re: The Rust I wanted had no future

#355

Post by Lk7Of3vfJS2n » Mon, Jun 05, 2023, 5:31 PM UTC

Has Rust gone beyond the point of no return? Have less elegant features possibly been embedded in the language that have put Rust on the track to never become the hypothetically perfect or unblemished language?

Re: The Rust I wanted had no future

#356

Post by duped » Mon, Jun 05, 2023, 5:33 PM UTC

mjburgess wrote: post #341

duped wrote: post #335

Earlier quoted context omitted.

I still have no idea what you're talking about. Can you give an example? Most "syntax" in AOT, statically typed languages does not directly generate machine code, but it does directly impact what machine code is generated. So there's not a clear distinction in practice. For example, a lot of the syntax is used to control method selection and verification - that's not a "different" syntax or language by most folks' de…

Compare this with lisp, where there's one syntax -- compiler operations are "compile-time" interpretations of the very same syntax. Or below, let's invent a language where there's (in my sense) "one syntax for everything", Eg., consider something like, const SimpleTrait = trait with: val name def GenericApiTrait(type T) = return new trait with: def response : self -> str const MyAPI = GenericApiTrait(SimpleTrait(new…

Ah ok, I see what you're saying. It's an interesting idea.

One of the reasons that something like unified syntax is not preferred is because there are some important distinctions between runtime and comptime, and a lisp-like syntax doesn't translate well because lisp doesn't have a meaningful distinction between the two.

For example, it's desirable for some folks to have the "comptime" work (declaring types, imports, function signatures, etc) to have a purely declarative syntax. And languages like Rust use declarative syntax to express things about types, interfaces, and their constraints. Contrast that with the logic of the program which is more convenient for a programmer to express in the imperative style.

Re: The Rust I wanted had no future

#357

Post by moron4hire » Mon, Jun 05, 2023, 5:33 PM UTC

pornel wrote: post #18

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…

Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…

I've been using C# and (Java|Type)Script pretty much since they were invented. Both use a function coloring async system. I don't know what it's like in Rust, but at least in the two examples with which I have experience with this apparently much-maligned system, I really don't get the complaints. Having to "color" functions really isn't that big of a deal.

Re: The Rust I wanted had no future

#358

Post by w10-1 » Mon, Jun 05, 2023, 5:34 PM UTC

Graydon may lament the features that got away, but being a good loser may be the best way to encourage contributions and to respond to community needs. The historical forces on a language are both its constraints and its drivers. Languages that are nice conceptually are not responsive to history.

Both Swift and Rust both veered away from their original champions. The champions helped by focusing the problem and providing a technical skeleton, but the need (the pain of C/C++/Objective-C) was both intense and complex, so the community was stronger than the BDFL model.

Interestingly, Swift has seen Rust forge ahead on a number of fronts, but is quietly adopting the best of Rust, and soon interoperating with C/C++ will be frictionless. The ties to Apple are being loosened, with a more portable stdlib and a Foundation library that subsets the legacy Apple Foundation instead of dragging Apple API's into other platforms. If/since Apple is to rewrite its systems in Swift, Swift will likely evolve into the best language for migrating off C/C++.

Compare Graydon, von Rossum, or Chris Lattner to Java's Mark Reinhold. Mark has been quietly at the helm of Java since 1997, navigating: the Oracle and open-source transitions, partners ranging from IBM to broad developer communities, continuous VM updates that kept Java relevant, and the quick pace of recent language/library upgrades: lambdas (method and field handles), vector processing and FFI, native...

Re: The Rust I wanted had no future

#359

Post by collinmanderson » Mon, Jun 05, 2023, 5:34 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.

> The transition was slow

Here's the timeline the way I think about it:

- 2008-2012 Python 3 becoming usable (byte formatting, six library)

- 2012-2016 Libraries (Django, etc) becoming compatible

- 2016-today Applications (Trac, Ansible, Chrome, etc) becoming compatible.

It took a lot of time for the ecosystem to be ready. Yes, there was a lot of stubbornness, but that's reality.

There are many things that could have been done to make the transition go smoother.

Re: The Rust I wanted had no future

#360

Post by za3faran » Mon, Jun 05, 2023, 5:36 PM UTC

vips7L wrote: post #203

hadrien01 wrote: post #197

Earlier quoted context omitted.

The language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.

Isn't this just mostly an issue with mock testing in C#? Developers cargo cult single implementation interfaces because its so hard to mock concrete classes.

I've seen the same in golang, which ironically is supposed to be vehemently against OOP.