It’s a bit of a silly post, because syntax is the least interesting d detail about the language, but, still, I can’t stop thinking how Zig gets this detail just right for the class of curly-braced languages, and, well, now you’ll have to think about that too.
On the first glance, Zig looks almost exactly like Rust, because Zig borrows from Rust liberally. And I think that Rust has great syntax, considering all the semantics it needs to express (see “Rust’s Ugly Syntax”). But Zig improves on that, mostly by leveraging simpler language semantics, but also through some purely syntactical tasteful decisions.
↫ Alex Kladov
Y’all know full well I know very little about programming, so there’s much interesting stuff I can add here. The only slightly related frame of reference I have is how some languages – as in, the ones we speak – have a pleasing grammar or spelling, and how even when you can’t actually speak a language, some of them intrinsically look attractive and pleasing when you see them in written form.
I mean, you can’t look at Scottisch Gaelic and not notice it just looks pleasing:
Dh’ éirich mi moch air mhaduinn an-dé
↫ Mo Shùil Ad Dhèidh by Donald MacNicol
‘S gun ghearr mi’n ear-thalmhainn do bhrìgh mo sgéil
An dùil gu ‘m faicinn fhéin rùn mo chléibh
Och òin gu ‘m faca ‘s a cùl rium féin.
I have no idea if programmers can look at programming languages the same way, but I’ve often been told there’s more overlap between programming languages and regular language than many people think. As such, it wouldn’t surprise me if some programming languages look really pleasing to programmers, even if they can’t use them because they haven’t really learned them yet.
I’m going to have to disagree with matklad. He’s certainly a big enough part of creating Rust’s developer tooling to know why Rust made the decisions it did, but failing to acknowledge those makes this post feel like a shallow expression of personal taste without much being effectively communicated.
I just don’t get it.
Zig’s “comptime_int” type sounds like Rust’s “{integer}”. (You can write an integer literal with no intrinsic type hint and “The value of an integer literal is known at compile time and is coerced to a specific type on assignment”.)
Is matklad praising that Zig omits one of Rust’s three syntaxes for achieving that goal?
let a: u32 = 9;
let a = 9u32;
let a = 9 as u32;
Also, Zig’s “@as(i32, 92)” doesn’t look prettier than Rust’s “92 as i32” to me.
Yes, I suppose Rust COULD have done another compiler-built-in-macro like println! (built-in because it predates procedural macro support) and made it something like as!(i32, 92), but people already complain enough about the need to explicitly convert integer sizes… so I’d argue it’s only prettier from a LISPy “have as few linguistic primitives, with as much generality as possible” standpoint… something matklad’s later complaints indicate isn’t what’s being aimed for.
Good points on the parsing advantages of their approach… but all that depends on not using double quotes to delimit the string and anyone who’s been kicking around Rust’s development process as long as matklad and I will recognize that Rust already takes enough flack for the alienness of the bits of Ocaml syntax it did borrow for lack of a C++ equivalent.
I don’t think they could get away with a syntax that feels like it took a little too much YAML in its coffee.
I’ll grant that Rust doesn’t currently have a pretty way to do multi-line strings while ignoring leading indentation so they match the rest, but that’s what the indoc! macro from the crate of the same name is for. Also, with crates like that having had time to explore the space, did matklad miss the announcement of RFC 3830: dedented string literals , currently under discussion, in places like This Week in Rust?
This is another case of “I acknowledge the advantage to this syntax… but I’m not sure Rust had the weirdness budget to spare, given that it’s entirely possible to never stumble into discovering the advantage the syntax brings without being told”.
(I’m also not sure how to take it, given that matklad wrote another post about what a pain some of Rust’s design decisions make developing IDE smarts he’s worked on like the IntelliJ Rust plugin and rust-analyzer. If you’re so into IDE assists that you develop them, and you’ve been around long enough that you should have at least picked up the syntax design philosophy through osmosis… why are you giving this so much attention?)
OK, you lost me here. That’s even worse on the weirdness budget and, unless you were brought up in a language that reads right-to-left, the absolute REVERSE of what makes sense.
?[3]u32 // An array of three integers or null
…more like “null or an array of three of type u32” if I’m being charitable.
For the same reason QWERTY still continues to win out over Dvorak (because any Intro to Human-Computer Interaction textbook will tell you of how overwhelming the value is for consistency with what came before), I’d expect at least “u32[3]?”… but Rust probably would have gone with “[u32; 3]?” if Option were a sigil instead of a standard library type, since they already use “[u32]” for “slice of u32” and “[u32; 10]” for “array of u32, 10-long”.
(And Rust moved AWAY from using sigils shortly before the syntax was stabilized within a year of dropping the Go-esque green threading runtime, to give freedom for projects to implement custom types with the same degree of integration that the provided ones have.)
…do you think “raw identifiers”, including ones containing spaces, are a good thing that shouldn’t feel like a code smell when typed?
As I remember it, Rust only introduced r#whatever for raw identifiers to make it easy to mechanically upgrade code to a new edition where the identifier in question has become a reserved word.
Hell, Rust specifically adds compile-time errors for certain Unicode identifier shenanigans that other languages allow.
…to be fair, this does seem to embody the philosophical divide between Zig and Rust. Zig is still of the C “trust the programmer knows what they’re doing” mould, while Rust’s design philosophy explicitly involves the phrase “pit of success”, which has an explicit element of “code smells should look ugly” in its syntax.
Again, alienness budget. Rust’s use of “->” to denote a function return type is commonplace in the world of academic and functional programming languages and, in a slightly different role, present in Rust’s progenitor, Ocaml. It’s also very similar to JavaScript’s “arrow function” syntax, which uses => instead of ->.
But that would be misrepresenting things to the developer and, as someone developing what is essentially a partial Rust compiler, you should be aware of it.
Rust’s empty return type is () because a function return is a tuple and () is a zero-element tuple.
Hell, in C, “void” is a special reserved keyword that serves two hacky purposes:
1. As a placeholder akin to “auto” in C++, to work around the limitation of doing “return_type foo” instead of “fn foo”
2. As something you put into the function argument list to opt out of original C’s JavaScript-esque function argument semantics.
As K&R put it:
In a sense, preferring “void” could be thought of as stockholm syndrome. You’re so used to the hack to work around a buggy syntax that you now want it elsewhere.
“val” to mean “const”/”final”?
I’ve been arguing against “val” on a proposal to add “assignable once” variables to Godot’s GDScript as a way to have “const”, but for stuff that can’t actually be a compile-time constant, such as values from the IDE’s property inspector, and not only did I argue against that, I saw someone actually make the val/var typo that I was arguing against in that very thread, and “r” and “l” aren’t THAT visually different as far as letters go.
This is antithetical to the “Code is read more than it’s written” part of Rust’s design philosophy… though I suppose one could argue that it’s in line with Zig’s effort to be a modernized expression of C’s “trust the lone rockstar coder to know what he’s doing” design philosophy. (I certainly don’t trust “myself from five years ago”. That guy’s an idiot.)
Makes sense and, as a Rust/Python programmer, you won’t see me arguing.
I’m assuming Rust chose “&&” and “||” as part of saving up for their weirdness budget by copying C++ whenever they could.
Most of this lands as “I don’t personally find value in Rust’s approach to being an expression-oriented language, so I don’t like the syntax that enables it”, which makes it of little persuasive value to me.
I certainly wouldn’t want to give up the ability to have a block expression return a value so I can cleanly and elegantly limit the lifespan of temporaries and, to my Rust eyes, the labelled block approach Zig has looks like it’s saying “Returning a value from a block is a code smell. Try to avoid it.”
Given “Everything Is an Expression” further down, I think this is a perfect example of “you really need to argue your point better”. As-is, I think you’d need to have experience with both Rust and Zig to have confidence that you understand what’s being argued for… and by then, wouldn’t you have already discovered or formed your own opinions on everything this post is saying?
As a Python programmer, I can certainly see the value in “else” clauses for “for” loops… but I also remember what a weird thing they were to teach. “else” running on early exit from a loop is a weird association to draw and I can definitely see why it was thrown on the same discard pile as making braces optional for single-element if/else bodies and disallowing assignment in control flow test expressions.
Hell, Python eventually added assignment in control flow test expressions via := which is known as the walrus operator.
As someone who spent a lot of time in Python, I agree. The language is much cleaner and easier to evolve if all tokens share the same namespace.
I’m not a Zig programmer, so I can’t say with confidence that I understand what a “comptime closure” is… but, given what I know about comptime, I think the answer to this is falls under the same answer as many other cases where Rust chose not to go the Zig comptime route… because comptime intermingles interface and implementation in ways Rust was explicitly designed to stay far away from in the name of making it easier to maintain API stability as a codebase evolves.
Huh… so it’s now sounding like Zig’s “comptime_int” mentioned in “Integer Literals” is unlike Rust’s “{integer}” in the most counter-intuitive and unhelpful way possible for common-case uses of it.
Yes, I can see “But this doesn’t kick the can sufficiently far enough” potentially being useful if Zig were going for Ada-esque subtyping tricks… but that’s clearly not what Zig is going for in other places. By your own statement, it’s the definition of the kind of “implementation details leaking into what the user is allowed to do in ways liable to induce frustration” that boats mentioned as the big reason Rust can’t have higher-kinded types for lack of a fundamentally currying-based syntax.
Yeah, people have been arguing for anonymous structs since the beginning… that doesn’t change that they have complex implications… especially if paired with the anonymous enums that people also argue for.
Pushing to lean further from structural typing toward nominal typing is no quick and dirty decision.
I disagree. I think you’re conflating objective and subjective statements. As someone with varying degrees of experience in BASIC, Bash, C, C++, CoffeeScript, CSS, DOS Batch, GDScript, HTML, Java, JavaScript, Lua, Pascal, Perl, PHP, Prolog, Python, Rust, Visual Basic, x86 assembly, XUL, XSL, and probably other languages I’m forgetting, I find some of the things you praise to be quite ugly and undesirable compared to how Rust does them.
And that logic leads to assembly language. Rust’s features exist to serve a purpose and that purpose is one reason Rust is making its way into places like the Windows kernel so quickly and not “C but done right” languages like D or Zig. As the paraphrase of Einstein goes, “Everything should be made as simple as possible, but not simpler.”
ssokolow,
Firstly, excellent commentary, thank you – enjoyed reading it. On a related note, C23 now changes the meaning of a function with no parameters declared to explicitly mean the same thing as one with ‘void’.
I’ve been porting my PlayStation emulator to Rust (and in the process actually finishing/redesigning it). I have very much enjoyed the process so far. Particular the expression based nature of it. Fully agree it makes things far cleaner.
I see the appeal of languages like Zig, and wish them well – indeed the same spirit that engenders my love for C will always have a place in my heart. But in my mind, Rust is a genuine game changer.
Regards,
Phil
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
I agree it’s very subjective. I very much appreciate your commentary. I have so much appreciation for what rust have done on the safety side, although I’m clearly not as fond of rust’s syntax as you. Unfortunately I think this opinion is common with mainstream C/C++/C# devs and it’s held back rust adoption.
D-lang’s managed memory is not suitable for system programming. I find Dlang’s choice to go with managed memory regrettable because that makes it unfit for purpose whereas in almost every other way D-lang could have been an excellent successor to C/C++. As is, it shares a lot more space with C#, which is fine but C# is more popular and more mature so Dlang isn’t compelling in that space either. Syntactically D lang really solves a lot of C’s legacy problems and I wish Rust and D-lang could have worked together somehow to create a safe language that genuinely feels like a C++ successor in a way that rust just does not. I agree with you that the syntax is very subjective and arbitrary, but when you’re trying to convince the world to migrate to safe languages, unfortunately rust’s syntax inadvertently created an additional barrier to adoption on top of safety, which increases resistance.
…which is funny, because the “ugliness” that so many non-C++ programmers complain about is caused by an explicit decision to use C++ syntax everywhere unless there was a very good reason not to (eg. Lexer Hack, Most Vexing Parse, various features missing from C++ entirely), and then fill in the gaps with borrows from Ocaml.
D supports un-managed operation and the problem was that they offered an optional garbage collector which too much of the ecosystem lazy’d into, making it a de facto Java/C# competitor since nobody likes to reinvent the world.
It’s one of the things that I’ve always brought up over the last decade whenever people tried to argue that “Rust is a great language, but please give it an optional GCed and/or un-borrow-checked mode”.
I’ll repeat my question to CapEnt: Examples?
Rust was designed by Programming Language Theorists with a lot of consideration and, if I were a betting man, I’d be willing to bet money that I can point out solid reasons for the syntax you point to being the least worst option, given the needs they were aiming to solve for.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
The bottom line is syntax is subjective. Since so many mainstream languages are derivative of C, that does give C derivatives the edge when it comes to familiarity. Younger future generations could end up bucking deep rooted preferences for C if coding is still done by humans in the future :-/
Variable assignments, function parameter prototypes and return values, classes. Nothing is familiar and the syntax for everything needs to be relearned. I’m not saying rust syntax is worse, only subjective. But I find a lot of system programmers in industry are squeamish about rust’s syntax. I understand if you don’t want to concede it. but respectfully the opinions of traditional C/C++ devs is really quite important given their dominance in the software industry. I know that you and I agree that safe languages are of utmost importance for the software industry to evolve past the vulnerabilities and faults we are notoriously associated with. Clearly rust has made huge strides on this front. But for better or worse, the choice not to go with the popular C syntax has popularity consequences, which somehow have to be overcome.
I want you to appreciate how much respect I have for you. You are probably the foremost expert on rust here. But I feel you may be missing the point. It’s like a French national arguing why French is a better language than English. Even if several reasons could be articulated, it doesn’t necessarily equate to winning anyone over. Rust is not going to win over many C/C++ developers over syntax. I’d warn you this debate is more of a detractor that riles up C/C++ developers and gets them to dig their heels over preferences. Their preferences have just as much merit to them as your preferences have to you, which isn’t a battle you can win. We need to focus on what makes rust special. IMHO this is not the syntax, but the safe by default philosophy.
By variable assignments and function parameter prototypes, I assume you mean the Pascal-style postfix type declarations.
There are two reasons I’m aware of that they felt it was worthwhile to break from C++:
1. To avoid needing the lexer hack. (Managing parsing complexity is something that they make an explicit focus.)
2. Because type inference is meant to be default and it would have made for a language that was either much uglier or much more syntactically inconsistent if they required “auto” to be stuffed a million different places. (Basically the same rationale as making “const” the default and “mut” the modifier… and I suspect you underestimate how many places that optional “: type” annotation is allowed without requiring a separate syntax.)
I’m just going to have to disagree with you there.
To me, Rust’s traits, based on Haskell’s Typeclasses, are the “Subversion tried to be CVS done right. Git and Mercurial went back to reconsider the very concept of CVS, using wisdom since gained” of interface constructs.
Among other things, the “polymorphic dispatch is a property of the pointer, not the object” design element is in line with modern best practices for C++ laid out in talks like code::dive conference 2014 – Scott Meyers: Cpu Caches and Why You Care.
In C++, you always have to watch out for making your structs or classes no longer POD, and each data type unilaterally and universally decides whether its consumers pay the cost of dynamic dispatch.
In Rust, padding aside and automatic struct packing in the default ABI aside, your struct’s in-memory representation is exactly what you specify and nothing more.
(“Make costs explicit” is another part of the Rust philosophy. Hence the part about no code beyond a memcpy() being run automatically when you perform an assignment.)
Likewise, unless you use a dyn pointer (which is a (pointer to struct instance, pointer to trait vtable) fat pointer), methods are just syntactic sugar for free functions which take the object as the first argument and can be called as such… and they compile down the same as a free function in C or C++ would.
A helluva lot is familiar. Rust’s creators are people who came from academic and functional languages. Look at some samples of Ocaml… the language Rust was originally written in, which it borrowed all that syntax from.
I suspect you’re looking at it backwards. Rust isn’t a C-lineage language that pulled a bunch of ideas from from academic languages. It’s an ML-lineage language that garbed itself in as much C++ as possible to pursue mainstream success.
Rust is surprisingly familiar for a language that’s so fundamentally different. (The ML lineage is independent of and parallel to the C lineages. ISWIM (1966) → ML (1973) → Caml (1985) → Ocaml (1996)→ Rust)
Hell, in the early days, it was a running joke that Rust was a ruse to trick C++ programmers into writing Haskell.
In fact, one of the greatest laments of Rust is the need for the ugly turbofish operator (::<>) to resolve a syntactic ambiguity introduced by using < and > for both generics and comparison operators and [ and ] for indexing like C++, rather than using [ and ] for generics and just making .get() behave like current Rust’s [] to keep that behaviour concise.
The problem is that Rust isn’t trying to be a C++ replacement. That way lies Subversion. It’s trying to serve the same needs as C++ from a new angle and, if it replaces C++ by doing so, so much the better.
The rationale that argues for Rust sacrificing even more of its design to be more C++-like is the rationale that also argues that Rust should have an “auto-Rc/Arc mode” or “unchecked mode” or something like that, despite D’s “optional” garbage collector being made de facto mandatory by ecosystem use and D failing as a C or C++ replacement because its ecosystem made it de facto a Java or C# competitor.
Rust isn’t the first safe-by-default language and other languages like D and Ada are adopting the borrow-checker concept. What got Rust over the hump was that it managed to pile enough good things into one language to achieve critical mass regardless, and that was a design goal.
Back when borrow checking was Rust’s only true innovation, one of the team members wrote that the point of Rust was to give proven but overlooked good ideas a second chance.
In fact, borrow checking wasn’t an ex nihilo innovation. Rust took inspiration from a “safer C” language named Cyclone that never achieved critical mass.
Beyond that, I’ve seen various attempts to make a “safer C” or “safer C++” and the people trying to bring them to fruition inevitably give up because there’s a strong current in the C and C++ communities that pushes back against any effort to make “C or C++, but safer”… including in the C++ steering committee. (Example)
Rust’s success is more like that of systemd or Flatpak… “adapt or become irrelevant. Your employers/customers are tired of letting you stonewall now that there’s an alternative available.”
Hell, most of the people I see coming to Rust aren’t coming for the safety, but for how pleasant Cargo is as a build and dependency tool and how pleasant Crates.io is as an ecosystem, with things like Clap, Serde, Rayon, etc. (Early on, the Rust devs were surprised how much interest there was from people who already knew scripting languages like Python, Ruby, JavaScript, etc.)
…and I see a lot of programmers faulting Rust for that because they’re of the opinion that dependencies are supposed to be painful because that’s how you beat back NPM’s ills.
See the “Gotta Go Deeper” section of https://wiki.alopex.li/LetsBeRealAboutDependencies for more on how that works out. (TL;DR: A lot of bespoke implementations and vendored libraries, each slacking off on static analysis and fuzzing in its own way.)
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
You are responding as though you need to defend your preference for rust syntax, but you really don’t. It’s not my intention to be critical of rust syntax or argue for C syntax being better. However I still don’t feel you are giving enough consideration to why none of these academic arguments win over C/C++ developers. Rust is not the first academic language to bring new ostensibly better syntax, challengers from academia have come and gone over several decades, yet what system programming language consistently remains dominant? I’m not saying your arguments are wrong, but you’ve got to read the room to make sure they’re going to be effective! Don’t put so much importance on subjective benefits that loose the interest of mainstream devs who genuinely don’t have a problem with writing or reading C code, myself included. While I don’t doubt the importance of rust’s syntax to you, I’d still encourage you to come up with selling points that work for C/C++ developers instead.
Of course it’s a replacement. There’s not enough room for rust to grow in the market without displacing C/C++. IMHO rust’s core advantage is it’s safe by default design. This is a huge improvement over C/C++, which were plagued by memory issues since the very beginning. If Rust had introduced memory safety with a more familiar C syntax, it would likely be more popular today, but they made their choice and here we are. I wasn’t here to question their choices, but I don’t think we can deny that rust not using the world’s most popular syntax creates additional resistance to adoption.
A safe variation of C++ might yet win in the end, but this is a very different topic.
Systemd had powerful incumbents promoting it. I could be wrong, but it doesn’t seem like rust has similar incumbent advantages. I’m sure your aware of the drama already, but if anything incumbents like linux kernel devs may actually be more interested in keeping rust away. It boils down to a lot of politics and speculation so we don’t really know what will happen. My own prediction has been that rust will gain popularity among new generations of programmers who value robustness and memory safety more than the older generations of programmers retiring.
@Alfman
> A safe variation of C++ might yet win in the end, but this is a very different topic.
I am curious what safe variations of C++ you may be betting on. Is Carbon too foreign for you?
Carbon is certainly less alien that Rust but it is a lot more “modern” than C++ in terms of syntax. It looks a lot more like Javascript or Kotlin than C++ to me. And it pulls trends from the ML languages like declaring types to the right of the identifier instead of the left. Certainly Carbon comes much more directly “from the C++ community though”.
Or are you thinking of something more like MISRA?
I think we’re talking past each other… as will become more apparent in the responses which follow:
I’m not defending my preferences. I’m giving context for how the Rust team knew all these arguments and chose to do things differently anyway.
Python was my go-to language for nearly 15 years before Rust came along and provided a way to be “Go without the boilerplate”, “Cython but better”, and a bunch of other things, I still write a lot of Python, and I have no personal attachment to the syntax.
(I write at least half a dozen languages at least casually and what draws me to Rust isn’t the syntax… though I would be disappointed if I had to use the same Rust constructs with the more awkward retrofitted syntax from Sean Baxter’s Safe C++ draft.)
Because Rust explicitly drew a line in the sand and said “This is as far as we’re willing to compromise. We’re not sacrificing any more of our goals to satisfy C and C++ developers.
…a non-trivial number of whom are arguing in bad faith anyway with arguments like ‘I don’t care that Rust is already more tightly specified than C or C++ and with regression tests in a CI system and the Crater bot, or that every C project of any significant size is written in Microsoft C or GNU C or Borland C or whatever, not ANSI C. You don’t have a standard and a committee to ‘stabilize’ the language, so you’re not ready for consideration”. (When Ferrocene came along, and the Rust people started on a standard beyond that, the goalposts got moved to “but that’s not by an international standards body so it’s not good enough”.)
I am reading the room. I’m making these arguments because I’m talking to you, not someone else.
There is no “C/C++ developers” one can make a single set of points to, because they range from “My sense of worth is tied up in my ability to survive a masochistic language” to “I like Cargo so much that I’ll switch to Rust on that alone”. (And many of the more obstinate ones will use that “C/C++” phrasing as an excuse to dismiss you as not worth listening to because they’re looking for any excuse to interpret that as you calling C and C++ the same thing.)
Rust is a C++ replacement in the same way that Go is a C++ replacement… it’s aiming to replace C++ for a certain set of users and not blindly trying to please everyone.
(Go is a replacement for how Google uses C++ to write web services when Python or Ruby can’t scale. Rust was originally focused around being a replacement for how Mozilla uses C++ and it stayed that way beyond the v1.0 syntax freeze. That’s why the generally minimal standard library contains vestigial Servo asks like a multi-producer, single-consumer queue that most people ignore in favour of pulling in a multi-producer, multi-consumer queue like crossbeam-channel or Flume off Crates.io.)
Efforts have been made. I’m having trouble remembering what it was called, but I remember seeing a proposal akin to the Safe C++ proposal on LWN.net years ago. (I vaguely remember it being a demoralized concession that the C programming world was not interested and would push back if pushed.)
See also CCured and SafeC.
I get a strong impression the calls for that sort of thing translate to “Make something I can ignore” or “How long do I have to humor you before you give up and go away?”
Look at how little excitement there has been around Carbon, the Circle C++ compiler, and the Safe C++ and Std2 proposals.
Those are literally “better C++” efforts, right down to taking various approaches to being intercompatible with existing C++ code in the same way TypeScript is with JavaScript and the lion’s share of C++ developers who were faulting Rust for anything but needing more work on C++ interop are dismissing them for being unnecessary and a waste of time.
I think i remember reading that Sean Baxter was getting demoralized by the reactions he was getting to Safe C++ and Circle C++. (Not to mention, as mentioned in that “Example” link from earlier, people like Stroustrup seem to be pushing strongly in the direction of treating Safer C++ efforts as “I don’t WANT systemd, so I’ll make noises about things like OpenRC until you give up and go away so I can keep using my sysvinit”.
Meanwhile the people who were talking in good faith about C++ interop being a weak point of Rust are working on various approaches to improve Rust, be it crates like autocxx or getting entries like Evaluate approaches for seamless interop between C++ and Rust on the Project Goals agenda for 2025H1.
Define “promoting”. Aside from names on the membership list for the Rust Foundation, here are some examples:
Google is rewriting parts of Android that can’t live inside the Android Runtime environment in Rust:
The Chrome team have been active participants in the efforts to improve Rust-C++ interop and, as of 2023, Chromium project policy allows the use of Rust libraries in Chromium’s codebase as a valid solution for outside-sandbox processes for their Rule of Two security strategy.
Microsoft is rewriting parts of Windows in Rust where they’re particularly risky from a security standpoint, including in the kernel (eg. GDI, DWriteCore) and also writing new stuff in Rust, like their Windows 11 replacement for the real-mode MS-DOS Edit.com that 32-bit Windows was still shipping.
They also have have an official… projection, I think they call them? …in Rust of the WinAPI IDL they cooked up for generating bindings for things like C#, documentation for Rust on MSDN, they’ve put work into improving the experience for writing Rust using Visual Studio Code, and released a beta Azure SDK for Rust.
Amazon AWS uses Rust (2) for things like the Firecracker Virtual Machine Manager that underpins AWS Lambda and AWS Fargate, as well as considering it “the language of choice” for new components for EC2, CloudFront, Route 53, “and more”.
They have also released official SDKs like the Rust Lambda Runtime.
IBM has released Open SDK for Rust on AIX.
As for Meta/Facebook, here’s a post on their engineering blog from 2022:
I don’t know much about what Huawei has deployed Rust in, given their stuff isn’t big in North America, but they’re apparently also big enough into Rust that they are a founding Platinum member of the Rust Foundation.
The main notable exception is Apple, and that’s probably because they’d prefer to just adapt Objective-C and Swift to meet whatever needs they see instead.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
I’m afraid I’m not familiar. It looks inspired by both C++ and rust. The “bi-directional interoperability” sounds promising. I’d really need to study it more.
https://en.wikipedia.org/wiki/Carbon_(programming_language)
At the risk of sounding a bit contradictory, I’d like to clarify my own position: I am not married to C/C++. Like most C++ devs I am comfortable with the syntax, but perhaps unlike most of them I have a lot of resentment towards C/C++ over annoying legacy baggage, questionable language design choices, and issues with software robustness. Over the years I’ve become more amenable to ditching it for something newer and cleaner. As a C++ dev rust would not have been my first choice because of the syntax, however I personally think rust’s safety benefits over C++ are worth it. For the broader community though rust are asking developers to swallow two pills: one for the new requirements of static code verification features, and another for the work needed to rewrite code using a new syntax, the merits of which is subjective. If a new language were to bring compile time safety on top of existing C++ class and function syntax, this might eliminate the need to rewrite so much code, which a major consideration for existing code bases. “Safe C++” could be quite persuasive with developers who are otherwise reluctant to port their work to rust.
That sounds like Sean Baxter’s Safe C++ proposal. It’s literally a plan for how Rust’s features could be added as opt-in functionality within existing C++.
(Since & already has a meaning in C++, it proposes that borrow-checked references would be “T^” for Rust’s “&mut T” and “const T^” for Rust’s “&T”.)
@Alfman
We agree on D.
> create a safe language that genuinely feels like a C++ successor in a way that rust just does not
Rust was created to fill the same niches that C++ filled. It was designed to be a replacement for C++. But it does not seem to have been designed to be a language that C++ programmers would choose. It was designed from the beginning from the perspective of the academic language community rather than the programmer community.
I am not sure yet if creating a C++ competitor that is unattractive to C++ programmers is a good or a bad thing. It is a good way to avoid perpetuating mistakes of the past. And the people that do like Rust seem to love it, winning the “most loved language” in the Stack Overflow survey year after year. But the Rust syntax has certainly been an obstacle to adoption by C and C++ devs.
The founder of C++ once proclaimed “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”. Certainly lots of people complain about C++ and so I think he was bragging about the popularity of C++. Well, lots of people complain about Rust too–certainly many C++ devs. Does that mean Rust will be popular? I mean, it already is.
A language that was meant to appeal to C++ programmers is C#. It was meant to woo Windows desktop devs away from C++ and it largely succeeded in that mission. Even a substantial fraction of Windows game dev is C# these days. It succeeded in bringing over the Visual Basic camp as well. Neat trick marrying those worlds. But C# cannot target every C++ use case (not even with AOT).
LeFantome,
I feel the same way.
Agreed.
I love C# as a language, it just hits the right notes for me, succeeds at fixing most C++ problems while introducing new features as well. As a managed language it doesn’t quite cover the same domain as C++ (or rust) does for system programming. Also I find C#’s lack of independence from MS is a con.
On windows microsoft intentionally breaks .net backwards compatibility for older versions of windows to achieve planned obsolescence with other people’s software, which negatively impacts users. This has made it painful for me to use windows 7, my last favorite version of windows, in a VM. Contrast this to software built with mingw or another non-MS compiler that doesn’t have this problem since they’re not slaves to microsoft’s planned obsolescence agenda.
I think this just made it click why we’re talking past each other. It’s because I’m not particularly wedded to any specific syntax.
For me, not being able to see any better way the Rust devs could have achieved the goals I agree with is enough to excuse any personal taste issues I might have with the syntax.
(eg. How else would you have used the same type ascription syntax consistently throughout the language, and allowed types to be inferred rather than explicit in most of them, and also avoided the need for the lexer hack without going even more alien than the Pascal/TypeScript/Python-style type ascriptions they chose? Regardless of my taste in syntax, I can’t see a better way, and I agree with placing value on those things, so I sit down and get used to it.)
I thought my arguments were compelling because, to me, syntax is the last thing you decide on after pinning down the practical concerns that it needs to be chosen within, and Rust’s syntax generally even manages to satisfy their “If a C++ construct is unavailable or doesn’t meet requirements, who else can we be familiar to?”
(eg. Those Pascal-style optional types are also in use in Python and TypeScript and probably other languages too.)
Hell, it was a big, controversial deal when, instead of cribbing off some other language (even if it was stuff like using Ocaml’s
'agenerics syntax for lifetimes because <T> was already used for regular generics and lifetimes are a special class of generic type parameter), they invented method-like-but-not-a-method.awaitsyntax… a decision that people agree in hindsight to have been the right move.I find Rust syntax is atrocious. It kinda has the same vibe as Perl, is trying to embrace way too much stuff, and like the Perl community, their community are increasingly convincing themselves this is a feature.
In a decade from now, people will be gorging their eyes out trying to maintain these write-only pieces of code done in Rust everywhere and cursing seven generations of people who wrote it.
Examples?
Given my experience with both Perl and Rust, and with hanging out in and participating in the Rust RFC discussions over the years, I’d say they’re polar opposites.
Rust bends over backwards to NOT add new syntax, starting with migrating a bunch of sigils into standard library types within the last couple of years before locking down the syntax at v1.0.
(Now, if you’d said Perl and C# have the same vibe…)
CapEnt,
I think “write only” was a joke about perl that stuck, but I don’t see a reason perl is any worse than it’s brethren in terms of readability. I’ve seen code that’s horrible to read in C++ (especially with templates), PHP, bash, VB, ASP, etc.
What bothers me is the lack of a consistent framework. Want an asynchronous socket IO library/HTTP library/timer library/etc? Perl has dozens of them, have fun choosing but don’t get too used to it because some day you may have to merge code that uses different libraries. This is what happens with languages that came into widespread usage before standard frameworks were prevalent. Consider the countless string and type libraries that are written for C++. At least C++ has an official STL, but it’s not even the most popular or elegant implementation. For example at school they tried to standardize on Roque Wave’s implementation.
https://en.wikipedia.org/wiki/Rogue_Wave_Software
Others places would use QT classes, etc.
Languages that had robust class frameworks from the beginning can benefit hugely from standardization.