<'_>)
How come it is in demand?
Cool book though.
The underscore could've been a name if the name mattered, which would be required in many languages. Rewriting it to <'something>) may help readability (but risks introducing bugs later by reusing `something`).
Many C-derived languages are full of symbol soup. A group like <?,?>[]) can happen all over Java, for instance. Many of these languages have mixes of * and & all over the place, C++ has . and -> for some reason, making for some pretty unreadable soup. The biggest additions I think Rust added to the mix was ' for lifetimes (a concept missing from most languages, unfortunately), ! for a macro call (macro invocations in many other languages aren't marked at all, leaving the dev to figure out if println is a method or a macro), and ? to bubble up errors. The last one could've been a keyword (like try in Zig) but I'm not sure if it makes the code much more readable that way.
If you know other programming languages, the symbols themselves fall into place quite quickly. I know what <'_> does in Rust for the same reason I know what <T, R> T does in Java, while a beginner or someone who hasn't learned past Java 6 may struggle to read the code. Out of all the hurdles a beginning Rust programmer will face, the symbols are probably your least concern.
As for books, the Rust book on the Rust website is kept up to date pretty well. There are books for programmers coming from various other languages as well.
The language itself hasn't changed much these past few years. The standard library gets extended with new features, but a book a few years old will teach you Rust just fine.
In many cases, changes to the language have been things like "the compiler no longer treats this as broken (because it isn't)" and "the compiler no longer requires you to write out this long definition because it can figure that stuff out itself". I'd recommend running a tool called "clippy" in your IDE or on the command line, if you can leverage a modern language feature for better legibility, clippy will usually suggest it.
Can you do a lot better? I don't think so and it wouldn't help that much.
The truth is that most of the time we want to rely on some inferred lifetime annotations, but will obviously need an escape hatch from time to time.
Rust doesn't waste a lot of typing around the annotations, but if you were to improve Rust, you'd improve the implicit inference, not the syntax for being explicit.
I think Rust could do a lot better inferring lifetimes if the compiler would be allowed to peek into called function instead of stopping at the function signature - e.g. if it had a complete picture of the control flow of the entire code base (maybe be up to a point that manual lifetime annotations could be completely eliminated?).
IMHO it's not unrealistic to treat the entire codebase as a single compilation unit, Zig does this for instance - it just doesn't do much so far with the additional information that could be gained.
Rust has similar rules about type inference (of which lifetimes are a subset) at the function level as well. I think this was a lesson learned the hard way by Haskell, which does allow whole-program type inference, and how programmers working in it quickly learned you really want to specify the types at the function level anyway
Hmm, but wouldn't that already be the case since the manual lifetime annotation must match what the function actually does? E.g. I would expect compiler errors if the 'internal' lifetime details of a function no longer match its manual lifetime annotations (is it actually possible to create incorrect lifetime annoatations in Rust without the compiler noticing?)
Higher compile times would be bad of course, but I wonder how much it would add in practice. It's a similar problem as LTO, just earlier in the compile process. E.g. maybe some time consuming tasks can be moved around instead of added on top.
In safe rust, no.
Full inference is one of those things that seems like a no brainer, but there are a number of other more subtle tradeoffs that make it a not great idea. Speed was already mentioned, but it’s really downstream from tractibility, IMHO. That is, lifetime checking is effectively instantaneous today, and that’s because you only need to confirm that the body matches the signature, which is a very small and local problem. Once you allow inference, you end up needing to check not just the body, but also the bodies of every function called in your body, recursively, since you no longer know their signatures up front. We tend to think of compiler passes as “speed” in the sense of it’s nice to have fast compile times, but it also matters in the sense of what can practically be checked in a reasonable time. The cheaper a check, the more checks we can do. Furthermore, remember that Rust supports separate compilation, which is a major hindrance to full program analysis, which is what you need to truly infer lifetimes.
Beyond complexity arguments, there’s also more practical ones: error messages would get way worse. More valid programs would be rejected if the inference can’t figure out an answer. Semver is harder to maintain, because a change in the body now changes the signature, and you may break your callers in ways you don’t realize at first.
Another thing I’ll point out is that TypeScript does full program inference and while type checking performance is a huge problem, it does a pretty good job. That obviously doesn’t necessarily map to Rust and the problem domain it’s solving (& maybe TS codebases naturally are smaller than Rust) but just putting that out there. Rust has made certain opinionated choices but that doesn’t mean that other choices weren’t equally valid and available. SemVer is easily solvable - don’t allow inference for pub APIs exported from the crate which also neatly largely solves the locality issue.
> I’ll point out is that TypeScript does full program inference
Do you have a citation for this? I don't believe this is the case, though I could be wrong. I actually spent some time trying to find a definitive answer here and couldn't. That said,
> Rust has made certain opinionated choices but that doesn’t mean that other choices weren’t equally valid and available.
This is true for sure; for example, TypeScript is deliberately unsound, and that's a great choice for it, but does not make sense for Rust.
> SemVer is easily solvable - don’t allow inference for pub APIs exported from the crate which also neatly largely solves the locality issue.
It helps with locality but doesn't solve it, as it's still a non-local analysis. The same problems fundamentally remain, even if the scope is a bit reduced.
> Do you have a citation for this? I don't believe this is the case, though I could be wrong. I actually spent some time trying to find a definitive answer here and couldn't. That said,
No and thinking about it more I'm not sure about the specific requirements that constitutes full program inference so it's possible it's not. However, I do know that it infers the return type signatures of functions from the bodies.
> This is true for sure; for example, TypeScript is deliberately unsound, and that's a great choice for it, but does not make sense for Rust
Sure but I think we can agree that the deliberately unsound is for ergonomic and pragmatic compatibility with JS, not because of the choice of inference.
I'm not arguing Rust should change it's inference strategy. Of all the things, I'd rate this quite low on my wishlist of "what would I change about how Rust works if I could wave a magic wand".
See that the definition of Group is tying those together. Instead, you can split them apart and maybe use HRTB to ensure the closure _must_ be able to treat the lifetime as fresh? But then you’ll probably have other issues…
… which can largely be circumvented simply by pinning, in your reduced example, which probably doesn’t retain enough detail.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
My suggestion to avoid the pain? Use ArcStr.
The key is to isolate the unsafe code and test it directly, so you're not really doing it with whole programs. At least that's what I try to do. Anyway, was just curious!
(I don't have anything to say about the specific code here that cmr didn't already say)
> Sure but I think we can agree that the deliberately unsound is for ergonomic and pragmatic compatibility with JS,
Oh absolutely, all I meant was that because they're starting from different goals, they can make different choices.
There is something about how the brain is wired, that using ' for lifetime, just triggers the wrong immediate response to it.
Something like this would look so much nicer IMHO [$_], compared to this <'_>.
I never get this take. Array indexing is done with []. This would just confuse the hell out of me.
C is not full of symbol soup though.
It is more full of symbol soup than Pascal or Modula 2, and back in the day when C was taking over other such languages, there were lots of complaints about C's syntax being like "line noise" and whatnot.
Rust takes it to a whole new level though.
Math is also symbol soup. But those symbols mean things and they’ve usually been designed to compose nicely. Mathematicians using symbols—just like writers using alphabets—are able to use those symbols to concisely and precisely convey complicated concepts to one another.
I guess my point is that symbols shouldn’t be looked at as inherently a positive or negative thing. Are they clear and unambiguous in their use? Do they map clearly onto coherent concepts? When you need to compose them, is it straightforward and obvious to do so?
I have always used the "international" version of the US English keyboard on Linux.
And I can enter all common symbols pressing altgr or altgr-shift. I also use right Ctrl as a compose key fore more. I would be hard pressed remembering what combo to press, after years it's just muscle memory.
But how do you find out what layout and what compose key does what? Good luck. It's as documented as gesture and hidden menus on iOS and MacOS. sigh.
Like APL, it has a set of well-chosen symbols, but each symbol has an english name you can type just as you would a function name in another language, and it's automatically converted to the symbol when you run it.
Perhaps HRTBs and Fn traits, or double turbofish generics. I really cannot remember sadly.
Anyways, I will try to look for the code, it is somewhere in my comment history but I have left way too many comments, so no promises.
foo(bar()?)?
if a, err := bar() {
return nil, err
}
if b, err := foo() {
return nil, err
}
let a = bar()?;
let b = foo()?;Edit: actually, it was someone else who said this: "Human brain has a funny way of learning how to turn off the noise and focus on what really matters.".
I have fixed (and frankly, caused) many bugs in golang code where people’s brains “turned off the noise” and filtered out the copypasta’d error handling, which overwrote the wrong variable name or didn’t actually bubble up the error or actually had subtly wrong logic in the conditional part which was obscured by the noise.
Frankly, learning to ignore that 80% of your code is redundant noise feels to me like a symptom of Stockholm syndrome more than anything else.
One symbol to replace three lines of identical boilerplate is no less explicit and dramatically clearer.
fn foo() -> Result<(),FooError>
bar()?
fn bar() -> Result<(),BarError>
nil, err
It’s not like three lines of error handling copypasta is some optimal amount. If golang required ten lines of boilerplate error handling, you’d still have just as many people arguing in favor of it because they “like it to be explicit” when it reality it’s verbose and the real underlying argument is that it’s what they’ve grown accustomed to. `?` is no less explicit, but it is less unnecessarily verbose.
I just don't understand why one may take maths of all things as a positive example of something readable, when it's widely known to be utterly inscrutable to most humans on earth and even so many papers have differing conventions, using the same symbol for sometimes widely different or sometimes barely different things
It's a curly-brace language with some solid decisions (e.g. default immutability) that produces static binaries and without a need for a virtual machine, while making some guarantees that eliminate a swathe of possible bug types at compile time.
As others note, the symbol soup is something you learn to read fluently and isn't worth getting hung up on.
Basically it occupies something of a sweet spot in the power/useability/safety space and got a decent PR shove by coming out of Mozilla back when they were the cool kids. I like it a lot. YMMV.
Most people will conk out if you start talking about how your language has "algebraic data types." But if you rephrase that as "we let you put payloads in your enum," well, that piques people's interest. It certainly worked on me.
What does this mean? Not Python?
They often share other syntax similarities but not one particular common set across all of them.
> How come is it in demand?
Because there's a lot more to the language than just those not-really-unfamiliar symbols
Because it's a complicated language for building extremely low level things, when you have no other choice. IMO it's not the right tool for high level stuff (even though it does have some stuff which higher level languages should probably borrow).
The only other language that directly competes with Rust IMO is C++, which is equally full of symbol soup.
I thought that for a long time. But as time passes and I spend more time in languages like Typescript (Semi-Type Script more accurately) and Swift the more I yearn for Rust.
It is not the right tool for scripting, true.
It's also good to remind people that these things were borrowed by Rust from other languages too. Primarily the ML family of languages.
IMO there's still need for a higher level Rust where you don't need that last 20% of the performance and control.
Some people say that OCaml is the high level rust, but I think it's got a lot of gaps which rust doesn't.
Nice language otherwise.
My opinion is that in Rust you have to make decisions on certain things which are take n for you by the garbage collector in other languages.
Should you store a reference or value in your struct? You can't just change it without modifying other places. I understand that this gives you the control to get the final 20% of performance in certain places but it's still lower level than other languages.
You could say just spam Arc everywhere and forget about references, but that itself is a low level decision that you make.
Split ←((⊢-˜+`׬)∘=⊔⊢)
input2←' 'Split¨•file.Lines "../2020/2.txt" # change string to your file location
Day2←{
f←⊑{(⊑)+↕1+|-´}‿{-1} # Select the [I]ndex generator [F]unction
I←{F •BQN¨ '-' Split ⊑} # [I]ndices used to determine if the
C←{⊑1⊑} # [C]haracter appears in the
P←{⊑⌽} # [P]assword either
Part1←(I∊˜·+´C= P)¨ # a given number of times
Part2←(1= ·+´C=I⊏P)¨ # or at one of a pair of indices
⊑+´◶Part1‿Part2
}
•Show { Day2 input2}¨↕2Early Rust had other sorts of things that a lot of folks would consider readability problems unrelated to symbols too: no keyword was allowed to be over five characters, so return was ret, continue was cont, etc.
Can you think of such cases?
If those are the case, well, I can construct something, but it's not something I've used directly. Four isn't unheard of if you're going by those rules, but five is a bit extra.
You cited )?)?; a little while ago, I personally would write this code like the final example over here: https://news.ycombinator.com/item?id=43234284
I don't see it in other fields, at all.
What do you mean?
But almost the entirety of Computer Science is based on abstractions because they're helpful to "dumb down" some details that aren't super-important for our day-to-day work. E.g., writing TCP protocols directly is Assembly would be too fine-grained detail for most people's usual work, and using some existing abstraction is "good enough" virtually all of the time (even though we might be able to optimize things for our use-cases if we did drop down to that level)
There exists programming work where fiddling with lifetimes is just too fiddly to be worthwhile (e.g., web development, probably is more than fine using a good ol' garbage collected language). This isn't about "dumbing down" anything, it's about refocusing on what's important for the job you're doing.
If you just want a better c/c++ afaik that's zig, but I have no experience with it
I been learning Rust off and on and I have a more serious need to get up to speed with it but I’m unsure where it’s best to start in this way
1. The Rust Book (Free) - https://doc.rust-lang.org/book/
2. Rust by Example (Free) - https://doc.rust-lang.org/rust-by-example/
3. Rust Atomics and Locks - https://marabos.nl/atomics/
4. Rust in Action - https://www.rustinaction.com/
5. Rust for Rustaceans - https://rust-for-rustaceans.com/
Also Jon Gjengset's channel is immensely valuable: https://www.youtube.com/c/JonGjengset
I found it more approachable than some of the other Rust books and highly recommend it as a first Rust book.
Yeah Rust atomics and locks is essential if you truly want to understand low-level concurrency. But you might have to also refer to the C++ std::atomics reference [1] to get a complete idea. It took me a while to grasp those concepts.
Zig seems to follow the C tradition, and Rust C++.
They mean the domain that Rust is in.
Before Rust there was only C or C++ for real time programming. C++ was an experiment (wildly successful IMO when I left it in 2001) trying to address the shortcomings of C. It turned out that too much of everything was in C++, long compile times, a manual several inches thick, huge executables. Some experiments turned out not to be a good idea (exceptions, multiple inheritance, inheritance from concrete classes....)
Rust is a successor in that sense. It draws on the lessons of C++ and functional programming.
I hope I live long enough to see the next language in this sequence that learns form the mistakes of Rust (there are a few, and it will take some more years to find them all)
Anyways, I dislike C++, it is too bloated and I would rather just use C.
Also there have been alternatives to C and C++, even if they tend to be ignored by most folks.
That being said, I can't work with std::variant, and God knows I tried to like it. Rust's enums look a lot nicer by comparison, haven't had enough experience to run into potential rough edges which I'm sure are there.
Rust's defining feature is its borrow checker, which solves a similar problem as move semantics, but is more powerful and has saner defaults.
If you really only want a better C/C++, use C++ and amp up your use of safer types (or consider D).
In the end, language stability isn't as important as it used to be, people are quite used to fixing their code when upgrading dependencies to a new major version for instance.
I haven't yet seen something that would make me have to consider Zig, regardless of my personal opinion, like other languages that have grown to become unavoidable.
I love Rust, I am a devotee and an advocate.
But the packaging system, more importantly the lack of a comprehensive system crate, is one of the greatest weaknesses of Rust.
A simple programme can pull in hundreds of crates from goodness knows where and by Dog knows who, for all sorts of uncertainties.
There are work arounds, but they eat up time that could be used far more productively
I developed some muscles I didn't know I had.
Seriously though, I immediately parse it as "generic bounds containing the erased lifetime, close parenthesis". It's not a big deal.
And of all the critics one might have on Rust (or any other programming language), "too much symbols" appear like a weak one.