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

131–140 of 523 posts

Re: The Rust I wanted had no future

#131

Post by Tyr42 »

Aardwolf wrote: post #104
layer8 wrote: post #82

Earlier quoted context omitted.

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…

What I actually meant to ask is: given what you said, is supporting it then even a language feature, and not a compiler optimization instead? If rust says they don't support it, does it mean they don't even allow the compiler to do it? Obviously the syntax of the language itself already supports calling the function itself, and whether tail call optimization is supported or not doesn't affect the visible result afaik…

I suppose a difference of speed turns into a difference of ability at some point. If you can't rely on tail calls, you will have to manually trampoline the calls, just in case the optimization didn't kick in and your program dies.

Or like xmtp or mail or whatever, you generally write your client assuming you are going to talk to any spec compliment server, which can stop you from using some extensions if you aren't sure they will be supported.

Possible is not the same as guaranteed.

Re: The Rust I wanted had no future

#132

Post by intelVISA »

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

The fatal mistake here is using the STL...

Re: The Rust I wanted had no future

#133

Post by jedisct1 »

Aissen wrote: post #12

On integer wrapping, I think explicit wrap is annoying at first, but eliminates a whole class of bug. I can only agree with: > (Swift at least traps in release by default -- I wish Rust had chosen to). I enable it in release on serious projects: [profile.release] overflow-checks = true

And then you may just have introduced side channels in crypto code.

Re: The Rust I wanted had no future

#134

Post by LinXitoW »

vsnf wrote: post #85
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…

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 superior to those of other languages.

Re: The Rust I wanted had no future

#135

Post by belmont_sup »

sph wrote: post #22
pornel wrote: post #18

Earlier quoted context omitted.

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 disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Algebraic effects like how OCaml’s now implementing it may be possible! The ecosystem around effects in OCaml is still really young, but here’s an example of an http request being made that is asynchronous, non-blocking but looks synchronous with no special syntax.

https://github.com/mirage/ocaml-cohttp/blob/16e991ec1f7e5f0c...

Performing these effects is similar to throwing exceptions up the callstack where whichever ancestor handles the IO work, then resumes the child with IO work done in hand.

Re: The Rust I wanted had no future

#136

Post by JonChesterfield »

LeanderK wrote: post #39

Can someone comment on "Library-defined containers, iteration and smart pointers"? I have no rust experience so far. Magic compiler support for such primitives is something I usually very much, really strongly dislike, it was always my experience that it is the wrong point of abstraction because it just reduces the design state so much. But then you need good support for inlining the relevant parts of the language, w…

If containers, control flow and so forth are expressible as library code you get a simpler compiler and stuff determined users can reasonably debug, modify, replace. It means you have to improve the core language enough to implement them and/or have magic compiler intrinsics which are only intended for use by that library.

If you implement these things in the compiler (open code means emit the implementation inline as you go, can also emit calls to the compiler runtime which is roughly similar to library code that the compiler ships and knows lots about) then users need to hack the compiler to change them.

However, if the structures are in the compiler, and you've done things like encode them directly in the AST, the compiler has a better chance of emitting useful diagnostics for them and of optimising them at the semantic level of the container.

C++ goes with library code supported by compiler intrinsics, and a common developer experience is compilation errors referring to iterators some distance into the library code. It also can't sanely do things like call reserve on a vector outside of a loop, because by the time it's ready to optimise things it's holding raw pointers with mangled names, not a hashmap instance.

Conventional wisdom is to put containers in the stdlib. D has some support in the compiler. I'm starting to think this is one where conventional wisdom has got it wrong.

Re: The Rust I wanted had no future

#137

Post by kryptiskt »

pmontra wrote: post #84

> The priorities I had while working on the language are broadly not the revealed priorities of the community that's developed around the language in the years since Isn't that a matter of self selection? A language which developed around those priorities would have a community sharing those priorities now. The point is if that community would be as large as the current one, larger, smaller.

It's not really mentioned in the post, but one thing Rust had since fairly early on was a use case, it was used to build a browser engine. As I remember it from the time, the feedback from Servo development tended to pull Rust in a more performance-oriented direction.

Re: The Rust I wanted had no future

#138

Post by [deleted] »

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…

[deleted]

Re: The Rust I wanted had no future

#139

Post by phi-go »

JonChesterfield wrote: post #130
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…

Interesting that tail calls are mentioned and implied to never come to Rust. I agree with your assessment and actually there is a RFC[1] in the works to support them. (Note that while I'm the author, this RFC is definitely a community effort.)

[1] https://github.com/rust-lang/rfcs/pull/3407

Re: The Rust I wanted had no future

#140

Post by littlestymaar »

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…

> (i.e. function coloring)

I really wish people stopped using this concept, especially in the context of Rust because the `async fn`/“regular function” split is strictly equivalent to the `try_something()`/`something()` split (the first one being failible and returning a `Result` in case of failure). `Result`s and `Option`s are coloring the stack in exactly the same way a `Future` does (and `async` is pure syntactic sugar on top of future).

So, someone may like exceptions and green threads more than `Result` and `async` (and this is a completely valid PoV, even though I personnaly like the explicitness better), but thinking `async` is somehow special is just a conceptual mistake.

BTW, in the original blog post the “red” functions were actually functions with a callback parameter, which is actually very different.

Post reply on HN