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

211–220 of 523 posts

Re: The Rust I wanted had no future

#211

Post by kaba0 »

pjc50 wrote: post #145
inferiorhuman wrote: post #68

Earlier quoted context omitted.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great . Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather tha…

> Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. ... Mapping JSON (or whatever) to strongly typed objects is great cough C#. You also get LINQ. And a fairly heavy amount of web frameworks in ASP.NET / Razor.

Or Java, F#, Scala, Kotlin, Haskell. If we were to randomly pick a language, chances are it could be a good fit for these — Rust became as well-known as is because it was made for a different niche, where there were no competition.

Re: The Rust I wanted had no future

#212

Post by kaba0 »

LinXitoW wrote: post #134
vsnf wrote: post #85

Earlier quoted context omitted.

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

To me, one thing missing from most popular web languages is the single best part of Rust: A well-defined handling of the non-happy path. I'm talking about things like exhaustive "switches", built-in, ENFORCED handling of "missing" values (null, undefined), and finally useful error handling. I actually don't need any of the baremetal features of Rust. It's just that most of it's "zero-cost" abstractions are still far…

Haskell, Scala, F#, OCaml.

(Some dislike it, but Java’s checked exceptions are exact homologous of result types)

Re: The Rust I wanted had no future

#213

Post by kaba0 »

sph wrote: post #32
moonchrome wrote: post #8

As someone casually following Rust and haven't touched it or C++ in probably 5+ years (but keeping tabs in hope of coming back to that world), I feel like a lot of decisions he mentions are what made me optimistic about Rust adoption/positioning itself as a modern C++ replacement. So I kind of agree with his conclusion - his version of Rust would be much less interesting to me, and I think a lot of it's current users…

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 :-)

ML-version of Rust would not have been a uniquely interesting language. It targeting the C++-niche is what made it into quite the big name it has become.

Re: The Rust I wanted had no future

#214

Post by kaba0 »

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…

Scala, Haskell, Java, Kotlin.

Re: The Rust I wanted had no future

#215

Post by Merad »

inferiorhuman wrote: post #100
vsnf wrote: post #85

Earlier quoted context omitted.

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

any of which offer everything you've outlined They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.

Your knowledge of the .Net ecosystem is a bit out of date. It's had first class support for mac and linux for 7-8 years now.

Re: The Rust I wanted had no future

#216

Post by epage »

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 distinct look as I process them differently when reading. Now, cppfront's approach to types I think is bonkers, making critical details hard to find except maybe through convention.

https://github.com/hsutter/cppfront

> for inequality is something SQL got right

Maybe I'm not recognizing the biases of my own learning background but this never reads right to me vs "not equal" / `!=`.

> - concise keywords like `fn`

In other discussions, it sounded like Graydon had an upper limit of 4 characters for keywords

https://www.reddit.com/r/rust/comments/13oemrg/question_abou...

For me, I had a "whoosh" moment for `fn` and always thought it a weird abbreviation, completely overlooking "fn" keys on laptops.

Re: The Rust I wanted had no future

#217

Post by pjmlp »

intelVISA wrote: post #132
Ygg2 wrote: post #17

Earlier quoted context omitted.

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

The fatal mistake here is using the STL...

The fatal mistake is not enabling bounds checking, which most STL implementations support.

Re: The Rust I wanted had no future

#218

Post by 0xDEF »

Rust moved in a direction where it is now a suitable alternative to C/C++ all the way down to operating system code and bare-metal embedded firmware.

Graydon wanted something else even before Rust 1.0 was released. He wanted an OCaml-like language with modern Go/Erlang-inspired higher level concurrency abstractions.

Re: The Rust I wanted had no future

#219

Post by kaba0 »

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.

Re: The Rust I wanted had no future

#220

Post by hgomersall »

School-Cotton wrote: post #182
dist1ll wrote: post #126

Earlier quoted context omitted.

> That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring) Function coloring seems to come up a lot in these discussions, but I don't see a better way without providing a runtime. Could you propose an alternative approach to async, without sacrificing ability to write zero-overhead, high-performance bare metal systems?

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?
Post reply on HN