FWIW, this is how you express conditional arguments / struct fields in Rust. The condition has to encompass the name as well as the type, not just the type as was first attempted.
I feel like Rust has definitely obliterated its complexity budget in unfortunate ways. Every day somebody comes to the sled discord chat with confusion over some async interaction. The fixation on async-await, despite it slowing down almost every real-world workload it is applied to, and despite it adding additional bug classes and compiler errors that simply don’t exist unless you start using it, has been particularly detrimental to the ecosystem. Sure, the async ecosystem is a “thriving subcommunity” but it’s thriving in the Kuhnian sense where a field must be sufficiently problematic to warrant collaboration. There’s no if-statement community anymore because they tend to work and be reasonably well understood. With async-await, I observed that the problematic space of the overall community shifted a bit from addressing external issues through memory safety bug class mitigation to generally coping with internal issues encountered due to some future not executing as assumed.
The problematic space of a community is a nice lens to think about in general. It is always in-flux with the shifting userbase and their goals. What do people talk about? What are people using it for? As the problematic space shifts, at best it can introduce the community to new ideas, but there’s also always an aspect of it that causes mourning over what it once represented. Most of my friends who I’ve met through Rust have taken steps to cut interactions with “the Rust community” down to an absolute minimum due to it tending to produce a feeling of alienation over time. I think this is pretty normal.
I’m going to keep using Rust to build my database in and other things that need to go very fast, but I see communities like Zig’s as being in some ways more aligned with the problematic spaces I enjoy geeking out with in conversations. I’m also thinking about getting a lot more involved in Erlang since I realized I haven’t felt that kind of problem space overlap in any language community since I stopped using it.
I was surprised to see the Rust community jump on the async-await bandwagon, because it was clear from the beginning it’s a bandwagon. When building a stable platform (e.g. a language) you wait for the current fashion to crest and fall, so you can hear the other side of the story – the people who used it in anger, and discovered what the strengths and weaknesses really are. Rust unwisely didn’t do that.
I will note though that the weaknesses of the async-await model were apparent right from the beginning, and yet here we are. A lesson for future languages.
This hits me particularly hard because I had experienced a lot of nearly-identical pain around async when using various flavors of Scala futures for a few years before picking up Rust in 2014. I went to the very first Rust conference, Rust Camp in 2015 at Berkeley, and described a lot of the pain points that had caused significant issues in the Scala community to several of the people directly working on the core async functionality in Rust. Over the years I’ve had lots of personal conversations with many of the people involved, hoping that sharing my experiences would somehow encourage others to avoid well-known painful paths. This overall experience has caused me to learn a lot about human psychology - especially our inability to avoid problems when there are positive social feedback loops that lead to those problems. It makes me really pessimistic about climate apocalypse and rising authoritarianism leading us to war and genocides, and the importance of taking months and years away from work to enjoy life for as long as it is possible to do so.
The content of ideas does not matter very much compared to the incredibly powerful drive to exist in a tribe. Later on when I read Kuhn’s Structure of Scientific Revolutions, Feyerabend’s Against Method, and Ian Hacking’s Representing and Intervening, which are ostensibly about the social aspects of science, I was blown away by how strongly their explanations of how science often moves in strange directions that may not actually cause “progress” mapped directly to the experiences I’ve had while watching Rust grow and fail to avoid obvious traps due to the naysayers being drowned out by eager participants in the social process of Making Rust.
I think that Kuhn’s Structure of Scientific Revolutions has the broadest appeal and I think that nearly anyone who has any interaction with open source software will find a tremendous number of connections to their own work. Science’s progressions are described in a way that applies equally to social-technical communities of all kinds. Kuhn is also the most heavily cited thinker in later books on the subject, so by reading his book, you gain deeper access to much of the content of the others, as it is often assumed that you have some familiarity with Kuhn.
You can more or less replace any mention of “paper citation” with “software dependency” without much loss in generality while reading Kuhn. Hacking and Feyerabend are more challenging, but I would recommend them both highly. Feyerabend is a bit more radical and critical, and Hacking zooms out a bit more and talks about a variety of viewpoints, including many perspectives on Kuhn and Feyerabend. Hacking’s writing style is really worth experiencing, even by just skimming something random by him, by anyone who writes about deep subjects. I find his writing to be enviably clear, although sometimes he leans a bit into sarcasm in a way that I’ve been put off by.
If you don’t mind, what’s an example of async/await pain that’s common among languages and not to do with how Rust uniquely works? I ask because I’ve had a good time with async/await, but in plainer, application-level languages.
The classic “what color is your function” blog post describes what is, I think, such a pain? You have to choose in your API whether a function can block or not, and it doesn’t compose well.
I read that one, and I took their point. All this tends to make me wonder if Swift (roughly, Rust minus borrow checker plus Apple backing) is doing the right thing by working on async/await now.
But so far I don’t mind function coloring as I use it daily in TypeScript. In my experience, functions that need to be async tend to be the most major steps of work. The incoming network request is async, the API call it makes is async, and then all subsequent parsing and page rendering aren’t async, but can be if I like.
Maybe, like another commenter said, whether async/await is a net positive has more to do with adapting the language to a domain that isn’t otherwise its strong suit.
Indeed this is an interesting difference at least in presentation. Usually, async/await provides sugar for an existing concurrency type like Promise or Task. It doesn’t provide the concurrency in the first place. Function colors are then a tradeoff for hiding the type, letting you think about the task and read it just like plain synchronous code. You retain the option to call without await, such that colors are not totally restrictive, and sometimes you want to use the type by hand; think Promise.all([…]).
Zig seems like it might provide all these same benefits by another method, but it’s hard to tell without trying it. I also can’t tell yet if the async frame type is sugared in by the call, or by the function definition. It seems like it’s a sort of generic, where the nature of the call will specialize it all the way down. If so, neat!
Well, I think that async/await was a great thing for javascript, and generally it seems to work well in languages that have poor threading support. But Rust has great threading support, and Rust’s future-based strategy aimed from the beginning at copying Scala’s approach. A few loud research-oriented voices in the Rust community said “we think Scala’s approach looks great” and it drowned out the chorus of non-academic users of Scala who had spent years of dealing with frustrating compilation issues and issues where different future implementations were incompatible with each other and overall lots of tribalism that ended up repeating in a similar way in the Rust async/await timeline.
I am somewhat surprised that you say Rust’s futures are modeled after Scala’s. I assume the ones that ended up in the standard library. As for commonalities: They also offer combinators on top of a common futures trait and you need explicit support in libraries - that’s pretty much all that is similar to Rust’s.
In Scala, futures were annoying because exceptions and meaningless stacktraces. In Rust, you get the right stacktraces and error propagation.
In Rust, Futures sucked for me due to error conversions and borrowing being basically unsupported until async await. Now they are still annoying because of ecosystem split (sync vs various partially compatible async).
The mentioned problem of competing libraries is basically unpreventable in fields without wide consensus and would have happened with ANY future alternative. If you get humans to agree on sensible solutions and not fight about irrelevant details, you are a wizard.
Where I agree is that it was super risky to spend language complexity budget on async/await, even though solving the underlying generator/state machine problem felt like a good priority. While async await feels a bit to special-cased and hacky to be part of the language… It could be worse. If we find a better solution for async in Rust, we wouldn’t have to teach the current way anymore.
Other solutions would just have different pros and cons. E.g. go’s or zig’s approach seemed the solution even deeper into the language with the pro of setting a somewhat universal standard for the language.
It was emulating Finagle from the beginning: https://medium.com/@carllerche/announcing-tokio-df6bb4ddb34 but then the decision to push so much additional complexity into the language itself so that people could have an easier time writing strictly worse systems was just baffling.
Having worked in Finagle for a few years before that, I tried to encourage some of the folks to aim for something lighter weight since the subset of Finagle users who felt happy about its high complexity seemed to be the ones who went to work at Twitter where the complexity was justified, but it seemed like most of the community was pretty relieved to switch to Akka which didn’t cause so much type noise once it was available.
I don’t expect humans not to fragment now, but over time I’ve learned that it’s a much more irrational process than I had maybe believed in 2014. Mostly I’ve been disappointed about being unable to communicate with what was a tiny community about something that I felt like I had a lot of experience with and could help other people avoid pain around, but nevertheless watch it bloom into a huge crappy thing that now comes back into my life every day even when I try to ignore it by just using a different feature set in my own stuff.
I hope you will get a reply by someone with more Rust experience than me, but I imagine that the primary problem is that even if you don’t have to manually free memory in Rust, you still have to think about where the memory comes from, which tends to make lifetime management more complicated, requiring to occasionally forcefully move things unto the heap (Box) and also use identity semantics (Pin), and so all of this contributes to having to deal with a lot of additional complexity to bake into the application the extra dynamicism that async/await enables, while still maintaining the safety assurances of the borrow checker.
Normally, in higher level languages you don’t ever get to decide where the memory comes from, so this is a design dimension that you never get to explore.
I’m curious if you stuck around in Scala or pay attention to what’s going on now because I think it has one of the best stories when it comes to managing concurrency. Zio, Cats Effect, Monix, fs2 and Akka all have different goals and trade offs but the old problem of Future is easily avoided
I was surprised to see the Rust community jump on the async-await bandwagon, because it was clear from the beginning it’s a bandwagon.
I’m not surprised. I don’t know how async/await works exactly, but it definitely has a clear use case. I once implemented a 3-way handshake in C. There was some crypto underneath, but the idea was, from the server’s point of view was to receive a first message, respond, then wait for the reply. Once the reply comes and is validated the handshake is complete. (The crypto details were handled by a library.)
Even that simple handshake was a pain in the butt to handle in C. Every time the server gets a new message, it needs to either spawn a new state machine, or dispatch it to an existing one. Then the state machine can do something, suspend, and wait for a new message. Note that it can go on after the handshake, as part of normal network communication.
That state machine business is cumbersome and error prone, I don’t want to deal with it. The programming model I want is blocking I/O with threads. The efficiency model I want is async I/O. So having a language construct that easily lets me suspend & resume execution at will is very enticing, and I would jump to anything that gives me that —at least until I know better, which I currently don’t.
I’d even go further: given the performance of our machines (high latencies and high throughputs), I believe non-blocking I/O at every level is the only reasonable way forward. Not just for networking, but for disk I/O, filling graphics card buffers, everything. Language support for this is becoming as critical as generics themselves. We laughed “lol no generics” at Go, but now I do believe it is time to start laughing “lol no async I/O” as well. The problem now is to figure out how to do it. Current solutions don’t seem to be perfect (though there may be one I’m not aware of).
The whole thing with async I/O is that process creation is too slow, and then thread creation was too slow, and some might even consider coroutine creation too slow [1]. It appears that concerns that formerly were of the kernel (managing I/O among tasks; scheduling tasks) are now being pushed out to userland. Is this the direction we really want to go?
[1] I use coroutines in Lua to manage async I/O and I think it’s fine. It makes the code look like non-blocking, but it’s not.
I don’t think it’s unreasonable to think that the kernel should have as few concerns as possible. It’s a singleton, it doesn’t run with the benefit of memory protection, and its internal APIs aren’t as stable as the ones it provides to userland.
… and, yes, I think a lot of async/await work is LARPing. But that’s because a lot of benchmark-oriented development is LARPing, and probably isn’t special to async/await specifically.
I’m not sure what you’re getting at. I want async I/O to avoid process creation and thread creation and context switches, and even scheduling to some extent. What I want is one thread per core, and short tasks being sent to them. No process creation, no thread creation, no context switching. Just jump the instruction pointer to the relevant task, and return to the caller when it’s done.
And when the task needs to, say, read from the disk, then it should do so asynchronously: suspend execution, return to the caller, wait for the response to come back, and when it does resume execution. It can be done explicitly with message passing, but that’s excruciating. A programming model where I can kinda pretend the call is blocking (but in fact we’re yielding to the caller) is much nicer, and I believe very fast.
Agreed. I always told people that async/await will be just as popular as Java’s synchronized a few years down the road. Some were surprised, some were offended, but sometimes reality is uncomfortable.
Thank you for sharing, Zig has been much more conservative than Rust in terms of complexity but we too have splurged a good chunk of the budget on async/await. Based on my experience producing introductory materials for Zig, async/await is by far the hardest thing to explain and probably is going to be my biggest challenge to tackle for 2021. (that said, it’s continuations, these things are confusing by nature)
On the upside
despite it slowing down almost every real-world workload it is applied to
This is hopefully not going to be a problem in our case. Part of the complexity of async/await in Zig is that a single library implementation can be used in both blocking and evented mode, so in the end it should never be the case that you can only find an async version of a client library, assuming authors are willing to do the work, but even if not, support can be added incrementally by contributors interested in having their use case supported.
I feel like Rust has definitely obliterated its complexity budget in unfortunate ways.
I remember the time I asked one of the more well-known Rust proponents “so you think adding features improves a language” and he said “yes”. So it was pretty clear to me early on that Rust would join the feature death march of C++, C#, …
Rust has many language features and they’re all largely disjoint from each other, so knowing some doesn’t help me guess the others.
That’s so painfully true.
For instance, it has different syntax for struct creation and function calls, their poor syntax choices also mean that structs/functions won’t get default values any time soon.
; is mandatory (what is this, 1980?), but you can leave out , at the end.
The severe design mistake of using <> for generics also means you have to learn 4 different syntax variations, and when to use them.
The whole module stuff is way too complex and only makes sense if you programmed in C before.
I have basically given up on getting to know the intricacies, and just let IntelliJ handle uses.
Super weird that both if and switch exist.
Most of my friends who I’ve met through Rust have taken steps to cut interactions with “the Rust community” down to an absolute minimum due to it tending to produce a feeling of alienation over time.
Yes, that’s my experience too. I have some (rather popular) projects on GitHub that I archive from time to time to not having to deal with Rust people. There are some incredibly toxic ones, which seem to be – for whatever reason – close to some “core” Rust people, so they can do whatever the hell they like.
For instance, it has different syntax for struct creation and function calls
Perhaps they are trying to avoid the C++ thing where you can’t tell whether foo(bar) is struct creation or a function call without knowing what foo is?
The whole module stuff is way too complex and only makes sense if you programmed in C before. I have basically given up on getting to know the intricacies, and just let IntelliJ handle uses.
It only makes sense to someone who has programmed in C++. C’s “module” system is far simpler and easier to grok.
Super weird that both if and switch exist.
Would you have preferred
match condition() {
true => {
},
false => {
},
}
I think that syntax is clunky when you start needing else if.
Perhaps they are trying to avoid the C++ thing where you can’t tell whether foo(bar) is struct creation or a function call without knowing what foo is?
Why wouldn’t you be able to tell?
Even if that was the issue (it isn’t), that’s not the problem C++ has – it’s that foo also could be 3 dozen other things.
Would you have preferred […]
No, I prefer having one unified construct that can deal with both usecases reasonably well.
Let the IDE color things accordingly. Solved problem.
The problem of course is for the writer of the IDE :)
Constructs like these in C++ make it not only harder for humans to parse the code, but for compilers as well. This turns into real-world performance decreases which are avoided in other languages.
I’m currently in the process of implementing it, but I think this is a good intro to my plans.
That’s interesting, but I think there’s a conflict with Rust’s goal of being a systems-level programming language. Part of that is having primitives which map reasonably well onto things that the compiler can translate into machine code. Part of the reason that languages like C have both if and switch is because switch statements of the correct form may be translated into an indirect jump instead of repeated branches. Of course, a Sufficiently Smart Compiler could optimize this even in the if case, but it is very easy to write code which is not optimizable in such a way. I think there is value to both humans and computers in having separate constructs for arbitrary conditionals and for equality. It helps separate intent and provides some good optimization hints.
Another reason why this exists is for exhaustiveness checks. Languages with switch can check that you handle all cases of an enum.
The other half of this is that Rust is the bastard child of ML and C++. ML and C++ both have match/switch, so Rust has one too.
I think you will have a lot of trouble producing good error messages with such a syntax. For example, say someone forgets an = or even both ==s. If your language does false-y and truth-y coercion, then there may be no error at all here. And to the parser, it is not clear at all where the error is. Further, this sort of extension cannot be generalized to one-liners. That is, you cannot unambiguously parse if a == b then c == d then e without line-breaks.
On the subject, in terms of prior-art, verilog allows expressions in its case labels. This allows for some similar syntax constructions (though more limited since functions are not as useful as in regular programming languages).
For instance, it has different syntax for struct creation and function calls, their poor syntax choices also mean that structs/functions won’t get default values any time soon.
This is a good thing. Creating a struct is a meaningfully different operation from calling a function, and there’s no problem with having there be separate syntax for these two separate things.
The Rust standard library provides a Default trait, with examples of how to use it and customize it. I don’t find it at all difficult to work with structs with default values in Rust.
The whole module stuff is way too complex and only makes sense if you programmed in C before. I have basically given up on getting to know the intricacies, and just let IntelliJ handle uses.
I don’t understand this comment at all. Rust’s module system seems fairly similar to module systems in some other languages I’ve used, although I’m having trouble thinking of other languages that allow you to create a module hierarchy within a single file, like you can do with the mod { } keyword (C++ allows nested namespaces I think, but that’s it). I don’t see how knowing C has anything to do with understand Rust modules better. C has no module system at all.
I guess that’s why many Rust devs – immediately after writing a struct – also define a fun to wrap their struct creation? :-)
Creating a struct is a meaningfully different operation from calling a function
It really isn’t.
The Rust standard library provides a Default trait, with examples of how to use it and customize it. I don’t find it at all difficult to work with structs with default values in Rust.
I don’t see how knowing C has anything to do with understand Rust modules better. C has no module system at all.
Rust’s module system only makes sense if you keep in mind that it’s main goal is to produce one big ball of compiled code in the end. In that sense, Rust’s module system is a round-about way to describe which parts of the code end up being part of that big ball.
Struct creation and function calls are quite different. In particular it’s good to have structure syntax that can be mirrored in pattern matching, whereas function call has no equivalent in match.
Multiple modules in one file is also possible in ML/OCaml. Maybe in some Wirth language, though I’m not sure on that one.
it’s main goal is to produce one big ball of compiled code in the end.
What other goal would there be? That’s what 100% of compiled languages aim at… Comparing rust to C which has 0 notion of module is just weird.
Struct creation and function calls are quite different. In particular it’s good to have structure syntax that can be mirrored in pattern matching, whereas function call has no equivalent in match.
In what sense would this be an obstacle? I would expect that a modern language let’s you match on anything that provides the required method/has the right signature. “This is a struct, so you can match on it” feels rather antiquated.
What other goal would there be? That’s what 100% of compiled languages aim at… Comparing rust to C which has 0 notion of module is just weird.
It feels like it was built by someone who never used anything but C in his life, and then went “wouldn’t it be nice if it was clearer than in C which parts of the code contribute to the result?”.
The whole aliasing, reexporting etc. functionality feels like it exists as a replacement for some convenience C macros, and not something one actually would want. I prefer that there is a direct relationship between placing a file somewhere and it ending up in a specific place, without having to wire up everything again with the module system.
There is documented inspiration from OCaml from the rust original creator. The first compiler was even in OCaml, and a lot of names stuck (like Some/None rather than the Haskell Just/Nothing). It also has obvious C++ influences, notably the namespace syntax being :: and <> for generics. The module system most closely reminds me of a mix of OCaml and… python, with special file names (mod.rs, like __init__.py or something like that?), even though it’s much much simpler than OCaml. Again not just “auto wiring” files in is a net benefit (another lesson from OCaml I’d guess, where the build system has to clarify what’s in or out a specific library). It makes build more declarative.
As for the matching: rust doesn’t have active patterns or the scala-style deconstruction. In this context (match against values you can pre-compile pattern-matching very efficiently to decision trees and constant time access to fields by offset. This would be harder to do efficiently with “just call this deconstuct method”. This is more speculation on my side, but it squares with rust’s efficiency concerns.
In almost all languages with mandatory semicolons, they exist to prevent multi-line syntax ambiguities. The designers of Go and Lua both went to great pains to avoid such problems in their language grammars. Unlike, for example, JavaScript. This article about semicolon insertion rules causing ambiguity and unexpected results should help illustrate some of these problems.
Javascript’s problems are solely Javascript’s. If we discarded every concept that was implemented poorly in Javascript, we wouldn’t have many concepts left to program with.
I want semicolon inference done right, simple as that.
That’s not what I’m saying. JavaScript is merely an easy example of some syntax problems that can occur. I merely assume that Rust, which has many more features than Go or Lua, decided not to maintain an unambiguous grammar without using semicolons.
Semicolons are an easy way to eliminate grammar ambiguity for multi-line syntax. For any language. C++ for example would have numerous similar problems without semicolons.
Not needing ; doesn’t mean the grammar is ambiguous.
Of course. Go and Lua are examples of languages designed specifically to avoid ambiguity without semicolons. JavaScript, C++, and Rust were not designed that way. JavaScript happens to be an easy way to illustrate possible problems because it has janky automatic semicolon insertion, whereas C++ and Rust do not.
; is mandatory (what is this, 1980?), but you can leave out , at the end.
Same in Zig? Curious to know Zig rationale for this.
The rationale for semicolons. They make parsing simpler, particularly for multi-line syntax constructs. I have been extremely clear about this the entire time. I have rephrased my thesis multiple times:
In almost all languages with mandatory semicolons, they exist to prevent multi-line syntax ambiguities.
Semicolons are an easy way to eliminate grammar ambiguity for multi-line syntax.
Many underestimate the difficulty of creating a language without semicolons. Go has done so with substantial effort, and maintaining that property has by no means been effortless for them when adding new syntax to the language.
Yeah, you know, maybe we should stop building languages that are so complex that they need explicitly inserted tokens to mark “previous thing ends here”? That’s the point I’m making.
when adding new syntax to the language
Cry me a river. Adding features does not improve a language.
Having a clear syntax where errors don’t occur 15 lines below the missing ) or } (as would unavoidably happen without some separator — trust me, it’s one of OCaml’s big syntax problems for toplevel statements) is a net plus and not bloat.
What language has no semicolon (or another separator, or parenthesis, like lisp) and still has a simple syntax? Even python has ; for same-line statements. Using vertical whitespace as a heuristic for automatic insertion isn’t a win in my book.
I didn’t know. That involves no whitespace/lexer trick at all? I mean, if you flatten a whole file into one line, does it still work? Is it still in LALR(1)/LR(1)/some nice fragment?
The typical problem in this kind of grammar is that, while binding constructs are easy to delimit (var/val/let…), pure sequencing is not. If you have a = 1 b = 2 + 3 c = 4 d = f(a) semicolons make things just simpler for the parser.
Using vertical whitespace as a heuristic for automatic insertion isn’t a win in my book.
I agree completely. I love Lua in particular. You can have zero newlines yet it requires no semicolons, due to its extreme simplicity. Lua has only one ambiguous case: when a line begins with a ( and the previous line ends with a value.
a = b
(f or g)() -- call f, or g when f is nil
Since Lua has no semantic newlines, this is exactly equivalent to:
a = b(f or g)()
The Lua manual thus recommends inserting a ; before any line starting with (.
a = b
;(f or g)()
But I have never needed to do this. And if I did, I would probably write this instead:
a = b
local helpful_explanatory_name = f or g
helpful_explanatory_name()
Also curious, as well as why Zig uses parentheses in ifs etc. I know what I’ll say is lame, but those two things frustrate me when looking at Zig’s code. If I could learn the rationale, it might hopefully at least make those a bit easier for me to accept and get over.
One reason for this choice is to remove the need for a ternary operator without greatly harming ergonomics. Having the parentheses means that the blocks may be made optional which allows for example:
There’s a blog post by Graydon Hoare that I can’t find at the moment, where he enumerates features of Rust he thinks are clear improvements over C/C++ that have nothing to do with the borrow checker. Forcing if statements to always use braces is one of the items on his list; which I completely agree with. It’s annoying that in C/C++, if you want to add an additional line to a block of a brace-less if statement, you have to remember to go back and add the braces; and there have been major security vulnerabilities caused by people forgetting to do this.
I’ve written an expression oriented language, where the parenthesis were optional, and the braces mandatory. I could use the exact same syntactic construct in regular code and in the ternary operator situation.
Another solution is inserting another keyword between the condition and the first branch, as many ML languages do:
I don’t get how that’s worth making everything else ugly. I imagine there’s some larger reason. The parens on ifs really do feel terrible after using go and rust for so long.
If b is actually a parenthesised expression like (2+2), then the whole thing looks like a function call:
const x = if a (2+2) else c
Parsing is no longer enough, you need to notice that a is not a function. Lua has a similar problem with optional semicolon, and chose to interpret such situations as function calls. (Basically, a Lua instruction stops as soon as not doing so would cause a parse error).
Your syntax would make sense in a world of optional semicolons, with a parser (and programmers) ready to handle this ambiguity. With mandatory semicolons however, I would tend to have mandatory curly braces as well:
Ah, Julia gets around this by banning whitespace between the function name and the opening parenthesis, but I know some people would miss that extra spacing.
A minus sign before a number to indicate a negative number is probably recognizable as a negative number to most people in my country. I imagine most would recognise -x as “negative x”, too. Generalising that to other identifiers is not difficult.
An exclamation mark for boolean negation is less well known, but it’s not very difficult to learn. I don’t see why jump-to should fail if you’re using a language server, either.
More generally, people have been using specialist notations for centuries. Some mathematicians get a lot of credit for simply inventing a new way to write an older concept. Maybe we’d be better off with only named function calls, maybe our existing notations are made obsolete by auto-complete, but I am not convinced.
My current feeling is that async/await is the worst way to express concurrency … except for all the other ways.
I have only minor experience with it (in Nim), but a good amount of experience with concurrency. Doing it with explicit threads sends you into a world of pain with mutexes everywhere and deadlocks and race conditions aplenty. For my current C++ project I built an Actor library atop thread pools (or dispatch queues), which works pretty well except that all calls to other actors are one-way so you now need callbacks, which become painful. I’m looking forward to C++ coroutines.
I think people are complaining about the current trend to just always use async for everything. Which ends up complaining about rust having async at all.
This is amazing. I had similar feelings (looking previously at JS/Scala futures) when the the plans for async/await were floating around but decided to suspend my disbelief because of how good previous design decisions in the language were. Do you think there’s some other approach to concurrency fit for a runtime-less language that would have worked better?
My belief is generally that threads as they exist today (not as they existed in 2001 when the C10K problem was written, but nevertheless keeps existing as zombie perf canon that no longer refers to living characteristics) are the nicest choice for the vast majority of use cases, and that Rust-style executor-backed tasks are inappropriate even in the rare cases where M:N pays off in languages like Go or Erlang (pretty much just a small subset of latency-bound load balancers that don’t perform very much CPU work per socket). When you start caring about millions of concurrent tasks, having all of the sources of accidental implicit state and interactions of async tasks is a massive liability.
I think The ADA Ravenscar profile (see chapter 2 for “motivation” which starts at pdf page 7 / marked page 3) and its successful application to safety critical hard real time systems is worth looking at for inspiration. It can be broken down to this set of specific features if you want to dig deeper. ADA has a runtime but I’m kind of ignoring that part of your question since it is suitable for hard real-time. In some ways it reminds me of an attempt to get the program to look like a pretty simple petri net.
I think that message passing and STM are not utilized enough, and when used judiciously they can reduce a lot of risk in concurrent systems. STM can additionally be made wait-free and thus suitable for use in some hard real-time systems.
I think that Send and Sync are amazing primitives, and I only wish I could prove more properties at compile time. The research on session types is cool to look at, and you can get a lot of inspiration about how to encode various interactions safely in the type system from the papers coming out around this. But it can get cumbersome and thus create more risks to the overall engineering effort than it solves if you’re not careful.
A lot of the hard parts of concurrency become a bit easier when we’re able to establish maximum bounds on how concurrent we’re going to be. Threads have a little bit more of a forcing function to keep this complexity minimized due to the fact that spawning is fallible due to often under-configured system thread limits. Having fixed concurrency avoids many sources of bugs and performance issues, and enables a lot of relatively unexplored wait-free algorithmic design space that gets bounded worst-case performance (while still usually being able to attempt a lock-free fast path and only falling back to wait-free when contention picks up). Structured concurrency often leans into this for getting more determinism, and I think this is an area with a lot of great techniques for containing risk.
In the end we just have code and data and risk. It’s best to have a language with forcing functions that pressure us to minimize all of these over time. Languages that let you forget about accruing data and code and risk tend to keep people very busy over time. Friction in some places can be a good thing if it encourages less code, less data, and less risk.
I like rust and I like threads, and do indeed regret that most libraries have been switching to async-only. It’s a lot more complex and almost a new sub-language to learn.
That being said, I don’t see a better technical solution for rust (i.e. no mandatory runtime, no implicit allocations, no compromise on performance) for people who want to manage millions of connections. Sadly a lot of language design is driven by the use case of giant internet companies in the cloud and that’s a problem they have; not sure why anyone else cares. But if you want to do that, threads start getting in the way at 10k threads-ish? Maybe 100k if you tune linux well, but even then the memory overhead and latency are not insignificant, whereas a future can be very tiny.
Ada’s tasks seem awesome but to the best of my knowledge they’re for very limited concurrency (i.e the number of tasks is small, or even fixed beforehand), so it’s not a solution to this particular problem.
Of course async/await in other languages with runtimes is just a bad choice. Python in particular could have gone with “goroutines” (for lack of a better word) like stackless python already had, and avoid a lot of complexity. (How do people still say python is simple?!). At least java’s Loom project is heading in the right direction.
Just like some teenagers enjoy making their slow cars super loud to emulate people who they look up to who drive fast cars, we all make similar aesthetic statements when we program. I think I may write on the internet in a way that attempts to emulate a grumpy grey-beard for similarly aesthetic socially motivated reasons. The actual effect of a program or its maintenance is only a part of our expression while coding. Without thinking about it, we also code as an expression of our social status among other coders. I find myself testing random things with quickcheck, even if they don’t actually matter for anything, because I think of myself as the kind of person who tests more than others. Maybe it’s kind of chicken-and-egg, but I think maybe we all do these things as statements of values - even to ourselves even when nobody else is looking.
Sometimes these costumes tend to work out in terms of the effects they grant us. But the overhead of Rust executors is just perf theater that comes with nasty correctness hazards, and it’s not a good choice beyond prototyping if you’re actually trying to build a system that handles millions of concurrent in-flight bits of work. It locks you into a bunch of default decisions around QoS, low level epoll behavior etc… that will always be suboptimal unless you rewrite a big chunk of the stack yourself, and at that point, the abstraction has lost its value and just adds cycles and cognitive complexity on top of the stack that you’ve already fully tweaked.
The green process abstraction seems to work well enough in Erlang to serve tens of thousands of concurrent connections. Why do you think the async/await abstraction won’t work for Rust? (I understand they are very different solutions to a similar problem.)
Not who you’re asking, but the reason why rust can’t have green threads (as it used to have pre-1.0, and it was scraped), as far as I undertand:
Rust is shooting for C or C++-like levels of performance, with the ability to go pretty close to the metal (or close to whatever C does). This adds some constraints, such as the necessity to support some calling conventions (esp. for C interop), and precludes the use of a GC. I’m also pretty sure the overhead of the probes inserted in Erlang’s bytecode to check for reduction counts in recursive calls would contradict that (in rust they’d also have to be in loops, btw); afaik that’s how Erlang implements its preemptive scheduling of processes. I think Go has split stacks (so that each goroutine takes less stack space) and some probes for preemption, but the costs are real and in particular the C FFI is slower as a result. (saying that as a total non-expert on the topic).
I don’t see why async/await wouldn’t work… since it does; the biggest issues are additional complexity (a very real problem), fragmentation (the ecosystem hasn’t converged yet on a common event loop), and the lack of real preemption which can sometimes cause unfairness. I think Tokio hit some problems on the unfairness side.
The biggest problem with green threads is literally C interop. If you have tiny call stacks, then whenever you call into C you have to make sure there’s enough stack space for it, because the C code you’re calling into doesn’t know how to grow your tiny stack. If you do a lot of C FFI, then you either lose the ability to use small stacks in practice (because every “green” thread winds up making an FFI call and growing its stack) or implementing some complex “stack switching” machinery (where you have a dedicated FFI stack that’s shared between multiple green threads).
Stack probes themselves aren’t that big of a deal. Rust already inserts them sometimes anyway, to avoid stack smashing attacks.
In both cases, you don’t really have zero-overhead C FFI any more, and Rust really wants zero-overhead FFI.
I think Go has split stacks (so that each goroutine takes less stack space)
No they don’t any more. Split Stacks have some really annoying performance cliffs. They instead use movable stacks: when they run out of stack space, they copy it to a larger allocation, a lot like how Vec works, with all the nice “amortized linear” performance patterns that result.
Erlang’s data structures are immutable (and it has much slower single threaded speed).
Erlang doesn’t have threads like Rust does.
That changes everything with regard to concurrency, so you can’t really compare the two. A comparison to Python makes more sense, and Python async has many of the same problems (mutable state, and the need to compose with code and libraries written with other concurrency models)
The fixation on async-await, despite it slowing down almost every real-world workload it is applied to, and despite it adding additional bug classes and compiler errors that simply don’t exist unless you start using it, has been particularly detrimental to the ecosystem.
I’m curious about this perspective. The number of individual threads available on most commodity machines even today is quite low, and if you’re doing anything involving external requests on an incoming-request basis (serializing external APIs, rewriting HTML served by another site, reading from slow disk, etc) and these external requests take anything longer than a few milliseconds (which is mostly anything assuming you have a commodity connection in most parts of the world, or on slower disks), then you are better off with a some form of “async” (or otherwise lightweight concurrent model of execution.) I understand that badly-used synchronization can absolutely tank performance with this many “tasks”, but in situations where synchronization is low (e.g. making remote calls, storing state in a db or separate in-memory cache), performance should be better than threaded execution.
Also, if I reach for Rust I’m deliberately avoiding GC. Go, Python, and Haskell are the languages I tend to reach for if I just want to write code and not think too hard about who owns which portion of data or how exactly the runtime schedules my code. With Rust I’m in it specifically to think about these details and think hard about them. That means I’m more prone to write complicated solutions in Rust, because I wouldn’t reach for Rust if I wanted to write something “simple and obvious”. I suspect a lot of other Rust authors are the same.
The number of individual threads available on most commodity machines even today is quite low
I don’t agree with the premise here. It depends more on the kernel, not the “machine”, and Linux in particular has very good threading performance. You can have 10,000 simultaneous threads on vanilla Linux on a vanilla machine. async may be better for certain specific problems, but that’s not the claim.
Also a pure async model doesn’t let you use all your cores, whereas a pure threading model does. If you really care about performance and utilization, your system will need threads or process level concurrency in some form.
I don’t agree with the premise here. It depends more on the kernel, not the “machine”, and Linux in particular has very good threading performance. You can have 10,000 simultaneous threads on vanilla Linux on a vanilla machine. async may be better for certain specific problems, but that’s not the claim.
I wasn’t rigorous enough in my reply, apologies.
What I meant to say was, the number of cores available on a commodity machine is quite low. Even if you spawn thousands of threads, your actual thread-level parallelism is limited to the # of cores available. If you’re at the point where you need to spawn more kernel threads than there are available cores, then you need to put engineering into determining how many threads to create and when. For IO bound workloads (which I described in my previous post), the typical strategy is to create a thread pool, and to allocate threads from this pool. Thread pools themselves are a solution so that applications don’t saturate available memory with threads and so you don’t overwhelm the kernel with time spent switching threads. At this point, your most granular “unit of concurrency” is each thread in this thread pool. If most of your workload is IO bound, you end up having to play around with your thread pool sizes to ensure that your workload is processed without thread contention on the one hand (too few threads) or up against resource limits (too many threads). You could of course build a more granular scheduler atop these threads, to put threads “to sleep” once they begin to wait on IO, but that is essentially what most async implementations are, just optimizations on “thread-grained” applications. Given that you’re already putting in the work to create thread pools and all of the fiddly logic with locking the pool, pulling out a thread, then locking and putting threads back, it’s not a huge lift to deal with async tasks. Of course if your workload is CPU bound, then these are all silly, as your main limiting resource is not IO but is CPU, so performing work beyond the amount of available CPU you have necessitates queuing.
Moreover the context with which I was saying this is that most Rust async libraries I’ve seen are async because they deal with IO and not CPU, which is what async models are good at.
Thanks for the listed points. What it’s made me realize is that there isn’t really a detailed model which allows us to demonstrate tradeoffs that come with selecting an async model vs a threaded model. Thanks for some food for thought.
My main concern with Rust async is mostly just its immaturity. Forget the code semantics; I have very little actual visibility into Tokio’s (for example) scheduler without reading the code. How does it treat many small jobs? Is starvation a problem, and under what conditions? If I wanted to write a high reliability web service with IO bound logic, I would not want my event loop to starve a long running request that may have to wait longer on IO than a short running request and cause long running requests to timeout and fail. With a threaded model and an understanding of my IO processing latency, I can ensure that I have the correct # of threads available with some simple math and not be afraid of things like starvation because I trust the Linux kernel thread scheduler much more than Tokio’s async scheduler.
I hope I’m not opening any wounds or whacking a bee-hive for asking but… what sort of problematic interactions occur with the Rust community? I follow Rust mostly as an intellectual curiosity and therefor aren’t in deep enough to see the more annoying aspects. When I think of unprofessional language community behavior my mind mostly goes to Rails during the aughts when it was just straight-up hostile towards Java and PHP stuff. Is Rust doing a similar thing to C/C++?
This article so accurately describes my feelings on Rust. Programming in Rust just isn’t fun. I can’t get into a flow with Rust because I write the code that will solve the problem and then spend two hours fighting with the compiler to get it to work; and when it works the code no longer looks like the problem I’m trying to solve.
Knowing one part of Rust doesn’t help me know another part and there are special cases and exceptions everywhere (?Sized, type+lifetime declarations that are 100+ characters long, etc). The module system seems overly complicated. I can’t just solve my problem, I have to wrestle with my language.
Now, I will say that I don’t have a whole lot of Rust experience: maybe 100 hours. But I know that I was able to write good, working, productive code in Go well before 100 hours (and had fun doing it). After just 10 hours of Swift, I was able to do some good stuff.
Rust to me is like C++: just endless features thrown together. If there’s a new kind of problem to solve, Rust seems to fall on the “add a feature to solve it” side of the equation. New features are added so often and so quickly that I feel like I’m trying to learn a moving target.
The comments here and elsewhere about the community also hold true: more times than I care to remember, my dislike of some part of the language is seen as a personal failing rather than a potential flaw in the language.
That being said, I’m still doing my new project in Rust. Let me give you my reasons:
all the momentum appears to be behind Rust: Google is paying people to rewrite things in Rust, Microsoft has selected Rust as a language for safe programming, even Linus has indicated he’d be okay with Rust in the kernel. I’m not old enough to retire so I need to learn languages that will be used in the future.
cross-language libraries: I need to write code that can be used from multiple languages trivially. Traditionally this would be done in C. I need the code to be exposed as a Python module, pulled into NodeJS, etc. I tried to do this in Swift and while Swift-calls-C is trivial, the other way around is “possible, but undocumented and not officially supported.” Go brings in its own host of problems too.
libraries: if I want to parse a MIME tree (for example) in Rust, I’m spoiled for choice. If I want to parse a MIME tree in Swift or Zig, I have to write it myself or have maybe two options.
despite my criticism, I do like the strong safety guarantees Rust provides and I do like large parts of the language (traits, the well-defined iterator semantics, cargo, ADT-style enums, etc).
At the end of the day, I need a language that can run close to the hardware, without a heavy runtime, that can write libraries for other languages, and has a good library ecosystem of its own. That pretty much means C, C++, or Rust. It’s just a shame that Rust isn’t…fun.
(And I am really sad that Swift on non-Apple platforms/as a systems language appears to be DOA.)
EDIT: the fact that this comment got downvoted as “troll” kinda reinforces my thoughts on the Rust community….remember: even if you use Rust and explain why you’re using Rust, any criticism whatsoever is trolling and not legitimate in the eyes of a disturbingly large part of the community.
This matches my limited experience with Rust so well. I was able to write some nontrivial code in it, but it was a constant fight with the compiler, everything was way more verbose than I liked, and ultimately it was less enjoyable than my daily-driver C++.
Currently my “fun” language is Nim. It’s fast, low-overhead, integrates super well with C, and is mostly quite fun to use. It’s a bit too loosely-goosey with safety — the unsafe language constructs are very close to the surface and too easy to reach for — and the community is strongly against adding Rust-style safety, but I can live with that.
With C++ I at least have the escape hatch of going back to C.
I started using some of the C++ 11, 14, 17 template and compile time programming stuff: constexpr, etc.
Some of it is OK. There are lots of holes. When there’s a hole, I go back to a C macro! That has worked well enough many times.
So ironically C++ has incredible complexity, but you can always avoid it by programming in C :) On the other hand, the template stuff can be useful.
I kinda cringe when I realize someone’s first experience with systems programming could be in Rust. But then again I also cringe at how long it took to be productive in C and C++ too (more than a decade). We’re not there yet :)
Swift is a lovely language. It’s still missing good concurrency support, but they’re apparently working on something similar to Rust’s move-semantics. I do still feel like it’s not something I can use in cross-platform code yet.
It’s also something I wouldn’t be comfortable using outside of Apple’s ecosystem.
There is always the chance that Apple decides to make future development of the language proprietary, and then you are stuck with your code on an outdated compiler on an unsupported system.
I feel like I was productive in C almost immediately but I think that’s colored by the fact that it was (a) over two decades ago when I started, (b) the problems I was solving were simpler, (c) the systems I was targeting were simpler, (d) I was young and naive and didn’t know what I was doing so if things even sorta worked I assumed I was a programming god.
That being said, C fits in my head, and has not changed drastically in thirty years.
Zig is way better at metaprogramming, but doesn’t give you great safety guarantees. Rust is better at type checking, but has at least 3 different kinds of metaprogramming to patch over usability/composability holes created by that rigidity (2 kinds of macros and const contexts)
I won’t lie; after reading this, it has further pushed my doubts about Rust. This is coming from someone who uses Rust in production and hobby projects. My largest issue was the fact that it had no standards document. My second issue is there’s only one implementation which is complete - with mrustc probably forever trailing behind.
This article really highlights another big glaring issue: compiler time programming is terrible.
And I thought maybe dependency sizes were justifiable in some “futuristic” way, but Zig shows otherwise. IMO this is not a problem because it can be pecked at over time.
The rest of the article seems to be the author struggling with types. Rust’s type system and the borrow checker are probably the best things about it. I find if you stay within the realm of these two things, you’re going to have a really good time.
I’ve been interested in Rust since before the 0.1 days. At the time I was looking for something kind of like OCaml, but that would have better support for multi-threaded programming and Rust was this promising new language. (At the time, there was another new language in the same space, Clay that never got off the ground.)
Lately, maybe because of my age, I’ve begun feeling uneasy about the increase in complexity of Rust. One can understand why many of the recent features were introduced (async, const generics, generic associated types, etc.) and in isolation, they seem perfectly justified. But when looking at the whole package, I feel the complexity budget of Rust is now too far into the red for my personal comfort.
That said, I will keep using Rust for the near and medium future (although some younger Rustaceans might have issues with my increasingly un-modern style of Rust). It has a good ecosystem, good tooling, allows fast-as-C code, and most importantly to me: it helps to keep me away from memory safety issues. We’ve seen the articles about how ~70% of vulnerabilities are due to memory bugs and Rust’s ownership model and borrow checker give every user of the language a common tool to prevent those vulnerabilities. (By the way, I think it’s fascinating that 70% is a figure that has been found independently by many organizations.)
Nevertheless, I keep eyeing Zig as a possible escape hatch from Rust. The older I get, the closer I find myself philosophically to Zig. The idea of mastering a smaller tool is becoming more attractive to greying me than learning ever more features. (In other “get off my lawn” technology opinions, I completely distrust IoT appliances and I want buttons and knobs and not touch screens.) I’ve played with Zig a little bit, and I liked what I saw. I don’t think they have an answer to the 70% problem above, but if they came up with something for it, even if it was something not as effective at finding problems as Rust’s borrow checker, I would definitely start looking seriously at using it for some of my side projects.
but if they came up with something for it, even if it was something not as effective at finding problems as Rust’s borrow checker, I would definitely start looking seriously at using it for some of my side projects.
In Debug and ReleaseSafe mode there are already a lot of runtime checks to prevent UB from happening. There are plans for extending these capabilites, for example: recognizing at comptime when you try to return a pointer to function memory, probing for max call stack depth (and force heap allocation of frames for recursion) to make stack overflows impossible, etc.
Also if you use std.heap.GeneralPurposeAllocator you can get already today checks for leaks and double frees in Debug mode. It’s like running valgrind by default.
One of the problems with runtime only checks is you have to hit those code paths in testing or they can be missed. It would be great if other languages provided static checks at compile time, although that then leads back to how to do so without the complexities of what Rust forces you to provide. It’s a hard problem. So I don’t think runtime checks are a true apples to apples comparison, although it is a step in the right direction to be sure!
Device crates expose hardware peripherals as distinct types
One does not simply compute with distinct types in Rust
The whole second half of the post reads to me like elaborate workarounds for a lack of OOP. The way I’d solve this problem would be to create an interface describing a peripheral, create an implementation for each actual peripheral type, and then code everything to that interface. (Ideally the device crates would already be using a common predefined interface, saving me the trouble.)
It’s interesting that Zig has an “inline for” statement that can handle heterogeneous types, but then you’ve “solved” the problem at compile time with an arbitrarily large unrolled loop. That doesn’t seem like a good way to do this, especially on a microcontroller.
(I know Rust has interfaces. But Zig has no OOP at all, last I looked, which is one reason I haven’t considered using it.)
Well yeah, you can implement interfaces in any language. Turing-completeness, amirite?
It looks like Zig’s pattern for interfaces is a struct containing function pointers that take a pointer to the struct as the first argument, I.e. handmade vtables. I remember doing this in Pascal in the mid-80s. Haven’t we moved on from that in the last 30 years? I like a language that does a bit more work for me.
In a nutshell my objection to the “nothing’s hidden, every function call is explicit” school of language design is that it kind of locks you into the set of abstractions provided by the language. Any abstractions you try to build have all their rivets and wiring exposed, and can’t be used cleanly.
Ideally if you care about size, the compiler should roll-up the unrolled loops where it can, keeping the type safety intact. But I’m not sure if LLVM and/or any other compilers have this potential optimization.
But it looks like the libraries they’ve used in Rust have two different APIs that required different method calls, and their Zig equivalents happen to have the same API (at least duck-typing-wise same)?
I wonder if using traits for each keyboard type would have made that easier (impl ReadKeys for Keytron). #ifdef-like approach is not very nice, even when you don’t have to worry about types or work with stricter syntax.
But no doubt that Rust bringing features for million-line codebases to a dozen-line driver makes it too heavy.
Of course it is. Someone used both to solve the same problem, so clearly they can be used in the same context and people will be interested to know the differences. It would be quite boring if we could only compare things that are exactly the same.
I think one thing that’s missing from the analysis in this post is that the point of Rust is to get memory safety in your applications, but a keyboard firmware has no need for memory safety.
I’ve never used Rust. I’ve never used Zig. But I have written three keyboard firmwares, all in different languages. In a keyboard firmware, there is never any need to allocate any memory at runtime. You can preallocate all the memory you need ahead of time, and it’s honestly not much more than a couple bits per key. This is just … vastly different from basically every program that runs on my computer.
Yes and no ? AFAIK they do also position themself as c replacement (even stronger: dropin-replacement) for C. And try to fix the old issues C has. Similar features are async/await, though zig has this in a way you can create async and blocking functions at the same time. Rust tries to be an embedded platform (understandably), which zig also wants to be. And rust also wants to adopt configurable allocators (required for many embedded things), which zig already has.
But yeah they have different targets and features. I’d say zig tries to stay out of your way, while rust has stronger guarantees but requires you to do something for that.
FWIW, this is how you express conditional arguments / struct fields in Rust. The condition has to encompass the name as well as the type, not just the type as was first attempted.
I feel like Rust has definitely obliterated its complexity budget in unfortunate ways. Every day somebody comes to the sled discord chat with confusion over some async interaction. The fixation on async-await, despite it slowing down almost every real-world workload it is applied to, and despite it adding additional bug classes and compiler errors that simply don’t exist unless you start using it, has been particularly detrimental to the ecosystem. Sure, the async ecosystem is a “thriving subcommunity” but it’s thriving in the Kuhnian sense where a field must be sufficiently problematic to warrant collaboration. There’s no if-statement community anymore because they tend to work and be reasonably well understood. With async-await, I observed that the problematic space of the overall community shifted a bit from addressing external issues through memory safety bug class mitigation to generally coping with internal issues encountered due to some future not executing as assumed.
The problematic space of a community is a nice lens to think about in general. It is always in-flux with the shifting userbase and their goals. What do people talk about? What are people using it for? As the problematic space shifts, at best it can introduce the community to new ideas, but there’s also always an aspect of it that causes mourning over what it once represented. Most of my friends who I’ve met through Rust have taken steps to cut interactions with “the Rust community” down to an absolute minimum due to it tending to produce a feeling of alienation over time. I think this is pretty normal.
I’m going to keep using Rust to build my database in and other things that need to go very fast, but I see communities like Zig’s as being in some ways more aligned with the problematic spaces I enjoy geeking out with in conversations. I’m also thinking about getting a lot more involved in Erlang since I realized I haven’t felt that kind of problem space overlap in any language community since I stopped using it.
I was surprised to see the Rust community jump on the async-await bandwagon, because it was clear from the beginning it’s a bandwagon. When building a stable platform (e.g. a language) you wait for the current fashion to crest and fall, so you can hear the other side of the story – the people who used it in anger, and discovered what the strengths and weaknesses really are. Rust unwisely didn’t do that.
I will note though that the weaknesses of the async-await model were apparent right from the beginning, and yet here we are. A lesson for future languages.
This hits me particularly hard because I had experienced a lot of nearly-identical pain around async when using various flavors of Scala futures for a few years before picking up Rust in 2014. I went to the very first Rust conference, Rust Camp in 2015 at Berkeley, and described a lot of the pain points that had caused significant issues in the Scala community to several of the people directly working on the core async functionality in Rust. Over the years I’ve had lots of personal conversations with many of the people involved, hoping that sharing my experiences would somehow encourage others to avoid well-known painful paths. This overall experience has caused me to learn a lot about human psychology - especially our inability to avoid problems when there are positive social feedback loops that lead to those problems. It makes me really pessimistic about climate apocalypse and rising authoritarianism leading us to war and genocides, and the importance of taking months and years away from work to enjoy life for as long as it is possible to do so.
The content of ideas does not matter very much compared to the incredibly powerful drive to exist in a tribe. Later on when I read Kuhn’s Structure of Scientific Revolutions, Feyerabend’s Against Method, and Ian Hacking’s Representing and Intervening, which are ostensibly about the social aspects of science, I was blown away by how strongly their explanations of how science often moves in strange directions that may not actually cause “progress” mapped directly to the experiences I’ve had while watching Rust grow and fail to avoid obvious traps due to the naysayers being drowned out by eager participants in the social process of Making Rust.
Reminds me of the theory that Haskell and Scala appeal because they’re a way for the programmer to needsnipe themselves
Thanks for fighting the good fight. Just say “no” to complexity.
Which of those three books you mentioned do you think is most worthwhile?
I think that Kuhn’s Structure of Scientific Revolutions has the broadest appeal and I think that nearly anyone who has any interaction with open source software will find a tremendous number of connections to their own work. Science’s progressions are described in a way that applies equally to social-technical communities of all kinds. Kuhn is also the most heavily cited thinker in later books on the subject, so by reading his book, you gain deeper access to much of the content of the others, as it is often assumed that you have some familiarity with Kuhn.
You can more or less replace any mention of “paper citation” with “software dependency” without much loss in generality while reading Kuhn. Hacking and Feyerabend are more challenging, but I would recommend them both highly. Feyerabend is a bit more radical and critical, and Hacking zooms out a bit more and talks about a variety of viewpoints, including many perspectives on Kuhn and Feyerabend. Hacking’s writing style is really worth experiencing, even by just skimming something random by him, by anyone who writes about deep subjects. I find his writing to be enviably clear, although sometimes he leans a bit into sarcasm in a way that I’ve been put off by.
If you don’t mind, what’s an example of async/await pain that’s common among languages and not to do with how Rust uniquely works? I ask because I’ve had a good time with async/await, but in plainer, application-level languages.
(Ed: thanks for the thoughtful replies)
The classic “what color is your function” blog post describes what is, I think, such a pain? You have to choose in your API whether a function can block or not, and it doesn’t compose well.
I read that one, and I took their point. All this tends to make me wonder if Swift (roughly, Rust minus borrow checker plus Apple backing) is doing the right thing by working on async/await now.
But so far I don’t mind function coloring as I use it daily in TypeScript. In my experience, functions that need to be async tend to be the most major steps of work. The incoming network request is async, the API call it makes is async, and then all subsequent parsing and page rendering aren’t async, but can be if I like.
Maybe, like another commenter said, whether async/await is a net positive has more to do with adapting the language to a domain that isn’t otherwise its strong suit.
You might be interested in knowing that Zig has async/await but there is no function coloring problem.
https://kristoff.it/blog/zig-colorblind-async-await/
Indeed this is an interesting difference at least in presentation. Usually, async/await provides sugar for an existing concurrency type like Promise or Task. It doesn’t provide the concurrency in the first place. Function colors are then a tradeoff for hiding the type, letting you think about the task and read it just like plain synchronous code. You retain the option to call without await, such that colors are not totally restrictive, and sometimes you want to use the type by hand; think Promise.all([…]).
Zig seems like it might provide all these same benefits by another method, but it’s hard to tell without trying it. I also can’t tell yet if the async frame type is sugared in by the call, or by the function definition. It seems like it’s a sort of generic, where the nature of the call will specialize it all the way down. If so, neat!
That’s precisely it!
I’ve been poking at Zig a bit since this thread; thank you for stirring my interest. :)
Well, I think that async/await was a great thing for javascript, and generally it seems to work well in languages that have poor threading support. But Rust has great threading support, and Rust’s future-based strategy aimed from the beginning at copying Scala’s approach. A few loud research-oriented voices in the Rust community said “we think Scala’s approach looks great” and it drowned out the chorus of non-academic users of Scala who had spent years of dealing with frustrating compilation issues and issues where different future implementations were incompatible with each other and overall lots of tribalism that ended up repeating in a similar way in the Rust async/await timeline.
I am somewhat surprised that you say Rust’s futures are modeled after Scala’s. I assume the ones that ended up in the standard library. As for commonalities: They also offer combinators on top of a common futures trait and you need explicit support in libraries - that’s pretty much all that is similar to Rust’s.
In Scala, futures were annoying because exceptions and meaningless stacktraces. In Rust, you get the right stacktraces and error propagation.
In Rust, Futures sucked for me due to error conversions and borrowing being basically unsupported until async await. Now they are still annoying because of ecosystem split (sync vs various partially compatible async).
The mentioned problem of competing libraries is basically unpreventable in fields without wide consensus and would have happened with ANY future alternative. If you get humans to agree on sensible solutions and not fight about irrelevant details, you are a wizard.
Where I agree is that it was super risky to spend language complexity budget on async/await, even though solving the underlying generator/state machine problem felt like a good priority. While async await feels a bit to special-cased and hacky to be part of the language… It could be worse. If we find a better solution for async in Rust, we wouldn’t have to teach the current way anymore.
Other solutions would just have different pros and cons. E.g. go’s or zig’s approach seemed the solution even deeper into the language with the pro of setting a somewhat universal standard for the language.
It was emulating Finagle from the beginning: https://medium.com/@carllerche/announcing-tokio-df6bb4ddb34 but then the decision to push so much additional complexity into the language itself so that people could have an easier time writing strictly worse systems was just baffling.
Having worked in Finagle for a few years before that, I tried to encourage some of the folks to aim for something lighter weight since the subset of Finagle users who felt happy about its high complexity seemed to be the ones who went to work at Twitter where the complexity was justified, but it seemed like most of the community was pretty relieved to switch to Akka which didn’t cause so much type noise once it was available.
I don’t expect humans not to fragment now, but over time I’ve learned that it’s a much more irrational process than I had maybe believed in 2014. Mostly I’ve been disappointed about being unable to communicate with what was a tiny community about something that I felt like I had a lot of experience with and could help other people avoid pain around, but nevertheless watch it bloom into a huge crappy thing that now comes back into my life every day even when I try to ignore it by just using a different feature set in my own stuff.
I hope you will get a reply by someone with more Rust experience than me, but I imagine that the primary problem is that even if you don’t have to manually free memory in Rust, you still have to think about where the memory comes from, which tends to make lifetime management more complicated, requiring to occasionally forcefully move things unto the heap (Box) and also use identity semantics (Pin), and so all of this contributes to having to deal with a lot of additional complexity to bake into the application the extra dynamicism that async/await enables, while still maintaining the safety assurances of the borrow checker.
Normally, in higher level languages you don’t ever get to decide where the memory comes from, so this is a design dimension that you never get to explore.
I’m curious if you stuck around in Scala or pay attention to what’s going on now because I think it has one of the best stories when it comes to managing concurrency. Zio, Cats Effect, Monix, fs2 and Akka all have different goals and trade offs but the old problem of Future is easily avoided
I’m not surprised. I don’t know how async/await works exactly, but it definitely has a clear use case. I once implemented a 3-way handshake in C. There was some crypto underneath, but the idea was, from the server’s point of view was to receive a first message, respond, then wait for the reply. Once the reply comes and is validated the handshake is complete. (The crypto details were handled by a library.)
Even that simple handshake was a pain in the butt to handle in C. Every time the server gets a new message, it needs to either spawn a new state machine, or dispatch it to an existing one. Then the state machine can do something, suspend, and wait for a new message. Note that it can go on after the handshake, as part of normal network communication.
That state machine business is cumbersome and error prone, I don’t want to deal with it. The programming model I want is blocking I/O with threads. The efficiency model I want is async I/O. So having a language construct that easily lets me suspend & resume execution at will is very enticing, and I would jump to anything that gives me that —at least until I know better, which I currently don’t.
I’d even go further: given the performance of our machines (high latencies and high throughputs), I believe non-blocking I/O at every level is the only reasonable way forward. Not just for networking, but for disk I/O, filling graphics card buffers, everything. Language support for this is becoming as critical as generics themselves. We laughed “lol no generics” at Go, but now I do believe it is time to start laughing “lol no async I/O” as well. The problem now is to figure out how to do it. Current solutions don’t seem to be perfect (though there may be one I’m not aware of).
The whole thing with async I/O is that process creation is too slow, and then thread creation was too slow, and some might even consider coroutine creation too slow [1]. It appears that concerns that formerly were of the kernel (managing I/O among tasks; scheduling tasks) are now being pushed out to userland. Is this the direction we really want to go?
[1] I use coroutines in Lua to manage async I/O and I think it’s fine. It makes the code look like non-blocking, but it’s not.
I don’t think it’s unreasonable to think that the kernel should have as few concerns as possible. It’s a singleton, it doesn’t run with the benefit of memory protection, and its internal APIs aren’t as stable as the ones it provides to userland.
… and, yes, I think a lot of async/await work is LARPing. But that’s because a lot of benchmark-oriented development is LARPing, and probably isn’t special to async/await specifically.
I’m not sure what you’re getting at. I want async I/O to avoid process creation and thread creation and context switches, and even scheduling to some extent. What I want is one thread per core, and short tasks being sent to them. No process creation, no thread creation, no context switching. Just jump the instruction pointer to the relevant task, and return to the caller when it’s done.
And when the task needs to, say, read from the disk, then it should do so asynchronously: suspend execution, return to the caller, wait for the response to come back, and when it does resume execution. It can be done explicitly with message passing, but that’s excruciating. A programming model where I can kinda pretend the call is blocking (but in fact we’re yielding to the caller) is much nicer, and I believe very fast.
Agreed. I always told people that
async/awaitwill be just as popular as Java’ssynchronizeda few years down the road. Some were surprised, some were offended, but sometimes reality is uncomfortable.Thank you for sharing, Zig has been much more conservative than Rust in terms of complexity but we too have splurged a good chunk of the budget on async/await. Based on my experience producing introductory materials for Zig, async/await is by far the hardest thing to explain and probably is going to be my biggest challenge to tackle for 2021. (that said, it’s continuations, these things are confusing by nature)
On the upside
This is hopefully not going to be a problem in our case. Part of the complexity of async/await in Zig is that a single library implementation can be used in both blocking and evented mode, so in the end it should never be the case that you can only find an async version of a client library, assuming authors are willing to do the work, but even if not, support can be added incrementally by contributors interested in having their use case supported.
I remember the time I asked one of the more well-known Rust proponents “so you think adding features improves a language” and he said “yes”. So it was pretty clear to me early on that Rust would join the feature death march of C++, C#, …
That’s so painfully true.
For instance, it has different syntax for struct creation and function calls, their poor syntax choices also mean that structs/functions won’t get default values any time soon.
;is mandatory (what is this, 1980?), but you can leave out,at the end.The severe design mistake of using
<>for generics also means you have to learn 4 different syntax variations, and when to use them.The whole module stuff is way too complex and only makes sense if you programmed in C before. I have basically given up on getting to know the intricacies, and just let IntelliJ handle
uses.Super weird that both
ifandswitchexist.Yes, that’s my experience too. I have some (rather popular) projects on GitHub that I archive from time to time to not having to deal with Rust people. There are some incredibly toxic ones, which seem to be – for whatever reason – close to some “core” Rust people, so they can do whatever the hell they like.
Perhaps they are trying to avoid the C++ thing where you can’t tell whether
foo(bar)is struct creation or a function call without knowing whatfoois?It only makes sense to someone who has programmed in C++. C’s “module” system is far simpler and easier to grok.
Would you have preferred
I think that syntax is clunky when you start needing
else if.Why wouldn’t you be able to tell?
Even if that was the issue (it isn’t), that’s not the problem C++ has – it’s that
fooalso could be 3 dozen other things.No, I prefer having one unified construct that can deal with both usecases reasonably well.
The only way to tell what is going on is if you already know the types of all the symbols.
Ok, do you have an example from another language which you think handles this reasonably well?
Let the IDE color things accordingly. Solved problem.
I’m currently in the process of implementing it, but I think this is a good intro to my plans.
The problem of course is for the writer of the IDE :)
Constructs like these in C++ make it not only harder for humans to parse the code, but for compilers as well. This turns into real-world performance decreases which are avoided in other languages.
That’s interesting, but I think there’s a conflict with Rust’s goal of being a systems-level programming language. Part of that is having primitives which map reasonably well onto things that the compiler can translate into machine code. Part of the reason that languages like C have both
ifandswitchis because switch statements of the correct form may be translated into an indirect jump instead of repeated branches. Of course, a Sufficiently Smart Compiler could optimize this even in theifcase, but it is very easy to write code which is not optimizable in such a way. I think there is value to both humans and computers in having separate constructs for arbitrary conditionals and for equality. It helps separate intent and provides some good optimization hints.Another reason why this exists is for exhaustiveness checks. Languages with
switchcan check that you handle all cases of an enum.The other half of this is that Rust is the bastard child of ML and C++. ML and C++ both have
match/switch, so Rust has one too.I think you will have a lot of trouble producing good error messages with such a syntax. For example, say someone forgets an
=or even both==s. If your language does false-y and truth-y coercion, then there may be no error at all here. And to the parser, it is not clear at all where the error is. Further, this sort of extension cannot be generalized to one-liners. That is, you cannot unambiguously parseif a == b then c == d then ewithout line-breaks.On the subject, in terms of prior-art, verilog allows expressions in its case labels. This allows for some similar syntax constructions (though more limited since functions are not as useful as in regular programming languages).
This is a good thing. Creating a struct is a meaningfully different operation from calling a function, and there’s no problem with having there be separate syntax for these two separate things.
The Rust standard library provides a Default trait, with examples of how to use it and customize it. I don’t find it at all difficult to work with structs with default values in Rust.
I don’t understand this comment at all. Rust’s module system seems fairly similar to module systems in some other languages I’ve used, although I’m having trouble thinking of other languages that allow you to create a module hierarchy within a single file, like you can do with the
mod { }keyword (C++ allows nestednamespaces I think, but that’s it). I don’t see how knowing C has anything to do with understand Rust modules better. C has no module system at all.Lua can do this, although it’s not common.
I guess that’s why many Rust devs – immediately after writing a struct – also define a fun to wrap their struct creation? :-)
It really isn’t.
That’s clearly not what I alluded to.
Rust’s module system only makes sense if you keep in mind that it’s main goal is to produce one big ball of compiled code in the end. In that sense, Rust’s module system is a round-about way to describe which parts of the code end up being part of that big ball.
Putting a OCaml hat on:
match.What other goal would there be? That’s what 100% of compiled languages aim at… Comparing rust to C which has 0 notion of module is just weird.
In what sense would this be an obstacle? I would expect that a modern language let’s you match on anything that provides the required method/has the right signature. “This is a struct, so you can match on it” feels rather antiquated.
It feels like it was built by someone who never used anything but C in his life, and then went “wouldn’t it be nice if it was clearer than in C which parts of the code contribute to the result?”.
The whole aliasing, reexporting etc. functionality feels like it exists as a replacement for some convenience C macros, and not something one actually would want. I prefer that there is a direct relationship between placing a file somewhere and it ending up in a specific place, without having to wire up everything again with the module system.
There is documented inspiration from OCaml from the rust original creator. The first compiler was even in OCaml, and a lot of names stuck (like
Some/Nonerather than the HaskellJust/Nothing). It also has obvious C++ influences, notably the namespace syntax being::and<>for generics. The module system most closely reminds me of a mix of OCaml and… python, with special file names (mod.rs, like__init__.pyor something like that?), even though it’s much much simpler than OCaml. Again not just “auto wiring” files in is a net benefit (another lesson from OCaml I’d guess, where the build system has to clarify what’s in or out a specific library). It makes build more declarative.As for the matching: rust doesn’t have active patterns or the scala-style deconstruction. In this context (match against values you can pre-compile pattern-matching very efficiently to decision trees and constant time access to fields by offset. This would be harder to do efficiently with “just call this
deconstuctmethod”. This is more speculation on my side, but it squares with rust’s efficiency concerns.I see your point, but in that case Rust would need to disallow match guards too (because what else are guards, but less reusable
unapplymethods?).Well there are translation units :) (though you can only import using the linker)
Perl can do this.
Elixir also allows you to create a module hierarchy within a single file.
And Julia. Maybe this isn’t so rare.
Ugh this one gets me every time. Why Rust, why.
Same in Zig? Curious to know Zig rationale for this.
In almost all languages with mandatory semicolons, they exist to prevent multi-line syntax ambiguities. The designers of Go and Lua both went to great pains to avoid such problems in their language grammars. Unlike, for example, JavaScript. This article about semicolon insertion rules causing ambiguity and unexpected results should help illustrate some of these problems.
Pointing out Javascript isn’t a valid excuse.
Javascript’s problems are solely Javascript’s. If we discarded every concept that was implemented poorly in Javascript, we wouldn’t have many concepts left to program with.
I want semicolon inference done right, simple as that.
That’s not what I’m saying. JavaScript is merely an easy example of some syntax problems that can occur. I merely assume that Rust, which has many more features than Go or Lua, decided not to maintain an unambiguous grammar without using semicolons.
Why would the grammar be ambiguous? Are you sure that you don’t keep arguing from a JavaScript POV?
Not needing
;doesn’t mean the grammar is ambiguous.~_~
Semicolons are an easy way to eliminate grammar ambiguity for multi-line syntax. For any language. C++ for example would have numerous similar problems without semicolons.
Of course. Go and Lua are examples of languages designed specifically to avoid ambiguity without semicolons. JavaScript, C++, and Rust were not designed that way. JavaScript happens to be an easy way to illustrate possible problems because it has janky automatic semicolon insertion, whereas C++ and Rust do not.
I’m completely unsure what you are trying to argue – it doesn’t make much sense. Has your triple negation above perhaps confused you a bit?
The main point is that a language created after 2000 simply shouldn’t need
;.The rationale for semicolons. They make parsing simpler, particularly for multi-line syntax constructs. I have been extremely clear about this the entire time. I have rephrased my thesis multiple times:
Many underestimate the difficulty of creating a language without semicolons. Go has done so with substantial effort, and maintaining that property has by no means been effortless for them when adding new syntax to the language.
Yeah, you know, maybe we should stop building languages that are so complex that they need explicitly inserted tokens to mark “previous thing ends here”? That’s the point I’m making.
Cry me a river. Adding features does not improve a language.
Having a clear syntax where errors don’t occur 15 lines below the missing
)or}(as would unavoidably happen without some separator — trust me, it’s one of OCaml’s big syntax problems for toplevel statements) is a net plus and not bloat.What language has no semicolon (or another separator, or parenthesis, like lisp) and still has a simple syntax? Even python has
;for same-line statements. Using vertical whitespace as a heuristic for automatic insertion isn’t a win in my book.Both Kotlin and Swift have managed to make a working , unambiguous C-like syntax without semicolons.
I didn’t know. That involves no whitespace/lexer trick at all? I mean, if you flatten a whole file into one line, does it still work? Is it still in LALR(1)/LR(1)/some nice fragment?
The typical problem in this kind of grammar is that, while binding constructs are easy to delimit (
var/val/let…), pure sequencing is not. If you havea = 1 b = 2 + 3 c = 4 d = f(a)semicolons make things just simpler for the parser.Why are line breaks not allowed to be significant? I don’t think I care if I can write an arbitrarily long program on one line…
I agree completely. I love Lua in particular. You can have zero newlines yet it requires no semicolons, due to its extreme simplicity. Lua has only one ambiguous case: when a line begins with a
(and the previous line ends with a value.Since Lua has no semantic newlines, this is exactly equivalent to:
The Lua manual thus recommends inserting a
;before any line starting with(.But I have never needed to do this. And if I did, I would probably write this instead:
Also curious, as well as why Zig uses parentheses in
ifs etc. I know what I’ll say is lame, but those two things frustrate me when looking at Zig’s code. If I could learn the rationale, it might hopefully at least make those a bit easier for me to accept and get over.One reason for this choice is to remove the need for a ternary operator without greatly harming ergonomics. Having the parentheses means that the blocks may be made optional which allows for example:
There’s a blog post by Graydon Hoare that I can’t find at the moment, where he enumerates features of Rust he thinks are clear improvements over C/C++ that have nothing to do with the borrow checker. Forcing if statements to always use braces is one of the items on his list; which I completely agree with. It’s annoying that in C/C++, if you want to add an additional line to a block of a brace-less if statement, you have to remember to go back and add the braces; and there have been major security vulnerabilities caused by people forgetting to do this.
That was things Rust shipped without.
The following would work just as well:
I’ve written an expression oriented language, where the parenthesis were optional, and the braces mandatory. I could use the exact same syntactic construct in regular code and in the ternary operator situation.
Another solution is inserting another keyword between the condition and the first branch, as many ML languages do:
I don’t get how that’s worth making everything else ugly. I imagine there’s some larger reason. The parens on ifs really do feel terrible after using go and rust for so long.
For what values of a, b, c would this be ambiguous?
I guess it looks a little ugly?
If
bis actually a parenthesised expression like(2+2), then the whole thing looks like a function call:Parsing is no longer enough, you need to notice that
ais not a function. Lua has a similar problem with optional semicolon, and chose to interpret such situations as function calls. (Basically, a Lua instruction stops as soon as not doing so would cause a parse error).Your syntax would make sense in a world of optional semicolons, with a parser (and programmers) ready to handle this ambiguity. With mandatory semicolons however, I would tend to have mandatory curly braces as well:
Ah, Julia gets around this by banning whitespace between the function name and the opening parenthesis, but I know some people would miss that extra spacing.
Thanks for the example!
I think this is another case where banning bad whitespace makes this unambiguous.
You can summarise these rules as “infix operators must have balanced whitespace” and “unary operators must not be followed by whitespace”.
Following these rules, your expression is unambiguously a syntax error, but if you remove the whitespace between - and a it works.
Or you simply ban unary operators.
Sure, seems a bit drastic, tho. I like unary logical not, and negation is useful sometimes too.
Not sure how some cryptic operator without working jump-to-declaration is better than some bog-standard method …
A minus sign before a number to indicate a negative number is probably recognizable as a negative number to most people in my country. I imagine most would recognise
-xas “negative x”, too. Generalising that to other identifiers is not difficult.An exclamation mark for boolean negation is less well known, but it’s not very difficult to learn. I don’t see why jump-to should fail if you’re using a language server, either.
More generally, people have been using specialist notations for centuries. Some mathematicians get a lot of credit for simply inventing a new way to write an older concept. Maybe we’d be better off with only named function calls, maybe our existing notations are made obsolete by auto-complete, but I am not convinced.
My current feeling is that async/await is the worst way to express concurrency … except for all the other ways.
I have only minor experience with it (in Nim), but a good amount of experience with concurrency. Doing it with explicit threads sends you into a world of pain with mutexes everywhere and deadlocks and race conditions aplenty. For my current C++ project I built an Actor library atop thread pools (or dispatch queues), which works pretty well except that all calls to other actors are one-way so you now need callbacks, which become painful. I’m looking forward to C++ coroutines.
I think people are complaining about the current trend to just always use async for everything. Which ends up complaining about rust having async at all.
This is amazing. I had similar feelings (looking previously at JS/Scala futures) when the the plans for async/await were floating around but decided to suspend my disbelief because of how good previous design decisions in the language were. Do you think there’s some other approach to concurrency fit for a runtime-less language that would have worked better?
My belief is generally that threads as they exist today (not as they existed in 2001 when the C10K problem was written, but nevertheless keeps existing as zombie perf canon that no longer refers to living characteristics) are the nicest choice for the vast majority of use cases, and that Rust-style executor-backed tasks are inappropriate even in the rare cases where M:N pays off in languages like Go or Erlang (pretty much just a small subset of latency-bound load balancers that don’t perform very much CPU work per socket). When you start caring about millions of concurrent tasks, having all of the sources of accidental implicit state and interactions of async tasks is a massive liability.
I think The ADA Ravenscar profile (see chapter 2 for “motivation” which starts at pdf page 7 / marked page 3) and its successful application to safety critical hard real time systems is worth looking at for inspiration. It can be broken down to this set of specific features if you want to dig deeper. ADA has a runtime but I’m kind of ignoring that part of your question since it is suitable for hard real-time. In some ways it reminds me of an attempt to get the program to look like a pretty simple petri net.
I think that message passing and STM are not utilized enough, and when used judiciously they can reduce a lot of risk in concurrent systems. STM can additionally be made wait-free and thus suitable for use in some hard real-time systems.
I think that Send and Sync are amazing primitives, and I only wish I could prove more properties at compile time. The research on session types is cool to look at, and you can get a lot of inspiration about how to encode various interactions safely in the type system from the papers coming out around this. But it can get cumbersome and thus create more risks to the overall engineering effort than it solves if you’re not careful.
A lot of the hard parts of concurrency become a bit easier when we’re able to establish maximum bounds on how concurrent we’re going to be. Threads have a little bit more of a forcing function to keep this complexity minimized due to the fact that spawning is fallible due to often under-configured system thread limits. Having fixed concurrency avoids many sources of bugs and performance issues, and enables a lot of relatively unexplored wait-free algorithmic design space that gets bounded worst-case performance (while still usually being able to attempt a lock-free fast path and only falling back to wait-free when contention picks up). Structured concurrency often leans into this for getting more determinism, and I think this is an area with a lot of great techniques for containing risk.
In the end we just have code and data and risk. It’s best to have a language with forcing functions that pressure us to minimize all of these over time. Languages that let you forget about accruing data and code and risk tend to keep people very busy over time. Friction in some places can be a good thing if it encourages less code, less data, and less risk.
I like rust and I like threads, and do indeed regret that most libraries have been switching to async-only. It’s a lot more complex and almost a new sub-language to learn.
That being said, I don’t see a better technical solution for rust (i.e. no mandatory runtime, no implicit allocations, no compromise on performance) for people who want to manage millions of connections. Sadly a lot of language design is driven by the use case of giant internet companies in the cloud and that’s a problem they have; not sure why anyone else cares. But if you want to do that, threads start getting in the way at 10k threads-ish? Maybe 100k if you tune linux well, but even then the memory overhead and latency are not insignificant, whereas a future can be very tiny.
Ada’s tasks seem awesome but to the best of my knowledge they’re for very limited concurrency (i.e the number of tasks is small, or even fixed beforehand), so it’s not a solution to this particular problem.
Of course async/await in other languages with runtimes is just a bad choice. Python in particular could have gone with “goroutines” (for lack of a better word) like stackless python already had, and avoid a lot of complexity. (How do people still say python is simple?!). At least java’s Loom project is heading in the right direction.
Just like some teenagers enjoy making their slow cars super loud to emulate people who they look up to who drive fast cars, we all make similar aesthetic statements when we program. I think I may write on the internet in a way that attempts to emulate a grumpy grey-beard for similarly aesthetic socially motivated reasons. The actual effect of a program or its maintenance is only a part of our expression while coding. Without thinking about it, we also code as an expression of our social status among other coders. I find myself testing random things with quickcheck, even if they don’t actually matter for anything, because I think of myself as the kind of person who tests more than others. Maybe it’s kind of chicken-and-egg, but I think maybe we all do these things as statements of values - even to ourselves even when nobody else is looking.
Sometimes these costumes tend to work out in terms of the effects they grant us. But the overhead of Rust executors is just perf theater that comes with nasty correctness hazards, and it’s not a good choice beyond prototyping if you’re actually trying to build a system that handles millions of concurrent in-flight bits of work. It locks you into a bunch of default decisions around QoS, low level epoll behavior etc… that will always be suboptimal unless you rewrite a big chunk of the stack yourself, and at that point, the abstraction has lost its value and just adds cycles and cognitive complexity on top of the stack that you’ve already fully tweaked.
The green process abstraction seems to work well enough in Erlang to serve tens of thousands of concurrent connections. Why do you think the async/await abstraction won’t work for Rust? (I understand they are very different solutions to a similar problem.)
Not who you’re asking, but the reason why rust can’t have green threads (as it used to have pre-1.0, and it was scraped), as far as I undertand:
Rust is shooting for C or C++-like levels of performance, with the ability to go pretty close to the metal (or close to whatever C does). This adds some constraints, such as the necessity to support some calling conventions (esp. for C interop), and precludes the use of a GC. I’m also pretty sure the overhead of the probes inserted in Erlang’s bytecode to check for reduction counts in recursive calls would contradict that (in rust they’d also have to be in loops, btw); afaik that’s how Erlang implements its preemptive scheduling of processes. I think Go has split stacks (so that each goroutine takes less stack space) and some probes for preemption, but the costs are real and in particular the C FFI is slower as a result. (saying that as a total non-expert on the topic).
I don’t see why async/await wouldn’t work… since it does; the biggest issues are additional complexity (a very real problem), fragmentation (the ecosystem hasn’t converged yet on a common event loop), and the lack of real preemption which can sometimes cause unfairness. I think Tokio hit some problems on the unfairness side.
The biggest problem with green threads is literally C interop. If you have tiny call stacks, then whenever you call into C you have to make sure there’s enough stack space for it, because the C code you’re calling into doesn’t know how to grow your tiny stack. If you do a lot of C FFI, then you either lose the ability to use small stacks in practice (because every “green” thread winds up making an FFI call and growing its stack) or implementing some complex “stack switching” machinery (where you have a dedicated FFI stack that’s shared between multiple green threads).
Stack probes themselves aren’t that big of a deal. Rust already inserts them sometimes anyway, to avoid stack smashing attacks.
In both cases, you don’t really have zero-overhead C FFI any more, and Rust really wants zero-overhead FFI.
No they don’t any more. Split Stacks have some really annoying performance cliffs. They instead use movable stacks: when they run out of stack space, they copy it to a larger allocation, a lot like how
Vecworks, with all the nice “amortized linear” performance patterns that result.Two huge differences:
That changes everything with regard to concurrency, so you can’t really compare the two. A comparison to Python makes more sense, and Python async has many of the same problems (mutable state, and the need to compose with code and libraries written with other concurrency models)
I’d like to see a good STM implementation in a library in Rust.
I’m curious about this perspective. The number of individual threads available on most commodity machines even today is quite low, and if you’re doing anything involving external requests on an incoming-request basis (serializing external APIs, rewriting HTML served by another site, reading from slow disk, etc) and these external requests take anything longer than a few milliseconds (which is mostly anything assuming you have a commodity connection in most parts of the world, or on slower disks), then you are better off with a some form of “async” (or otherwise lightweight concurrent model of execution.) I understand that badly-used synchronization can absolutely tank performance with this many “tasks”, but in situations where synchronization is low (e.g. making remote calls, storing state in a db or separate in-memory cache), performance should be better than threaded execution.
Also, if I reach for Rust I’m deliberately avoiding GC. Go, Python, and Haskell are the languages I tend to reach for if I just want to write code and not think too hard about who owns which portion of data or how exactly the runtime schedules my code. With Rust I’m in it specifically to think about these details and think hard about them. That means I’m more prone to write complicated solutions in Rust, because I wouldn’t reach for Rust if I wanted to write something “simple and obvious”. I suspect a lot of other Rust authors are the same.
I don’t agree with the premise here. It depends more on the kernel, not the “machine”, and Linux in particular has very good threading performance. You can have 10,000 simultaneous threads on vanilla Linux on a vanilla machine. async may be better for certain specific problems, but that’s not the claim.
Also a pure async model doesn’t let you use all your cores, whereas a pure threading model does. If you really care about performance and utilization, your system will need threads or process level concurrency in some form.
I wasn’t rigorous enough in my reply, apologies.
What I meant to say was, the number of cores available on a commodity machine is quite low. Even if you spawn thousands of threads, your actual thread-level parallelism is limited to the # of cores available. If you’re at the point where you need to spawn more kernel threads than there are available cores, then you need to put engineering into determining how many threads to create and when. For IO bound workloads (which I described in my previous post), the typical strategy is to create a thread pool, and to allocate threads from this pool. Thread pools themselves are a solution so that applications don’t saturate available memory with threads and so you don’t overwhelm the kernel with time spent switching threads. At this point, your most granular “unit of concurrency” is each thread in this thread pool. If most of your workload is IO bound, you end up having to play around with your thread pool sizes to ensure that your workload is processed without thread contention on the one hand (too few threads) or up against resource limits (too many threads). You could of course build a more granular scheduler atop these threads, to put threads “to sleep” once they begin to wait on IO, but that is essentially what most async implementations are, just optimizations on “thread-grained” applications. Given that you’re already putting in the work to create thread pools and all of the fiddly logic with locking the pool, pulling out a thread, then locking and putting threads back, it’s not a huge lift to deal with async tasks. Of course if your workload is CPU bound, then these are all silly, as your main limiting resource is not IO but is CPU, so performing work beyond the amount of available CPU you have necessitates queuing.
Moreover the context with which I was saying this is that most Rust async libraries I’ve seen are async because they deal with IO and not CPU, which is what async models are good at.
Various downsides are elaborated at length in this thread.
Thanks for the listed points. What it’s made me realize is that there isn’t really a detailed model which allows us to demonstrate tradeoffs that come with selecting an async model vs a threaded model. Thanks for some food for thought.
My main concern with Rust async is mostly just its immaturity. Forget the code semantics; I have very little actual visibility into Tokio’s (for example) scheduler without reading the code. How does it treat many small jobs? Is starvation a problem, and under what conditions? If I wanted to write a high reliability web service with IO bound logic, I would not want my event loop to starve a long running request that may have to wait longer on IO than a short running request and cause long running requests to timeout and fail. With a threaded model and an understanding of my IO processing latency, I can ensure that I have the correct # of threads available with some simple math and not be afraid of things like starvation because I trust the Linux kernel thread scheduler much more than Tokio’s async scheduler.
That had me laughing out loud!
probably because it’s if-expressions 🙃
I hope I’m not opening any wounds or whacking a bee-hive for asking but… what sort of problematic interactions occur with the Rust community? I follow Rust mostly as an intellectual curiosity and therefor aren’t in deep enough to see the more annoying aspects. When I think of unprofessional language community behavior my mind mostly goes to Rails during the aughts when it was just straight-up hostile towards Java and PHP stuff. Is Rust doing a similar thing to C/C++?
This article so accurately describes my feelings on Rust. Programming in Rust just isn’t fun. I can’t get into a flow with Rust because I write the code that will solve the problem and then spend two hours fighting with the compiler to get it to work; and when it works the code no longer looks like the problem I’m trying to solve.
Knowing one part of Rust doesn’t help me know another part and there are special cases and exceptions everywhere (
?Sized, type+lifetime declarations that are 100+ characters long, etc). The module system seems overly complicated. I can’t just solve my problem, I have to wrestle with my language.Now, I will say that I don’t have a whole lot of Rust experience: maybe 100 hours. But I know that I was able to write good, working, productive code in Go well before 100 hours (and had fun doing it). After just 10 hours of Swift, I was able to do some good stuff.
Rust to me is like C++: just endless features thrown together. If there’s a new kind of problem to solve, Rust seems to fall on the “add a feature to solve it” side of the equation. New features are added so often and so quickly that I feel like I’m trying to learn a moving target.
The comments here and elsewhere about the community also hold true: more times than I care to remember, my dislike of some part of the language is seen as a personal failing rather than a potential flaw in the language.
That being said, I’m still doing my new project in Rust. Let me give you my reasons:
At the end of the day, I need a language that can run close to the hardware, without a heavy runtime, that can write libraries for other languages, and has a good library ecosystem of its own. That pretty much means C, C++, or Rust. It’s just a shame that Rust isn’t…fun.
(And I am really sad that Swift on non-Apple platforms/as a systems language appears to be DOA.)
EDIT: the fact that this comment got downvoted as “troll” kinda reinforces my thoughts on the Rust community….remember: even if you use Rust and explain why you’re using Rust, any criticism whatsoever is trolling and not legitimate in the eyes of a disturbingly large part of the community.
This matches my limited experience with Rust so well. I was able to write some nontrivial code in it, but it was a constant fight with the compiler, everything was way more verbose than I liked, and ultimately it was less enjoyable than my daily-driver C++.
Currently my “fun” language is Nim. It’s fast, low-overhead, integrates super well with C, and is mostly quite fun to use. It’s a bit too loosely-goosey with safety — the unsafe language constructs are very close to the surface and too easy to reach for — and the community is strongly against adding Rust-style safety, but I can live with that.
With C++ I at least have the escape hatch of going back to C.
I started using some of the C++ 11, 14, 17 template and compile time programming stuff: constexpr, etc.
Some of it is OK. There are lots of holes. When there’s a hole, I go back to a C macro! That has worked well enough many times.
So ironically C++ has incredible complexity, but you can always avoid it by programming in C :) On the other hand, the template stuff can be useful.
I kinda cringe when I realize someone’s first experience with systems programming could be in Rust. But then again I also cringe at how long it took to be productive in C and C++ too (more than a decade). We’re not there yet :)
Maybe someone needs to write a Rust-- that cuts out most of the complexity.
You might be interested in reading this post from withoutboats, a well known Rust contributor.
That would be nice! Even only throwing away all the UI cruft would be a measurable improvement.
From what I’ve seen, that would be Swift….
Swift is a lovely language. It’s still missing good concurrency support, but they’re apparently working on something similar to Rust’s move-semantics. I do still feel like it’s not something I can use in cross-platform code yet.
It’s also something I wouldn’t be comfortable using outside of Apple’s ecosystem.
There is always the chance that Apple decides to make future development of the language proprietary, and then you are stuck with your code on an outdated compiler on an unsupported system.
Trust in the maintainers of a language is honestly more important to me than any technical feature. I learned my lesson with HyperCard.
“What’s the most innovative piece of software on our platform and, possibly, the world? Yeah, let’s discontinue that one.”
Or Kotlin, look at Kotlin/Native, it works amazingly well and the language is actually pretty cool!
I feel like I was productive in C almost immediately but I think that’s colored by the fact that it was (a) over two decades ago when I started, (b) the problems I was solving were simpler, (c) the systems I was targeting were simpler, (d) I was young and naive and didn’t know what I was doing so if things even sorta worked I assumed I was a programming god.
That being said, C fits in my head, and has not changed drastically in thirty years.
This brings to mind Type Checking vs. Metaprogramming; ML vs. Lisp.
Zig is way better at metaprogramming, but doesn’t give you great safety guarantees. Rust is better at type checking, but has at least 3 different kinds of metaprogramming to patch over usability/composability holes created by that rigidity (2 kinds of macros and const contexts)
I won’t lie; after reading this, it has further pushed my doubts about Rust. This is coming from someone who uses Rust in production and hobby projects. My largest issue was the fact that it had no standards document. My second issue is there’s only one implementation which is complete - with mrustc probably forever trailing behind.
This article really highlights another big glaring issue: compiler time programming is terrible.
And I thought maybe dependency sizes were justifiable in some “futuristic” way, but Zig shows otherwise. IMO this is not a problem because it can be pecked at over time.
The rest of the article seems to be the author struggling with types. Rust’s type system and the borrow checker are probably the best things about it. I find if you stay within the realm of these two things, you’re going to have a really good time.
I’ve been interested in Rust since before the 0.1 days. At the time I was looking for something kind of like OCaml, but that would have better support for multi-threaded programming and Rust was this promising new language. (At the time, there was another new language in the same space, Clay that never got off the ground.)
Lately, maybe because of my age, I’ve begun feeling uneasy about the increase in complexity of Rust. One can understand why many of the recent features were introduced (async, const generics, generic associated types, etc.) and in isolation, they seem perfectly justified. But when looking at the whole package, I feel the complexity budget of Rust is now too far into the red for my personal comfort.
That said, I will keep using Rust for the near and medium future (although some younger Rustaceans might have issues with my increasingly un-modern style of Rust). It has a good ecosystem, good tooling, allows fast-as-C code, and most importantly to me: it helps to keep me away from memory safety issues. We’ve seen the articles about how ~70% of vulnerabilities are due to memory bugs and Rust’s ownership model and borrow checker give every user of the language a common tool to prevent those vulnerabilities. (By the way, I think it’s fascinating that 70% is a figure that has been found independently by many organizations.)
Nevertheless, I keep eyeing Zig as a possible escape hatch from Rust. The older I get, the closer I find myself philosophically to Zig. The idea of mastering a smaller tool is becoming more attractive to greying me than learning ever more features. (In other “get off my lawn” technology opinions, I completely distrust IoT appliances and I want buttons and knobs and not touch screens.) I’ve played with Zig a little bit, and I liked what I saw. I don’t think they have an answer to the 70% problem above, but if they came up with something for it, even if it was something not as effective at finding problems as Rust’s borrow checker, I would definitely start looking seriously at using it for some of my side projects.
In Debug and ReleaseSafe mode there are already a lot of runtime checks to prevent UB from happening. There are plans for extending these capabilites, for example: recognizing at comptime when you try to return a pointer to function memory, probing for max call stack depth (and force heap allocation of frames for recursion) to make stack overflows impossible, etc.
Also if you use
std.heap.GeneralPurposeAllocatoryou can get already today checks for leaks and double frees in Debug mode. It’s like running valgrind by default.One of the problems with runtime only checks is you have to hit those code paths in testing or they can be missed. It would be great if other languages provided static checks at compile time, although that then leads back to how to do so without the complexities of what Rust forces you to provide. It’s a hard problem. So I don’t think runtime checks are a true apples to apples comparison, although it is a step in the right direction to be sure!
The whole second half of the post reads to me like elaborate workarounds for a lack of OOP. The way I’d solve this problem would be to create an interface describing a peripheral, create an implementation for each actual peripheral type, and then code everything to that interface. (Ideally the device crates would already be using a common predefined interface, saving me the trouble.)
It’s interesting that Zig has an “inline for” statement that can handle heterogeneous types, but then you’ve “solved” the problem at compile time with an arbitrarily large unrolled loop. That doesn’t seem like a good way to do this, especially on a microcontroller.
(I know Rust has interfaces. But Zig has no OOP at all, last I looked, which is one reason I haven’t considered using it.)
if you want interfaces in Zig, you can make them. In this case a good starting point would be to create a tagged union over all the distinct types.
Here’s a talk on interfaces in Zig https://www.youtube.com/watch?v=AHc4x1uXBQE
Well yeah, you can implement interfaces in any language. Turing-completeness, amirite?
It looks like Zig’s pattern for interfaces is a struct containing function pointers that take a pointer to the struct as the first argument, I.e. handmade vtables. I remember doing this in Pascal in the mid-80s. Haven’t we moved on from that in the last 30 years? I like a language that does a bit more work for me.
In a nutshell my objection to the “nothing’s hidden, every function call is explicit” school of language design is that it kind of locks you into the set of abstractions provided by the language. Any abstractions you try to build have all their rivets and wiring exposed, and can’t be used cleanly.
Ideally if you care about size, the compiler should roll-up the unrolled loops where it can, keeping the type safety intact. But I’m not sure if LLVM and/or any other compilers have this potential optimization.
For this case Zig’s comptime looks better indeed.
But it looks like the libraries they’ve used in Rust have two different APIs that required different method calls, and their Zig equivalents happen to have the same API (at least duck-typing-wise same)?
I wonder if using traits for each keyboard type would have made that easier (
impl ReadKeys for Keytron).#ifdef-like approach is not very nice, even when you don’t have to worry about types or work with stricter syntax.But no doubt that Rust bringing features for million-line codebases to a dozen-line driver makes it too heavy.
Is comparing Rust to Zig even fair? Zig IIRC is a manual-deallocation language like C.
Of course it is. Someone used both to solve the same problem, so clearly they can be used in the same context and people will be interested to know the differences. It would be quite boring if we could only compare things that are exactly the same.
I think one thing that’s missing from the analysis in this post is that the point of Rust is to get memory safety in your applications, but a keyboard firmware has no need for memory safety.
I’ve never used Rust. I’ve never used Zig. But I have written three keyboard firmwares, all in different languages. In a keyboard firmware, there is never any need to allocate any memory at runtime. You can preallocate all the memory you need ahead of time, and it’s honestly not much more than a couple bits per key. This is just … vastly different from basically every program that runs on my computer.
The three firmwares are https://gitlab.com/technomancy/atreus-firmware, https://github.com/technomancy/orestes, and https://git.sr.ht/~technomancy/menelaus if you’re curious; the latter (which I still use every day) is 140 lines of code.
Yes and no ? AFAIK they do also position themself as c replacement (even stronger: dropin-replacement) for C. And try to fix the old issues C has. Similar features are async/await, though zig has this in a way you can create async and blocking functions at the same time. Rust tries to be an embedded platform (understandably), which zig also wants to be. And rust also wants to adopt configurable allocators (required for many embedded things), which zig already has.
But yeah they have different targets and features. I’d say zig tries to stay out of your way, while rust has stronger guarantees but requires you to do something for that.