What a wonderfully self aware and honest piece of writing.
The Rust I wanted had no future
101–110 of 523 posts
Re: The Rust I wanted had no future
#102Earlier quoted context omitted.
I ran into this case yesterday, for some cases there are warnings now. In this case I used ".div_ceil(...)" from from the Num [0] crate. (some_integer).div_ceil(&2) ^^^^^^^^ = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior! = note: for more information, see issue #48919 = help: call with fully qualified syntax `num::Integer::div_ceil(...)` t…
This warning happens during the time the method is added to libstd but is still unstable.
Given that all important codebases should have CI that rejects warnings and runs clippy I would say it is acceptable.
Re: The Rust I wanted had no future
#103Very 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 too would have loved something more towards ML than C++ I stopped paying attention to the language around 2012-2013 or so when the direction clearly steered towards the latter. You may want to check https://austral-lang.org/ out.
I was about to ask if there's any "Rust by ML" languages out there. Thank you.
Re: The Rust I wanted had no future
#104> 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…
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 (except in case of stack overflows / performance)
Re: The Rust I wanted had no future
#105I think Rust is somewhat cumbersome as a language, but I also think the right tradeoffs were made. There are far fewer and far worse competitors in the high-performance space than in the general purpose space.
Re: The Rust I wanted had no future
#106Earlier quoted context omitted.
One highlight from the article: > Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. Very much this! > I wanted (and got part way into building) a first class module system…
I often felt that being canonical was a pretty big advantage of traits. For example if you use first-class modules then every time you want a sort or a binary search tree you need to specify the choice of comparison operator for the elements. And a data structure for a search tree must somehow encode this in the type system so eg you can’t merge two trees with the same key type but different comparison functions. The…
Most type systems are not full-featured enough to elegantly encode traits/typeclasses or ML modules. You need dependent types, as seen in languages like Agda or Idris. And these in turn are hard to implement in a language with a traditional compile/run phase distinction like Rust: the _full_ feature-set of dependent types is pretty much only available at compile time. (Which is why dependent-typed languages tend to add "program extraction" features, which reintroduce that phase separation in a rather ad-hoc way.)
Re: The Rust I wanted had no future
#107I know we haven’t gotten to that point yet, but I’m curious to see if in my lifetime we get a successor to Rust that fixes a lot of issues people have with the language now.
Re: The Rust I wanted had no future
#108Earlier 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…
It’s a language feature in the sense that it determines which programs are viable in the language. This is similar to garbage collection. In principle, you never have to explicitly free memory. Given infinite memory, garbage collection would only be an optimization. But since memory is finite, it becomes a language feature. Without garbage collection, programs that don’t free their unused memory will typically run out of memory sooner or later, similarly to how a tail-calling program will run out of stack space if the language doesn’t support it.
Re: The Rust I wanted had no future
#109On 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
The correct (but hard) way to prevent overflow-related bugs would be to insist on the compiler being able to prove that no overflow can occur. Basically the same thing you do in your head to convince yourself that the program is correct and won’t overflow, only in a more formally rigorous fashion. Modulo semantics by itself doesn’t prevent bugs.
Rust has an optional clippy lint that will warn/forbid all basic arithmetic that might over/underflow, forcing you to use dedicated methods with explicit behaviour instead.
It's very annoying , but I use it in code where this is critical.
Re: The Rust I wanted had no future
#110Over 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 it's another. There are now nearly as many Rusts as C++s.
If I return to any domains where Rust would be relevant, I'd probably now opt for Zig or equivalent.