This is the kind of review I love to see. Not just for languages, everything. In my experience, reviews almost exclusively come while something is still novel to the reviewer, not battle tested, and worse, conflated with whatever situations the reviewer just happens to find themselves in at that period of time.
What a wonderful post to be able to read and not have to wonder how much of it will hold up given a little time.
On the other hand, if you wait too long, you run the risk of being afflicted with the kind of Stockholm syndrome/curse of expertise that explains how bad so much of everything is.
When I start playing with something, once the number of papercuts I'm tracking in my head gets above 2–3, then I crack open a fresh notes.markdown file adjacent to the source repo (if there is one) and start recording all my thoughts in the vein of[1], including everything from outright bugs to opportunities for UI improvement. If the project has reasonable bugtracking infrastructure, I'll file them—or for small projects, I'll email the author along with any patches—but since most projects don't, I mostly don't end up doing anything with them. I've often thought that it would be nice if this exercise of "Let's Critique" became a thing, though. If nothing else, it could provide fuel for folks' blogs that have been lying dormant since that one post from 2017.
I was thinking about this today in reference to Elixir. I've noticed there seems to be less of the unalloyed fanboyism, and more realism in people's reported experiences with it now they've had a chance to use it for a few years. Reports still seem to be positive, but more balanced, which I think is the sign of a language ecosystem maturing.
I generally take breathless coverage of how brilliant some new language (or tech stack) is with a large pinch of salt. The foibles and pitfalls of modern languages are often hard to spot until people have code-bases that are at least a couple of years old. I think the good stuff is generally easier to see at first, while the problems (which are often consequences/side-effects of the good aspects) generally take longer to appear.
Programming languages seem to follow a variation of the Gartner Hype Cycle, with the twist that just after you get to the Plateau of Productivity and lots of people are quietly getting stuff done with it everyone starts to declare that "language X is dead/dying".
What is the best way to confront this problem? On paper languages like Rust, Elixir/Erlang, and Haskell stand out in non-trivial ways from other languages but as you say they require a considerable investment to evaluate properly. Either you risk years of wasted effort or potentially missing out on a game-changing tool.
Yes!!! I was looking at exercise equipment this week and badly wanted to find reviews for when people had been using it for years. That’s where 98% of the useful info is.
Otherwise reviews are pointless things like the packaging quality and shipment speed.
The issue with that is that oftentimes by the time something has been used for years, the manufacturer has discontinued the model, or even worse, kept the same model number and did some cost engineering to make the new version less durable.
I agree with you though that a lot of reviews are useless fluff like shipping speed and packaging, and that there should be a better way to evaluate products.
I'm not using this language because the syntax is really heavy and definitely not my cup of tea. I'm puzzled by the ambitions to market this language for the embedded world. The embedded world is full of electronics engineers that are writing code as part of their job. If experienced developers are finding this language overwhelming, how are you going to convince the electronics guys to adopt it instead of using plain old C? Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard...
Rust's type system is complicated for a reason. It makes explicit the reasoning that is necessary to allocate and access memory correctly without reference counting or garbage collection. Sure it is easier to start writing C but I believe it is overall faster to write and debug a Rust program because C requires additional sanitization and fuzzing to catch errors.
To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)
Given that C++ has barely made a dent in some of those domains, after 40 years of trying, any Rust advocacy towards that target market can take a lesson or two from why those engineers are unwilling to move beyond C89 + OEM specific extensions.
I think this profession is hard enough as it is. I don't think you need another daily source of annoyance like reading code with a difficult syntax or fighting meaninglessly with the borrow checker. I understand the motivations for this language, but I don't like the tradeoffs on a personal level. Definitely not my cup of tea.
The article and the links it references do a good job of explaining the arguments. A short summary:
* Rust's no_std means you can run bare metal with less memory overhead than even newlib based c
* no_std also makes it easier to port to new platforms, as nonportable parts are isolated out of the std lib
* algebraic data types and in particular enums that can carry disjoint associated data reduce the number of error prone magic constants and casts in your code, as well as catching all missing switch cases
* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase
* The borrow check makes you work more, but in many cases this is justified by it leading you to a less brittle design
The examples, particularly on cliff's blog post, make pretty convincing arguments oo these points imo.
I also wouldn't discount EEs so much. There's plenty of complexity to Verilog and all the other tools they use.
If you are using no_std isn't that the same as just not having a C standard library? I have been programming in C/C++ for over 25 years in ridiculously restricted contexts--even using it to compile tiny trampolines and the such--and I have no clue what you might mean that Rust could possibly have a smaller runtime library than C's "literally it comes with and uses nothing as the C standard library is nothing more than an optional library that most embedded people don't use".
* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase
I have seen this argument a couple of times before. But I can't make myself buy it.
Because I always have to think about embedded systems in the car industry. Look at this list:
The argument is basically "the possible fail places are easily grepable", right?
I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance.
So how does Rust prevent something like this throughout the code base (and those are BIG code bases):
> If experienced developers are finding this language overwhelming, how are you going to convince the electronics guys to adopt it instead of using plain old C?
Because embedded software is increasingly networked (BLE, TCP/IP, ZigBee, etc.) and you can continue writing your communication stacks in C and having memory corruption security vulnerabilities or you can suck it up and try something else for once.
> Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard...
1) The embedded world has effectively converged on ARM. This means that the toolchain is whatever ARM shoves out and HALs and SDKs will comply or get no traction.
It also means that you can use actual, real software tooling (VSCode, Meson, Ninja, etc.) instead of "Yet Another Broken Vendor IDE". It's soooo compelling that I personally can run rings around some vendor teams. To be fair--this is NOT limited to Rust. VSCode and its ecosystem enables even C programmers to be stupidly more productive. However, the embedded Rust folks seem to rattle the VSCode folks cage quite a bit more than just plain embedded C folks--this keeps the VSCode guys quite a bit more honest about cross-platform support.
2) Anything RISC-V is in flux, and folks like Bryan Cantrill are leading the charge so the toolchain will be forced to accommodate more than "just C".
3) Even if Rust isn't the answer, you should root for its tooling to break the C hegemony. If Rust finally forces C tooling to acknowledge that "Hey, just maybe we should think about playing nicely in the sandbox and have some useful API's instead of telling everybody to cope or leave because we're the 500lb gorilla.", the successor to Rust will have a vastly easier time.
See. Not all the problems in embedded are network security risks. If you are evangelizing Rust, please stop trying to lure embedded developers with "networks haxxor buffer overflow" FUD because it's simply not going to work.
For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. Edit to add: is not that security bugs are not important, but is not what we (embedded developers) are always chasing or taking away our sleep at night. Embedded is wide enough beyond computer networks.
Please take a look at the room around you. Can you count every little chip in there? Including the one in your keyboard, LED lamps, coffee machine? Are all these ARM? NO. Are all these connected to the network? NO. Do you expect them to work 100% of the time without hiccups? YES, and they probably do without you noticing it.
And they are probably running 1000s of lines of C. That's embedded.
I can understand you. This is the reason, I miss lisp. Why language designers ignore syntax ? Syntax should be CONSISTENT, INTUTIVE and LESS AMBIGUOS (there should be one good way to do thing). As a enduser, I want to focus on solving problem at hand, instead tackling/remembering language syntax/quirks(and new apis).
Let me give a very simple example in golang. Function returning single value and function returing multiple values.
func foo(x int, y int) int {}
func bar(x int, y int) (int, int) {}
Even though below synatx works,
func bar(x int, y int)(int) {}
why there is a additional way to do it by removing parenthesis ?
This looks very simple example. But it breaks consistancy of syntax. Adds 2 rules to remember over what saving 2 keystrokes ? In the age of 100x full stack devs, life really sucks.
I am an embedded software dev and Rust would fit my job well, but I see what you are saying. However, embedded is not all for Rust and not all embedded is done by EEs. Systems programming goes from bare metal up to things like browsers and databases...
It's a large field. I don't think anyone in the Rust world expects it to make a large dent against embedded C anytime soon - rather a subset of embedded developers who would like to not have to use just C are working on it because they would personally want something "better" for their niches. And as the article describes, Rust has good foundations to be able to fit that role, compared to many other languages.
Great post, especially for the embedded crowd. I'm looking to start using Rust in FW development but hit a couple pain points.
* First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.
* Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
* Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
I would love to be proven wrong, because I have an OS to write, and would love to use Rust.
> First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust
“A litany of constants” is exactly what your c enum is though.
And you can define a "degenerate" Rust enum with explicit discriminant values:
enum Foo {
A = 1,
B = 2,
C = 4
}
They are cast-able to integrals too:
println!("{}", Foo::C as usize); // prints "4"
Doesn’t work so well for flags however.
> Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
The alternative would be to simply not make the feature available at all until it is done and ready, with even higher risk (as it would have been exercised even less).
As is, if the feature is fine for you as-is you can use it, and if you can't or don't want to use nightly you can go and assist its shepherding to stable (https://github.com/rust-lang/rust/issues/72016)
> while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
There are no safe Rust-level variadics, but Rust can call C variadic functions, and under RFC 2137 (not stable yet I think) define them as well.
> * First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.
With my Rust language team hat on: we'd love to have native support for bitfields. I'd invite folks who are interested in that to propose a language MCP ("major change proposal"), which I'd expect to be approved, and then collaborate on a spec for them.
>First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables.
You still have to give the literal value of the field instead of using the auto-incrementing enum but that's how I do it in C as well, I find it too error-prone otherwise. And how do you deal with fields that take up multiple bits anyway?
>Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
I agree 100%. I can understand them prioritizing higher level system programing and taking the time to do asm right, but it does make it a bit of a pain to do bare metal Rust at the moment.
>Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
What do you have in mind here? format! is strongly typed and a lot more flexible than printf. You can't even print custom structs with printf... Actually even printing standard types like uint32_t and friends require macro soup to work portably.
Variadic arguments are pretty much a no-go for a strongly typed, static language since you would need a lot of trickery to get it to work safely under the hood (hence format! being a macro).
But what use case do you have for printf that can't be implemented with println!/format! and friends?
> But what use case do you have for printf that can't be implemented with println!/format! and friends?
I'm guessing they mean that the format! machinery is rather complex and brings in a lot of code. That it's also somewhat slow is a recurring concern .
Have none of the embedded folks created a specialised version of format! which is not generic, and basically only supports the types and styles which c's printf supports?
I've jumped on plenty of hype trains of new languages over the last 20 years. Rust is the first one that made we actually worry that I might have to eventually switch back to different language in the future. In addition, it's the first language that doesn't have me use Python for quick shell scripting or small prototypes. It's a pleasure to code in.
I love rust, but Python is still my goto for scripting, small tasks, calculations, etc. It's more convenient for nearly all tasks of that shape.
I remember telling my uni professor about that 15 years ago, but she swore by using C for that purpose. It's what you know I suppose, but if you know both languages, Python is much better suited to the task.
This is not an objective opinion, but subjective. People generally appreciate different things about different languages, and it’s entirely possible for some who knows both languages to disagree with you here.
For quick CLI tools, my favorite thing about Rust is that it has really high quality command line parsers available in the community, and they are type safe.
I’m not suggesting that your opinion is wrong, only that the way you phrased it implies that many people could come to the same objective opinion, while there’s plenty of evidence that folks pick languages they enjoy and prioritize different things than you might.
Unless you're writing libraries, Rust feels a lot like Python.
One thing that sticks out in a scripting mindset is the various string types, but I mostly accept that as a small price to pay for doing things correctly (OS strings vs. UTF-8 vs. C strings).
Because of the kinds of things I build with Rust, I've had to write quite a few cargo build scripts (build.rs files), which are very bash/Python script-y in nature. Not once have I wished for a different language!
it's the first language that doesn't have me use Python for quick shell scripting or small prototypes
How do you define quick? Python has a large standard library and so you don't have to hunt for functionality on crates.io and then download/compile -- I have written scripts faster than that.
The Python standard library is amazing. A few weeks ago, I wrote a program that provides a SMTP relay, mail storage, and web UI for managing email sequencing. The only dependency that it pulled in was pywin32 so it could run as a windows service; if it ran on a Linux box, there wouldn't be a single dependency.
Not including integration testing, the whole deal was two days of work. If I had to pull in and evaluate external libraries I would have spent two days just working out the details of which libraries to select.
At least for now, I don't think anything can replace Python for prototyping an idea.
If you know that a crate exists then you can simply `cargo add foo` and have it download in the background while you get on with writing your script. If you don't know that it exists then you'll have to find it the first time, but you have that problem with python standard library modules too.
Writing scripts with Rust likely will be slower than Python, but I don't really buy that having functionality in crates is part of that.
Had you ever used an ML-family language before Rust? I hear lots of excitement about Rust but it seems to mostly be about things that I already have in the languages I was using.
We have a Windows working group that does far more work than I do; honestly, I mostly am just a visible person who uses Windows, more than an expert or someone who fixes a lot of big problems. I do file bugs and patch things where I can.
Personally I used to think I couldn't develop comfortably on Windows, but Rust's tooling is so integrated under the Cargo umbrella that I've never run into a real issue getting it working there, and I rarely even find myself needing to do "real command-line" stuff while working with Rust. A single tool has it all covered, so I don't really have to write scripts or anything. I'm sure the story is less simple for embedded, but I'm not surprised it's totally doable.
This is a good list of positives. I'm surprised there's no mention of bitfields though.
I like the u32::from_le_bytes and into() and so on, but I feel like Rust would be a perfect match for explicit "u3" types when dealing with low-level protocols.
https://immunant.com/blog/2020/01/bitfields/ and similar articles show some options, but none of them feel as natural (ergonomics wise) or even as "safe" as a C bitfield checked by clang.
bcantrill (or others): am I just missing something here?
No, you're not missing something -- this is an area that I would say is (to use a winter weather term) "unsettled." The Immunant blog entry you pointed to is quite good, and lays out all of the existing solutions and the issues with them. Better solutions are definitely possible here, and I'm confident that we'll see them over time. Especially given the incredible obstacles that Rust has overcome with respect to low-level software (e.g., no_std, asm!), making bitfields more ergonomic seems like a very reasonable aspiration, especially considering how many others see the same problem!
Re-reading the end of that post, I’m reminded that Josh had a talk about potential improvements.
I only return to Rust about once or twice a year (currently) and keep cutting myself on an ergonomics thing like this. But I’ve also seen it improve year over year at a remarkable pace. So I’m hopeful, but also always wondering “huh, am I holding the phone wrong?”.
Disclaimer: I haven’t used bitflags (but I don’t think it applies for my need).
The nginx example in the above blog post seems like a bitfield! equivalent would be... unpleasant.
For very small structs that are just only wire formats, I might use bitfield!. But encoding/decoding protocol headers (e.g., a VP8 header [1], which has a 19-bit “size” field) or interop with other systems where you’d like some checking a la serde, bitfield! seems more verbose than “fine, I’ll do it myself right here against the u8”.
That is, even if that nginx example had a two-bit field in there, I’d take everything at the end and round up to a u8. Then read/write some of these “by hand”, rather than pollute the struct with lots and lots of macro “noise”.
I have an (in-progress, but usable) project for generating rust code for parsing and generating these kinds of protocols: https://github.com/mwylde/protogen/tree/to_vec. It supports integers of arbitrary bit sizes up to 64.
I was curious to see what you chose to do for representing arbitrary bit width. I didn't see an example / test for something like u19 though.
Your backend compilation seems to generate calls to an arbitrary width [1], but I only see explicit 8/16/32/64s generated or tested [2]. The code definitely seems ready for size != width, and answering some of my question "sizes less than 8 round up to u8, otherwise round up to nearest power of 2" [3].
Either way, it looks like a great start! Your little language seems like it probably has enough in it already for my VP8 example.
Be careful with C and bitfields, as they can be a minefield too. First, always use an unsigned integral type for them, and second, be careful with bitfield packing rules -- maybe just use 1-bit fields only even.
I find it interesting the article didn't mention compile times at all. Maybe since Oxide mostly works with embedded, they have few dependencies and their compile times aren't very bad? I know my primary complaint after working with the language for about a year is that most projects take over a minute to build. Of course, it doesn't help that I keep moving onto larger projects xD but even small things like cargo-deadlinks and ripgrep take a while.
Funny story, I've actually been working on reducing our compile times lately. We had a conversation about this when I started the work, Brian just doesn't have a ton of sensitivity to this in general. I apparently have more :)
There are details that matter, but on the codebase I work on, the current worst case (before the work I've been doing) means a compile takes a couple of minutes; more like two than five. I'm not sure how other codebases at the company are with regards to this, but I don't think they're super long.
What I've been doing drops it to under thirty seconds in basically all cases.
So yeah, it hasn't been a super pain for us specifically. We'll see as time goes on :)
> What I've been doing drops it to under thirty seconds in basically all cases.
Is that for full builds or incremental? 30 seconds for a full build is reasonably fast (for rust, still feels slow IMO) but if that's incremental it sounds _painful_.
I recently updated some Rust code I wrote months ago (~April). In the 6 months since apparently its compile time went down from 6m30s to just around 4mins! I know there's been a focus on improving compile time and it's awesome to see in practise too.
Out of curiosity - what hardware are you using ? I kept hearing this but recently started playing with it and haven't found it limiting probably because I haven't used it enough yet. Still I'm curious if this is a problem top of the line HW setup can alleviate.
Honeymoon meets guerilla marketing. After a point the lines between a technical blog post, personal brand building and advertising for one's startup/new project become too blurry...
Makes one long for the days when ads were shown in pop-ups and you could at least close them. And the ad people did warn us this would happen :-)
I think a better analogy here might be Citizen Kane.
From a foreigner's perspective, Citizen Kane is a (very) good movie but really nothing special. I enjoyed Rashomon a lot more. However, Rashomon was clearly inspired by it. To really understand the appeal and significance of CK, you have to compare it to movies before it. The reason CK doesn't amaze many people anymore is because everyone now uses these cinematographic techniques! In similar vein, the first Half Life game was groundbreaking and pioneered new ways of story telling. But if you don't remember earlier games, you may be scratching your head.
Every now and then a programming language comes out that is a gamechanger. Such a language won't get out of fashion unless new programming languages start building upon it. I can't say if Rust is one of them.
I don't have a long career in programming, and I know only a few languages, but I'd say Python is one of the languages that managed to set the bar for others. It's still going strong, but it's no longer turning heads with its usability and clear syntax.
Readit News
What a wonderful post to be able to read and not have to wonder how much of it will hold up given a little time.
When I start playing with something, once the number of papercuts I'm tracking in my head gets above 2–3, then I crack open a fresh notes.markdown file adjacent to the source repo (if there is one) and start recording all my thoughts in the vein of[1], including everything from outright bugs to opportunities for UI improvement. If the project has reasonable bugtracking infrastructure, I'll file them—or for small projects, I'll email the author along with any patches—but since most projects don't, I mostly don't end up doing anything with them. I've often thought that it would be nice if this exercise of "Let's Critique" became a thing, though. If nothing else, it could provide fuel for folks' blogs that have been lying dormant since that one post from 2017.
1. https://pointersgonewild.com/2019/11/02/they-might-never-tel...
I generally take breathless coverage of how brilliant some new language (or tech stack) is with a large pinch of salt. The foibles and pitfalls of modern languages are often hard to spot until people have code-bases that are at least a couple of years old. I think the good stuff is generally easier to see at first, while the problems (which are often consequences/side-effects of the good aspects) generally take longer to appear.
Programming languages seem to follow a variation of the Gartner Hype Cycle, with the twist that just after you get to the Plateau of Productivity and lots of people are quietly getting stuff done with it everyone starts to declare that "language X is dead/dying".
Elixir is great at what it does, but I wouldn't use it for building a CLI tool or something like that.
Otherwise reviews are pointless things like the packaging quality and shipment speed.
I agree with you though that a lot of reviews are useless fluff like shipping speed and packaging, and that there should be a better way to evaluate products.
1: https://news.ycombinator.com/item?id=24707407
To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)
I dress slowly because I’m in a rush.
"Time is money".
;-).
Edit: Corrected typo.
* Rust's no_std means you can run bare metal with less memory overhead than even newlib based c
* no_std also makes it easier to port to new platforms, as nonportable parts are isolated out of the std lib
* algebraic data types and in particular enums that can carry disjoint associated data reduce the number of error prone magic constants and casts in your code, as well as catching all missing switch cases
* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase
* The borrow check makes you work more, but in many cases this is justified by it leading you to a less brittle design
The examples, particularly on cliff's blog post, make pretty convincing arguments oo these points imo.
I also wouldn't discount EEs so much. There's plenty of complexity to Verilog and all the other tools they use.
https://betterembsw.blogspot.com/2018/09/potentially-deadly-...
The argument is basically "the possible fail places are easily grepable", right? I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance.
So how does Rust prevent something like this throughout the code base (and those are BIG code bases):
"LOL. I need to get this done. unsafe { ... } "
Because embedded software is increasingly networked (BLE, TCP/IP, ZigBee, etc.) and you can continue writing your communication stacks in C and having memory corruption security vulnerabilities or you can suck it up and try something else for once.
> Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard...
1) The embedded world has effectively converged on ARM. This means that the toolchain is whatever ARM shoves out and HALs and SDKs will comply or get no traction.
It also means that you can use actual, real software tooling (VSCode, Meson, Ninja, etc.) instead of "Yet Another Broken Vendor IDE". It's soooo compelling that I personally can run rings around some vendor teams. To be fair--this is NOT limited to Rust. VSCode and its ecosystem enables even C programmers to be stupidly more productive. However, the embedded Rust folks seem to rattle the VSCode folks cage quite a bit more than just plain embedded C folks--this keeps the VSCode guys quite a bit more honest about cross-platform support.
2) Anything RISC-V is in flux, and folks like Bryan Cantrill are leading the charge so the toolchain will be forced to accommodate more than "just C".
3) Even if Rust isn't the answer, you should root for its tooling to break the C hegemony. If Rust finally forces C tooling to acknowledge that "Hey, just maybe we should think about playing nicely in the sandbox and have some useful API's instead of telling everybody to cope or leave because we're the 500lb gorilla.", the successor to Rust will have a vastly easier time.
For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. Edit to add: is not that security bugs are not important, but is not what we (embedded developers) are always chasing or taking away our sleep at night. Embedded is wide enough beyond computer networks.
Please take a look at the room around you. Can you count every little chip in there? Including the one in your keyboard, LED lamps, coffee machine? Are all these ARM? NO. Are all these connected to the network? NO. Do you expect them to work 100% of the time without hiccups? YES, and they probably do without you noticing it.
And they are probably running 1000s of lines of C. That's embedded.
Let me give a very simple example in golang. Function returning single value and function returing multiple values.
func foo(x int, y int) int {}
func bar(x int, y int) (int, int) {}
Even though below synatx works,
func bar(x int, y int)(int) {}
why there is a additional way to do it by removing parenthesis ?
This looks very simple example. But it breaks consistancy of syntax. Adds 2 rules to remember over what saving 2 keystrokes ? In the age of 100x full stack devs, life really sucks.
* First, bit field descriptors is a huge pain - where, in C, you would define an enum for the task, there isn't a real equal in vanilla Rust, other than a litany of constant variables. * Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard. * Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
I would love to be proven wrong, because I have an OS to write, and would love to use Rust.
“A litany of constants” is exactly what your c enum is though.
And you can define a "degenerate" Rust enum with explicit discriminant values:
They are cast-able to integrals too: Doesn’t work so well for flags however.> Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
The alternative would be to simply not make the feature available at all until it is done and ready, with even higher risk (as it would have been exercised even less).
As is, if the feature is fine for you as-is you can use it, and if you can't or don't want to use nightly you can go and assist its shepherding to stable (https://github.com/rust-lang/rust/issues/72016)
> while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
There are no safe Rust-level variadics, but Rust can call C variadic functions, and under RFC 2137 (not stable yet I think) define them as well.
For lighter weight formatting there is https://github.com/japaric/ufmt
Is this (C-style enums) new?
I swear I looked for it a year or two back, found questions about it, with the answers "use constants".
With my Rust language team hat on: we'd love to have native support for bitfields. I'd invite folks who are interested in that to propose a language MCP ("major change proposal"), which I'd expect to be approved, and then collaborate on a spec for them.
Have a look at the bitlags crate, I use it a lot for this purpose: https://docs.rs/bitflags/1.2.1/bitflags/
You still have to give the literal value of the field instead of using the auto-incrementing enum but that's how I do it in C as well, I find it too error-prone otherwise. And how do you deal with fields that take up multiple bits anyway?
>Second, the over-reliance on nightly is a tough sell for - having inline asm gated makes it very hard.
I agree 100%. I can understand them prioritizing higher level system programing and taking the time to do asm right, but it does make it a bit of a pain to do bare metal Rust at the moment.
>Third, while format is great, it's also very heavyweight. Not having (AFAIK) variadic arguments is hard, and there isn't really an equal to printf.
What do you have in mind here? format! is strongly typed and a lot more flexible than printf. You can't even print custom structs with printf... Actually even printing standard types like uint32_t and friends require macro soup to work portably.
Variadic arguments are pretty much a no-go for a strongly typed, static language since you would need a lot of trickery to get it to work safely under the hood (hence format! being a macro).
But what use case do you have for printf that can't be implemented with println!/format! and friends?
I'm guessing they mean that the format! machinery is rather complex and brings in a lot of code. That it's also somewhat slow is a recurring concern .
Have none of the embedded folks created a specialised version of format! which is not generic, and basically only supports the types and styles which c's printf supports?
edit: there's ufmt though it seems somewhat inactive and I've no idea how good it is: https://github.com/japaric/ufmt
> Optimized for binary size and speed (rather than for compilation time)
> No dynamic dispatch in generated code
https://defmt.ferrous-systems.com/
(And consider sponsoring them if this is of value to you: https://ferrous-systems.com/blog/knurling-one-month/.)
That sounds awesome. Personal project or commissioned?
I remember telling my uni professor about that 15 years ago, but she swore by using C for that purpose. It's what you know I suppose, but if you know both languages, Python is much better suited to the task.
This is not an objective opinion, but subjective. People generally appreciate different things about different languages, and it’s entirely possible for some who knows both languages to disagree with you here.
For quick CLI tools, my favorite thing about Rust is that it has really high quality command line parsers available in the community, and they are type safe.
I’m not suggesting that your opinion is wrong, only that the way you phrased it implies that many people could come to the same objective opinion, while there’s plenty of evidence that folks pick languages they enjoy and prioritize different things than you might.
One thing that sticks out in a scripting mindset is the various string types, but I mostly accept that as a small price to pay for doing things correctly (OS strings vs. UTF-8 vs. C strings).
Because of the kinds of things I build with Rust, I've had to write quite a few cargo build scripts (build.rs files), which are very bash/Python script-y in nature. Not once have I wished for a different language!
How do you define quick? Python has a large standard library and so you don't have to hunt for functionality on crates.io and then download/compile -- I have written scripts faster than that.
Not including integration testing, the whole deal was two days of work. If I had to pull in and evaluate external libraries I would have spent two days just working out the details of which libraries to select.
At least for now, I don't think anything can replace Python for prototyping an idea.
Writing scripts with Rust likely will be slower than Python, but I don't really buy that having functionality in crates is part of that.
Thanks Steve!
We have a Windows working group that does far more work than I do; honestly, I mostly am just a visible person who uses Windows, more than an expert or someone who fixes a lot of big problems. I do file bugs and patch things where I can.
I like the u32::from_le_bytes and into() and so on, but I feel like Rust would be a perfect match for explicit "u3" types when dealing with low-level protocols.
https://immunant.com/blog/2020/01/bitfields/ and similar articles show some options, but none of them feel as natural (ergonomics wise) or even as "safe" as a C bitfield checked by clang.
bcantrill (or others): am I just missing something here?
I only return to Rust about once or twice a year (currently) and keep cutting myself on an ergonomics thing like this. But I’ve also seen it improve year over year at a remarkable pace. So I’m hopeful, but also always wondering “huh, am I holding the phone wrong?”.
We use https://crates.io/crates/bitfield, and some of our dependencies use https://crates.io/crates/bitflags. They're not perfect, but they get the job done.
The nginx example in the above blog post seems like a bitfield! equivalent would be... unpleasant.
For very small structs that are just only wire formats, I might use bitfield!. But encoding/decoding protocol headers (e.g., a VP8 header [1], which has a 19-bit “size” field) or interop with other systems where you’d like some checking a la serde, bitfield! seems more verbose than “fine, I’ll do it myself right here against the u8”.
That is, even if that nginx example had a two-bit field in there, I’d take everything at the end and round up to a u8. Then read/write some of these “by hand”, rather than pollute the struct with lots and lots of macro “noise”.
[1] https://tools.ietf.org/html/rfc6386#section-9.1
I was curious to see what you chose to do for representing arbitrary bit width. I didn't see an example / test for something like u19 though.
Your backend compilation seems to generate calls to an arbitrary width [1], but I only see explicit 8/16/32/64s generated or tested [2]. The code definitely seems ready for size != width, and answering some of my question "sizes less than 8 round up to u8, otherwise round up to nearest power of 2" [3].
Either way, it looks like a great start! Your little language seems like it probably has enough in it already for my VP8 example.
[1] https://github.com/mwylde/protogen/blob/f812dd74e5cebe680422...
[2] https://github.com/mwylde/protogen/blob/f812dd74e5cebe680422...
[3] https://github.com/mwylde/protogen/blob/f812dd74e5cebe680422...
There are details that matter, but on the codebase I work on, the current worst case (before the work I've been doing) means a compile takes a couple of minutes; more like two than five. I'm not sure how other codebases at the company are with regards to this, but I don't think they're super long.
What I've been doing drops it to under thirty seconds in basically all cases.
So yeah, it hasn't been a super pain for us specifically. We'll see as time goes on :)
Is that for full builds or incremental? 30 seconds for a full build is reasonably fast (for rust, still feels slow IMO) but if that's incremental it sounds _painful_.
tl;dr if you have a lot of dependencies more cores help a lot. If not, you hit diminishing returns; top hardware _helps_ but it's still painful.
Does that happen for some couples?
Makes one long for the days when ads were shown in pop-ups and you could at least close them. And the ad people did warn us this would happen :-)
From a foreigner's perspective, Citizen Kane is a (very) good movie but really nothing special. I enjoyed Rashomon a lot more. However, Rashomon was clearly inspired by it. To really understand the appeal and significance of CK, you have to compare it to movies before it. The reason CK doesn't amaze many people anymore is because everyone now uses these cinematographic techniques! In similar vein, the first Half Life game was groundbreaking and pioneered new ways of story telling. But if you don't remember earlier games, you may be scratching your head.
Every now and then a programming language comes out that is a gamechanger. Such a language won't get out of fashion unless new programming languages start building upon it. I can't say if Rust is one of them.
I don't have a long career in programming, and I know only a few languages, but I'd say Python is one of the languages that managed to set the bar for others. It's still going strong, but it's no longer turning heads with its usability and clear syntax.