The Rust I wanted had no future • Hacker News Board

Re: The Rust I wanted had no future

#121

Post by twic » Mon, Jun 05, 2023, 11:27 AM UTC

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…

> 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 do think the enthusiasm for using Rust for web apps and such (a) is misplaced and (b) has been a drag on Rust developing into a better C++ replacement.

Re: The Rust I wanted had no future

#122

Post by EdwardDiego » Mon, Jun 05, 2023, 11:28 AM UTC

truculent wrote: post #60

It sounds like the Rust He Wanted has a lot of thematic similarities to Elm. Interestingly, Elm has a BDFL, and a development process that reflects that. And he’s right - there are a lot of people who really don’t like that! Overall, a really interesting article. Though I like today’s Rust, I do think I would prefer the trade-offs made by the alt-Rust outlined here. Perhaps it’s just my own personal preference, but I…

My understanding is that for the Elm BDFL, the B was dropped.

Re: The Rust I wanted had no future

#123

Post by FrustratedMonky » Mon, Jun 05, 2023, 11:28 AM UTC

Great read from a creator of a language. There are so many new languages these days, it is always enlightening to hear the author discuss design tradeoff's. That being said, man, its easy to forget how difficult and complicated creating a good language can be.

Makes me wonder if things like Linux, or C++, were historical anomalies, the stars aligned. How many good projects fail because of 'loosing arguments' that should have been won, or the community didn't form, etc... a million things..

Re: The Rust I wanted had no future

#124

Post by tinco » Mon, Jun 05, 2023, 11:30 AM UTC

layer8 wrote: post #82

Aardwolf wrote: post #77

> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and…

It’s about stack size. Programs that rely on tail calls (in particular recursive ones) may cause the stack to overflow when the language implementation doesn’t actually support tail calls, for example when using tail calls to recursively process a list that is larger than (some constant fraction of) the stack. With an infinite stack, it would just be an optimization, but in practice the stack is finite (and significa…

I thought on 64 bit systems the stack could basically be infinite for all practical purposes. Is this only a problem on more limited (i.e. <64bit) systems or am I misremembering when I last learned about stacks 10+ years ago?

Re: The Rust I wanted had no future

#125

Post by weinzierl » Mon, Jun 05, 2023, 11:30 AM UTC

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 similar enough to what is used in math for definition, so that languages like Pascal use it

- for inequality is something SQL got right

Smaller things that bug me are the ubiquity of the double colon (::) and the weird mixture of snake case and camel case conventions.

And not to leave the wrong impression, I think Rust got many things very right. My personal highlights are:

- -> for the return value

- concise keywords like `fn`

- `where` for constraints

In general more Algol/Pascal and Haskell - less BCPL and C/C++.

Re: The Rust I wanted had no future

#126

Post by dist1ll » Mon, Jun 05, 2023, 11:33 AM UTC

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…

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

Re: The Rust I wanted had no future

#127

Post by jstx1 » Mon, Jun 05, 2023, 11:33 AM UTC

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…

Syntax is mentioned in the article - it's under "Complex Grammar".

Re: The Rust I wanted had no future

#128

Post by internetter » Mon, Jun 05, 2023, 11:42 AM UTC

devjab wrote: post #27

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

We build a proof-of-concept backend replacement for what is essentially “SharePoint being used as a DB with a frontend by people who don’t know how to use SharePoint” and was a nice experience. We also build it in a few other languages, C#, Go, Python and TypeScript and Rust was probably the best experience of them all. We ended up going with C# because we needed Odata, and at the time we hadn’t yet run into the many…

> I wish Rust would have someone like Facebook pick it up and build a frontend framework for it

We have yew, and my personal favourite: leptos (https://leptos.dev/)

Re: The Rust I wanted had no future

#129

Post by logicchains » Mon, Jun 05, 2023, 11:42 AM UTC

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…

The Rust async story would be much nicer if they'd put in the hard work up front to support higher-kinded types, as then it could have a monadic async API like OCaml or Haskell. I don't know anyone who's used async in both Rust and Haskell who prefers the Rust approach. It'd also fix oddities like why it's possible to write a function like the following in C++ but not Rust:

    template class MyContainer>
    int getFirstInt(const MyContainer& myContainer) {
      return myContainer[0];
    }

(In Rust it's not possible to write something like MyContainer; only the int is allowed to be generic).

Re: The Rust I wanted had no future

#130

Post by JonChesterfield » Mon, Jun 05, 2023, 11:46 AM UTC

Aardwolf wrote: post #77

> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and…

Tail call optimisation means no work can be done after the call and before the return. You can't deallocate stack, call destructors, convert types, rethrow exceptions.

Therefore _yes_ the compiler can always do it, but it may involve patching the called function to do some work. Splicing code into it and/or changing the calling convention. That's difficult to do for unknown caller/caller pairs, e.g. function pointers or separate compilation to machine code without enough metadata to patch it later. It runs a bit close to "sufficiently smart" compiler which usually means doable in theory but unlikely in practice.

If you pick global designs to make them easier - probably most notably having the callee clean up the stack frame from the caller - and that makes other things slower, then you've given the competition an edge.

Clang now has tail call annotations for C++, which works mostly because the compiler can reject them in the cases where it hasn't implemented the lowering. Rust can probably have it in the same approximate circumstances as C++.