Hacker News Reader

Comment by aphextron | Hacker News Reader

Interesting that the only con listed for Rust is Not enough people are using it, compared to the serious criticisms of the others.

View on HN

The reasoning does sound serious: "The properties of the language are not yet well-understood, having selected an unusual language design point (e.g., borrow checker) and having existed only for a relatively short period of time". It isn't just "it isn't popular thus it is not good" but "it does something weird that no other language does and because few people use it, we haven't yet figured out what potential issues that weird part may have".

> does sound serious

Do you mean legitimate, instead of serious? The issue you point out sounds more like technical debt and verification/specification rather than something that can’t or won’t be overcome.

Yes i meant legitimate, though i'm not sure why you say that it sounds like technical debt. I'd say it is the opposite - trying to avoid technical debt that could happen by betting on something unknown and instead staying on the safe side.

I meant technical debt for the Rust project, not for fuchsia. I don’t disagree, Fuchsia would end up incurring this debt in the kernel too.

I would say, that as debt goes, this seems like something not egregious, but I can understand not wanting to take it on. But, with every passing year and no significant flaws having been discovered (I mean language destroying not some of the unsoundness bugs that exist), empirical evidence is getting stronger and stronger that Rust has an excellent model.

After having 2.2 million lines of code in rust in their project they should know a bit better imho; that's more than any other language they use; with go they knew quite quickly it's not good for them.

Usually language related issues are only understood when a project scales beyond a core team of experts.

Apparently most of those lines are vendored dependencies.

0.7 million of of them are their own.

As someone who’s project was vendored into Fuchsia, I will say that there were a number of contributions that were made directly to the project to support its use in Fuchsia.

This means that while the overall project is used outside of Fuchsia, google is contributing upstream patches, to many of those projects specifically to support Fuchsia. At that point it’s not a clean separation of what’s “in house” vs. not.

Yes, but if you think about it, it doesn't make the argument weaker but arguably stronger - not only they use all those lines of code but also it seems that you can do it, ie. use low level (I'm guessing) 3rd party libraries and it will work for you; and they must be having high bar for quality, they operate on low level etc.

A relevant factor could be in the other con

Con: None of our current end-developers use Rust.

I seriously doubt that whether any of their “end users” are allowed to use Rust.

End users here means user-space application developers

Reads to me like a slightly more general way of saying "this is not the time to specify an API in Rust that you intend to maintain in perfect backward compatibility forever". But if they said that directly they would be inviting a wave of counter-arguments that they most likely already went through themselves, repeatedly, considering how much love Rust is getting for in-tree use (where APIs can be refactored at will). I believe that their main issue is that they don't want to end up with the Rust equivalent of a Java API stuck with Vector and Enumeration.

That doesn't seem like a non-serious criticism to me. They're trying to build something huge that's of immense strategic importance looking forward potentially decades. It seems appropriate to adopt the utmost caution about incorporating a language that's promising but for which widespread traction might not materialize as expected. Though to be fair, the same (and more) might be said of Dart...

Yeah, but when something is built in-house like Dart is, I imagine there's some level of support the Fuchsia team will get.

The world of paid Rust language contributors is so small that Google could easily get all the advantages of "built in-house" for Rust if they spent a relatively tiny amount of money.

Being pretty conservative overall but betting the house on Dart for the UI seems like a strange combination of decisions to me.

Is there a conspiratorial side of Mozilla vs Google in this Rust vs Dart story?

The languages are as different as Python and C++, I honestly don't really see a Rust vs Dart story. Note that Rust is approved for use within much of the source tree, but outside it is only not supported. Johnny end-developer, whoever that is, could still use Rust if he insisted, coding against C bindings.

Just like it happens in Android.

If Johnny doesn't like JVM languages, or C++, all they get is a bare bones C API, which requires JNI even for opening files, asking for permissions and so forth.

I don't know what "conspiracy" you might be referring to. There's a natural tendency for organizations to gravitate toward tools, such as programming languages, that originated there. That's just human nature, though, not anything nefarious.

They don't seem to be betting on Dart by itself as much as they are betting on Flutter, which is already reasonably successful and relies on familiar reactive component concepts popular on the web and well tested in Google's own web frameworks (Polymer, Angular).

> They don't seem to be betting on Dart by itself as much as they are betting on Flutter

You don’t get Flutter without Dart. Anyone that’s ever looked at what is behind any Flutter component can see the Dart code building it.

You literally can not bet on Flutter and not Dart. Don’t confuse Flutter as some DeclarativeUI of its own.

EDIT: How we that’s not to say the cart can’t lead the horse (good analogy). Flutter requirements are definitely driving changes in Dart Lang.

I agree with you, the point I was trying to convey is that Google isn't betting on Dart as a pioneering, untested technology as Rust is.

Flutter demonstrates Dart is a good choice; it gives you a successful declarative UI framework that effectively builds on Dart as a fairly straightforward upgrade of the most tried and true UI scripting language ever made: Javascript.

To answer the GP comment, betting the house on Dart for the UI doesn't seem like a strange or risky decision in that light.

> To answer the GP comment, betting the house on Dart for the UI doesn't seem like a strange or risky decision in that light.

Yea. Before using Flutter, I probably wouldn’t have agreed. After using, I can’t disagree at all.

That you like Dart and that it's a good fit for UI development doesn't make it less risky.

It still seems incongruous that widespread usage is portrayed as an important criterion for Fuschia PLs, but they bet big on Flutter which forces them to adopt Dart, a language which has very little uptake outside Flutter.

I'm not sure how you got "I like Dart" from my two comments. I'm clearly saying that Dart & Flutter are based on very popular and well tested concepts/structures, therefore it is not very risky. Dart & Flutter by themselves may not be very widespread, but it's very familiar and easy to adopt to anyone who has done declarative UI web development in Javascript or Javascript-like language, which are widespread.

Rust, on the other hand, is treading new ground with the unusual core concept of a borrow checker.

The difference I think is that Dart is a dependency they have already accepted on the level of "we'll maintain it if necessary" (probably in the form of the intra-Google equivalent of an acqui-hire, I wouldn't even be surprise if Dart/Flutter were already reporting to Fuchsia, while publicly still appearing as equal peers), whereas Rust is a big scary NIH.

And still the decision on Rust reads very much like a "we'd love to extend the scope of the time is right" whereas the dismissal of Go is surprisingly brutal, almost reads as if there was a cold civil war going on between the two garbage collected Google languages and Fuchsia people feel need to to demonstrate loyalty to their Darters. Might even just mirror an equal dismissal regarding server side Dart.

> Might even just mirror an equal dismissal regarding server side Dart.

That'd be my guess. Given the nature of Flutter and its co-development with Dart it's not surprising that Fuchsia prioritizes it. After all, you need to implement the UI in something. Meanwhile I have literally never heard of a UI implemented in Go, and outside of the UI I can see why they don't want to use garbage collected languages in their OS.

There are a couple of them, including some books, but yeah there are better alternatives out there.

> I have literally never heard of a UI implemented in Go

I expect it has the same issue as UI in Rust: UI is one of the domain where OO inheritance is most convenient and most deeply embedded. So langages which don’t do inheritance are hard sells.

Newer “declarative” UI frameworks less so but they’re probably not mature enough conceptually that you’d want to bet your OS’s core UI system on them, right now they’d be used as an overlay on the core stateful UI system (see bodil’s vgtk for example).

Flutter is a declarative UI framework in Dart, and is the core system UI for Fuchsia. Shallow inheritance is used extensively there

> They're trying to build something huge that's of immense strategic importance looking forward potentially decades.

This seems like an exaggeration. Maybe Fuchsia will turn out to be important, maybe it won't. As of right now, it's another Google vanity project that makes them no money.

It could turn out to be enormously strategically important by allowing Google to drive a stake through the heart of Linux on consumer devices...or just as easily get killed tomorrow.

There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there. The actual software out there is the ultimate, unforgiving, unfraudable review of a language, not what people say.

Developers seem to like Rust (or at least pay lip service). It's understandable. We are all suckers for a golden hammer. Rust promises no data races, no dangling pointers, high performance, and best of all it can run on numerous targets, making it a contender for The Last Language you have to know.

But you don't judge a restaurant's performance by the holiness of the chef's choice of tools in the eyes of other chefs. What is the most profitable piece of Rust software or the piece of Rust software that the most people depend on? If it wants to be taken seriously at the systems programming table, then we should see the Unix coreutils written in Rust (with all the command line flags working exactly the same way). Come on, replace GNU. You say you can do it faster and safer than everyone else. Let's see it.

> There isn't a lot of good software written in Rust, open source or not. It's a lot of small and half-finished stuff here and there.

Perhaps you and I have very different definitions of "a lot" or of "good", because I don't agree with this at all. There are plenty of high profile Rust projects with excellent production track records. Linkerd, TiKV, and Firecracker (originally crosvm) come to mind immediately, and of course Servo. Facebook also selected it for Libra, Google for Fuchsia.

> half-finished

Literally all of the things you mentioned (except linkerd which is mostly Go) are half-finished incubator projects. Rust has been around for over 10 years. Come on.

There is literally no Rust in the main repo:

https://github.com/linkerd/linkerd2 https://github.com/linkerd/linkerd

It's confounding how a project that doesn't include Rust is included in Rust's "Greatest Hits."

Citing a cryptocurrency that...for all intents and purposes, doesn't really exist right now, is also a strange choice.

Linkerd consists of a "control plane" and a "data plane." You linked the the control plane, written in Go. You want the data plane, here: https://github.com/linkerd/linkerd2-proxy

Ah, interesting! Thanks for chiming in!

AWS blog on Firecracker, November 2018 (source: https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...)

> Today, Lambda processes trillions of executions for hundreds of thousands of active customers every month. Last year we extended the benefits of serverless to containers with the launch of AWS Fargate, which now runs tens of millions of containers for AWS customers every week.

> Battle-Tested – Firecracker has been battled-tested and is already powering multiple high-volume AWS services including AWS Lambda and AWS Fargate.

That doesn't sound like a half-finished incubator project.

Using language age as a definition of success isn't really being fair. Plenty of very successful languages took a long time to gain traction. For instance, Python was in a very similar position to Rust for almost 15 years before it finally started to shoot up into what it is today. In 2000 you were considered eccentric if you chose to use Python for anything but the most dirty scripts, but now it's being used for complex production systems.

I'm not blind. I can see that Rust has its major downsides, and the zealotry you see is on HN and elsewhere is downright annoying. But dismissing it based on age is being disingenuous. There was another list of projects elsewhere in this comment thread which listed a number of things being used in production that can't be considered half-finished by any measure.

> we should see the Unix coreutils written in Rust (with all the command line flags working exactly the same way)

While I'm not convinced that implementing an identical API to coreutils is necessary to be "taken seriously" as a systems programming language, there's a fairly far along implemention that already exists:

https://github.com/uutils/coreutils/blob/master/README.md

> What is the most profitable piece of Rust software or the piece of Rust software that the most people depend on?

You've got:

* Every page load of Firefox

* Every page served of Reddit

* Every byte stored in dropbox

* Every user of 1password's browser extension, and every user of their Windows client.

* Every HTTP/3 request served through Cloudflare (okay HTTP/3 is still a baby but, the future here)

* Every DNS request of every user of the 1.1.1.1 mobile app (hundreds of thousands of installs)

* Every invocation of AWS Lambda and Fargate

* 4% of Debian packages

* Every control-F in Visual Studio: Code

* Every time a user list changes in Discord, also other things.

... so, yeah. Take your pick.

Interesting. I thought that only find in project (ctrl shift f) was using ripgrep, but I kind of thought that find in current file (ctrl f) was done differently.

Find in project is really awesome in VSCode.

I thought they both did, but I'm also not an expert on Code's internals.

AIUI, VS Code uses Node's regex engine for searching in the current file. But I am also not knowledgeable about Code's internals. :-)

I'll pick using an example from Discord as being a rotten apple in the list. The less this malware is mentioned the better.

To be fair the cancerous part of it is the Electron JS frontend, which is not to my knowledge at all implemented in Rust.

I don't think Discord is malware, but we have straight-up 100% malware too! :p https://news.drweb.com/show/?i=10193&lng=en

Just my two cents: there are lots of Rust zealots in HN right now. Rust is at the top of its hype cycle rn, so it's a bit difficult to have balanced discussions even here. You're completely right with that Rust isn't one of the main language that drives the industry yet, but everyone will jump on you with tons of partial examples, and will claim it's already flying. Sigh.

It seems to me like the only point of difference between you and the zealots is the definition of success.

Rust sounded like it was close:

“ Rust is not supported for end-developers.

Rust is approved for use throughout the Fuchsia Platform Source Tree, with the following exceptions: kernel. The Zircon kernel is built using a restricted set of technologies that have established industry track records of being used in production operating systems.”

That’s better than Go, which is not supported.

That's probably in part demand driven? I.e., there's little need for rust to be supported officially for end users.

Moreover, C is supported for end users, and if C is supported then Rust is de facto supported though C bindings, which Rust understands natively.

Someone will have the fun of writing those wrappers, because Google won't do it.

Likewise a future Fuchsia Studio won't support templates, debugging, or OS libraries written in Rust.

And the Fuchsia team most likely won't prioritize toolchain bugs related to Rust.

This is the biggest difference between using an official SDK language and guest languages.

Rust doesn't have a stable ABI, so it's sensible to always go through C bindings anyway. The other things you mention are just a matter of what their future Fuchsia Studio chooses to support.

The majority of the code in the project is already written in Rust. If we're judging Rust based on its acceptance in Fuchsia for some weird reason, it's doing very well. Doing the best, in fact.

I'm sorry your comment is in the grey here. I think if you'd just stuck to: "If we're judging Rust based on its acceptance in Fuchsia for some weird reason, it's doing very well.", It'd have been better received.

Calling it the "majority" or "doing the best" is probably coming off as disingenuously impling "most significant". Sloc dosn't meet anyone's idea of that.

Pretty much every con in Rust is some variation of (we | others) don't use Rust enough. Interesting to see!

Would have assumed the Kernel would be where Rust truly shines, but that's where it's blocked, which is... interesting!

Good to know! I'll look for an OS written in Rust elsewhere then. Fuchsia is interesting, but could be much more so.

If you want to learn to write an OS in Rust, checkout this series: https://os.phil-opp.com/

For an os project fully in rust and targeting end users, check out: https://www.redox-os.org/

Given that they already have a microkernel written in C++ (zircon is derived from littlekernel), and they're trying to move as much as possible outside the kernel, it makes sense that (for the time being) adding a new kernel language isn't on the table.

I'm not very happy to see C++ infecting more and more system software when it STILL IN 2020 doesn't have a stable FFI/ABI.

This is going to bite us ALL in the future because it will saddle other languages with a useless set of constraints long after C++ gets removed from a project.

They don't want to add loadable kernel modules (but instead go pretty strict microkernel), so what would an unstable FFI/ABI really matter?

It's much easier to progressively migrate away from a language if you have a stable ABI.

The goal is to get it to the size where it can be replaced all at once. For instance sel4 is only 10kloc.

With the exception of the change to std::string in C++11, which was very, very carefully worked around so that C++11 code can handle C++03-ABI std::string, there have been no changes to the ABI implementation since the Itanium ABI was adopted by gcc almost two decades ago.

How is that not a stable ABI?

> How is that not a stable ABI?

Because it's an ABI with several severe constraints, especially around the more OO features and templates, plus the solutions introduce even more abstractions: https://community.kde.org/Policies/Binary_Compatibility_Issu...

All ABIs define similar set constraints, specially when the programming languages are a bit more expressive that pseudo-assembly.

> specially when the programming languages are a bit more expressive that pseudo-assembly.

Most higher level languages (java, c#, python) handle most of those much better, albeit with a different set of trade offs. Things like adding a private field to a class won't break binary compatibility in a c# apllication. C++ is fairly unique in that it tries to be high level and tries to be low level but the cost is it pushes the complexity of this split personality onto the developers.

That's not a C++-ABI but a C++-as-compiled-by-gcc-ABI. C++ itself does not define an ABI and different compilers (sometimes even from the same vendors) will use different incompatible ABIs.

It is the linux standard C++ ABI as the defined by the linux standard base. An ABI for low level language is necessarily (OS, architecture) specific, so you can hardly do better than that. There is no ABI that could be usefully defined at the standard level (and even if it somehow were, it would be mostly ignored[1] as compilers wouldn't break compatibility to implement it).

[1] I could see the committee standardizing some intermediate portable representation requiring installation time or even JITing in the future though.

It is not the linux standard C++ ABI, it's just the defacto standard ABI because of gcc's former dominance and clang intimidating the ABI. And I broke things in the past, where I had to recompile stuff, due to different compilers (clang, clang+libc++, gcc in different -std=c++ modes) producing not 100% compatible outputs.

You can say it's good enough (most of the time), but it isn't really a standard, unless I am mistaken.

https://uclibc.org/docs/psABI-x86_64.pdf page 106 cares to disagree with:

> 9.1 C++

> For the C++ ABI we will use the IA-64 C++ ABI and instantiate it appropriately.

The Itanium ABI is the official C++ ABI on Unix systems. (Note that this same document officially documents the C ABI).

although it might the facto be, at least for AMD64, I wouldn't say it is the official standard ABI of all unix systems. But it is the standard ABI of Linux based systems, at least those that claim to conform to the LSB.

The Itanium ABI it is not just whatever GCC does; while it is not an ISO standard, it is an intervendor ABI documented independently of any compiler implementation and changes are agreed among compiler teams. It is continually updated to track the C++ evolution.

The standard library ABI it is not covered the the Itanum ABI (outside of some basic functionality), but it is defined necessarily by the platform. For linux that would be libstdc++.

The LSB references the Itanium ABI and defines libstdc++ as the ABI for the C++ standard library on linux platforms; it is again not an ISO standard, but it is as close as you can get on Linux.

And of course the C++ ABI being a very complex and both the ABI document itself and compilers have bugs from time to time, especially if you live close to the bleeding edge.

There's more to a practical language ABI than stack and vtable layout. If you write idiomatic C++, this means passing objects from the standard library around. If different compilers use different implementations of the standard library that aren't layout-compatible, things break.

On linux, libstdc++ implementation details are part of the official ABI.

The Linux processor-specific ABIs explicitly call out that the Itanium ABI is the C++ ABI for x86 and x86-64; ARM has its own ABI that differs from the Itanium ABI only in the exception handling details.

FFI in C++ is never gonna happen with the preprocessor and templates being there. By design of the language it basically won't ever work. You would need to recompile the world unless you're artificially restricting yourself to the equivalent of extern "C". C++20 modules won't make it better either.

I don't think Rust, Dart, or Go are any better.

In practice it seems C++'s ABI is called "protocol buffers".

Basically correct, though in Fuchsia it's called FIDL. It's protocol buffers, but not the specific project that Google refers to as "protocol buffers".

https://fuchsia.googlesource.com/fuchsia/+/master/docs/devel...

Which is also used by Android.

It works perfectly fine with COM, specially after the COM 2.0 (aka UWP/WinRT) improvements.

C++ is moderately safe if one doesn't use it as a C compiler, even standard library does bounds checking across all major compilers, during debug builds and specific compilers switches.

There is a stable ABI inside some OSes, moreso than any wannabe C++ replacements.

Speaking of which, Rust is a very nice language, but still lacks many productive tooling that systems developers came to expect.

If anything this rationale is great input for the Rust community, how to improve the ecosystem.

Rust binary size can be pretty painful, depending on what you're doing. Also, it doesn't look like that document is receiving regular updates, so grain of salt and all.

> it doesn't look like that document is receiving regular updates

It was checked into git yesterday.

It's worth noting that Go and Dart were characterized as "highly productive" whilst Rust wasn't.

Absolutely, I don't think any sane Rust zealot would argue that Rust can compete with Go/Dart productivity. The argument can be made that Rust code has a lower maintenance cost over time, though, and that productivity may not drop as much as the system becomes more complex.

Even with this relative improvement, though, I question if it's enough to overcome the shorter compile and test loop the other languages have, or the mental overhead of managing lifetimes and ownership.

Notice that they omitted the "highly productive" claim thy applied to Dart and Go.

Sorry, but that was not the only con. The other were that the design was unusual and it is not yet understood.

And not enough people are using it is devastating critique of a language - every piece of code written will be read by someone eventually. And you want that pool to be as big as possible.

To me it seems Google are cautiously bullish on Rust.

I agree with your summary.

My worry comes from the fact that a computer system of the scale of Fuchsia comes up every couple decades. I'd like not waste another one on C++ shortcomings and Fuchsia going with Rust was a great chance for a better dominant language in 20ties.

The microkernel is a pretty small component. It's like if 80% of the Linux kernel was Rust and 20% was C++.

compared to the serious criticisms of the others

Adoption and community are one of our top factors. It's a pretty serious one, IMHO.

EDIT: our as in our company. Not in any way affiliated to Fuchsia.

Reply on news.ycombinator.com