The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#221

Post by weinzierl » Mon, Jun 05, 2023, 2:21 PM UTC

epage wrote: post #216

weinzierl wrote: post #125

One thing I wished was on this list, but wasn't, is syntax. I love many syntax decisions Rust made, but I wish Rust hasn't borrowed so much syntax from C/C++. The syntax of these languages was designed under (for todays standards) weird keyboard and encoding constraints and many choices are just odd. To give you a few examples: - = instead of == for equality would have been the natural choice - := for assignment is s…

> - := for assignment is similar enough to what is used in math for definition, so that languages like Pascal use it I think its cppfront that is taking the approach of `:=` being a declaration with the type being inferred (ie shorthand for `: Type =`). Reading up on that has made me the most ok with applying this to functions (which I see coming up more these days) but I think i still prefer functions having a more…

My very first programming language had fn, so maybe my love for it is just a form of nostalgia.

Re: The Rust I wanted had no future

#222

Post by hardwaregeek » Mon, Jun 05, 2023, 2:21 PM UTC

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 being a language that was willing to take ambitious swings on cutting edge features. But I don't think he would have been the person to eventually make the cuts and compromises necessary to hew the language into a cohesive, mainstream language. Rust ending up as a replacement C++ helped it not only determine which features to keep and which rules to follow, but also helped it create the right pitch for developers to use it.

This does lead to a larger question about BDFLs. Perhaps, like CEOs, the BDFL you want when you're starting a language is not the BDFL you want when you're maturing a language, or maintaining a language. Especially around feature selection, in the beginning it may pay off to add a lot of features based on user feedback, but later on it may be better to push back more. And from a psychological standpoint, I have wondered about the pressure of being a BDFL. Grayson has been open about stepping down partially due to reaching his limits, and I suspect other BDFLs have thought about it too. The job sounds exhausting and thankless. At a certain point, wouldn't you want to leave and start a new project? And wouldn't we want the person who had success once to give it another shot?

Re: The Rust I wanted had no future

#223

Post by kaba0 » Mon, Jun 05, 2023, 2:23 PM UTC

LinXitoW wrote: post #141

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…

> Why on earth would you try to rewrite python CRUD apps in Rust? Because Rust has a lot of incredibly helpful features that make bigger systems far less of a pain to maintain. I work in Java/Kotlin, and my entirely gut-based estimate is that 66% of problems wouldn't happen in Rust. My big favorites are: - Sane, well-defined, enforced, opt-out error handling - Sane, well-defined, enforced, opt-out handling of "missin…

Scala has all of that and predates Rust by far.

But even Java is pretty much there: checked exceptions are available (and imo superior), but Optional is also an.. option. Kotlin/scala can handle nulls, but java can also statically analyse every usage with annotations.

switch expressions are exhaustive in java over enums and sealed ADTs. (Rust has a misnomer, their enums are ADTs, java has both real enums and ADTs now).

Re: The Rust I wanted had no future

#224

Post by FpUser » Mon, Jun 05, 2023, 2:24 PM UTC

tick_tock_tick wrote: post #31

rob74 wrote: post #15

Earlier quoted context omitted.

I think this quote also applies more generally: > It's easier to work with than C++, but that's fairly faint praise. So, while Rust positions itself as a C++ alternative with all the complexities that C++ developers love, it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust...

> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust... I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.

>"I mean who'd want to and why bother trying to support that use case"

I write my web apps in C++. They tend to be little bit more than just query database / update database. They're exposed as JSON based RPC and can be accessed by JS front end from browser or third party systems we interact with. The performance is stellar and the code size is not much different comparatively to using PHP / Ruby / Python / your_pet_goes_here.

Re: The Rust I wanted had no future

#225

Post by kaba0 » Mon, Jun 05, 2023, 2:24 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.

Well put. Rust wouldn’t be anywhere near this big/hyped if it would have been a new ML.

Re: The Rust I wanted had no future

#226

Post by pjmlp » Mon, Jun 05, 2023, 2:33 PM UTC

Ygg2 wrote: post #17

kzrdude wrote: post #10

Earlier quoted context omitted.

I was at the sidelines when Rust 1.0 was being made and I think it got into an llvm induced feedback loop. Slowly turning into C or C++ with other features but the same type, object and memory model. Part of the reason was Rust's desire to show itself as a direct competitor w.r.t performance, I think.

Performance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

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.

Re: The Rust I wanted had no future

#227

Post by pjmlp » Mon, Jun 05, 2023, 2:33 PM UTC

tialaramex wrote: post #201

intelVISA wrote: post #132

Earlier quoted context omitted.

The fatal mistake here is using the STL...

The safe thing Rust did here is affordable in Rust (Option is the same size as T for many T including all references) so they could afford to do it, whereas it's expensive in C++. Could it have been made cheaper in C++? Sure, but safety wasn't their priority so who cares? That prioritisation applies to the whole ISO language, not only to the standard library.

Talking about C?

https://godbolt.org/z/vYcMhE9h7

Re: The Rust I wanted had no future

#228

Post by ninkendo » Mon, Jun 05, 2023, 2:34 PM UTC

hgomersall wrote: post #220

School-Cotton wrote: post #182

Earlier quoted context omitted.

They could have simply not added async to the language. I was happily using rust before async and it was perfectly fine.

So don't use it. Why object to those that do have a use case for it?

Because it's possible the crate you want to use, uses it.

Re: The Rust I wanted had no future

#229

Post by pjmlp » Mon, Jun 05, 2023, 2:37 PM UTC

While it has a been a great piece of wrong to introduce affine type systems into mainstream, it hardly justifies outside domains where any kind of automatic memory allocation isn't either a blocker, or religious issue that won't be sorted out even by proving the contrary.

I see the ongoing attempts to add linear types for low level coding, alongside automatic resource management more future proof.

Re: The Rust I wanted had no future

#230

Post by mjburgess » Mon, Jun 05, 2023, 2:40 PM UTC

kaba0 wrote: post #219

mjburgess wrote: post #110

Over the evolution of Rust, I've been increasingly despairing about many of the things Graydon here dislikes. I assumed the present "syntactical insanity" was, somehow, intended; it seems, really, it wasn't. I find Rust basically unusable -- at the level of abstraction I want to write code, basic definitions break line limits. Rust seems to be a repetition of C++'s mistake: a language which conspires you to pretend i…

Rust is a low-level programming language meant to control everything about the code’s execution. It will by almost definition, be complex. You seem to want contradictory things — if you don’t need that level of control just use any of the litany of high level languages with nice syntaxes. I don’t think we can eat this cake anytime.

The major innovation in this space is to make the compiler an interpreter which can evaluate the language at compile time (and emits code for runtime where it cannot).

This makes brining in the "full power of dynamic languages" almost trivial and extremely performant.

Delete half of rust's symbols, get rid of its macro system, rewrite it until lifetimes are inferred /or/ allocators are explicitly chosen, etc. etc.

I don't want to feel visually assaulted when writing the type signature of the sort of function common in a dynamic language. Here `mypy` is also treasonously guilty.

Consider, eg., zigs "function which returns a type at compile-time" is an example of where blindingly-obvious syntax retains its blindingly-obviousness because of compile-time eval... ie., we dont need a "second syntax" to program the compiler.

This "two syntaxes, one for the runtime and one for the compiler" approach -- has swamped Rust as it aims for greater expressiveness. Not least, because it has a third syntax: one for unsafe.