1. 39
  1.  

  2. 24

    How this looks like to me.

    • C++: Yes! Welcome everywhere. It’s matured and proven!
    • Dart: Yes. Because “people” are using it. But in my OS code? Not a chance. Not in my workplace.
    • Rust: No. Because “people” don’t use it. Oh except in the my OS code. But you? Not a chance.

    Just my humble opinion :P

    I think they gonna provide more support if other languages gets more popular. But at this point, it seems they want to “encourage” people to use Dart but not Rust or Go.

    1. 3

      I had read quite some time ago that the plan was to make Go the “systems” language for Fuchsia and Dart the “application” language. Dart makes a lot of sense since, as a result of Flutter, they’re actually making language decisions with an eye toward programming user interfaces and it is intentionally “Java-esque” to make it easy to learn. C++ I find somewhat surprising, I wonder what happened to Go for low-level code.

      1. [Comment removed by author]

        1. 1

          I do know two. I know you mostly know geeks too, but I do know two such geeks.

      2. 59

        This is a great example of how programmers dress up arbitrary opinions to make them look like they were rationally derived. The cognitive dissonance that led to writing that C is not supported, but the near-complete superset C++ is supported, or that rust should not be supported because end developers do not use rust must have been nearly overwhelming.

        1. 18

          The cognitive dissonance that led to writing that C is not supported

          Huh? The doc clearly says that C is approved both for end development and for use in the source tree. It’s not “recommended”, because apparently they’d rather use C++, but that’s not the same as not supporting it.

          1. 10

            None of our current end-developers use Rust.

            … says more about Google than anything else.

            1. 21

              I read it as, “the biggest problem with Rust is that we didn’t make it, so how good could it possibly be?”

              1. 3

                We interviewed a guy the other day who told me that he knows “insider sources” in Google and that they are abandoning Go for all new project starts and moving entirely to Rust.

                EDIT: to be clear, I didn’t believe this guy. I was relating the story because it would be funny that they don’t support Rust for Fuchsia but supposedly are abandoning Go in favor of it…

                1. 8

                  This is not true.

                  1. 3

                    I know. We didn’t hire the guy either.

                    1. 1

                      o, sorry :(

                      1. 1

                        What do you hypothesize his motivation was for such a weird fabrication? Was he proseletizing rust in an interview? Were you hiring for rust devs and this just.. came out in the interview as a point of conversational commentary?

                        Just curious. Seems a weird thing for a candidate to raise during an interview!

                        1. 3

                          I think he was trying to sound smart and “in the know.” He brought it up when we mentioned that some of our code is in Go, and mentioned that some of his personal projects were in Rust.

                          Like I said above, we ended up not extending him an offer, for a lot of reasons.

                          1. 1

                            Also very easy to check?

                      2. 0

                        Hopefully not. I don’t want to deal with the influx of twenty-somethings fresh from university who believe starting at Google instantly added 20 points to their (already enlarged) IQ.

                    2. 5

                      It makes sense to support C++ and not C. C++ makes it easier to write safer code (RAII) and provides a higher abstraction level (templates).

                      1. 4

                        Those are useful features, but that’s the subset of C++ that isn’t “C functions, compiled with the C++ compiler, and avoiding undecorated casts”. If I’m allowed to use C++ then I’m allowed to use C.

                        My original point remains: “it makes sense” is not “here are our axioms, and here are the conclusions derived from those axioms”. Programming language choice is usually - and rightly - a popularity contest based on what the team finds interesting, and I see no difference here when I look beyond the dressing.

                        I compare this to an experience I had at FB, where the systems developers chose to question their language choice (mostly C++, some Java). Arguments were put forward in favour of and against Rust, D, Go, and maybe some other things that I’ve forgotten. Then the popularity contest was run in the form of a vote, and C++ won, so they decided to double down on C++. Not because [list of bullet points], but because it won the popular vote.

                        1. 5

                          Idiomatic C++ is qualitatively different from C, though the language is technically a superset. That in itself is enough to have a group disallow C but allow C++.

                          You are right that it’s an imprecise process. But, popularity is a feature in itself. A popular language has more developers, more help information online, and more libraries. Why wouldn’t popularity be an important feature?

                    3. 13

                      So I would be an “end-developer” in this story? (Well, if I were writing software for Fuchsia.) So I’m down to Dart, C or C++?

                      I’m not in these waters, but this could going to slow down adoption by a lot, right? I don’t see many people embracing Dart, and C/C++ has it’s well-known pain points that most people currently developing third-party software don’t have to deal with on their current platforms. I mean, if I were writing a Windows, Android or an iOS app, I would likely not be dealing with memory. And I somehow don’t see a lot of people developing Linux apps jumping to Fuchsia.

                      Google is weird.

                      1. 23

                        These days my reaction to seeing new stuff being developed in unsafe languages (like C/C++) is to shake my head and close the page again.

                        • Should we rewrite e. g. Linux in Rust? Maybe, maybe not.

                        • Should we start writing new software in C/C++? Absolutely not! (Some exceptions may apply.)

                        People who say “you can write safe code in C/C++ if you are careful bla bla bla” are exactly the kind of people whose software I try to actively avoid.

                        1. 9

                          Should we start writing new software in Rust? Probably not. Very immature ecosystem, a lot of language churn, no established GUI frameworks.

                          What other languages are you going to use? I refuse to touch JVM/.NET with a ten foot barge pole, I’m certainly not going to write a desktop application in Go, or a scripting language, or a functional language like Haskell. What’s left other than C?

                          1. 17

                            C would be my last choice to develop a desktop application among the languages you mentioned. Memory safety is more important than memory usage and performances in my humble opinion.

                            1. 3

                              I don’t think that memory usage and performance are the big wins for C. I think stability is. C has a stable ABI and is the natural language for interacting with the rest of the Unix platform. There’s no impedance mismatch between C and your operating system like I feel with every other language.

                              Plus it’s fun to write.

                              1. 3

                                C has a stable ABI and is the natural language for interacting with the rest of the Unix platform. There’s no impedance mismatch between C and your operating system like I feel with every other language.

                                Rust has first class support for making calls into libraries that conform to those ABIs, and for producing libraries that conform to those ABIs. It also, like C, doesn’t mandate a particular threading model or garbage collection scheme. It’s the first language I’ve seen in a long time that has successfully convinced me that I can have a bunch of extra safety without giving up first class access to even more advanced OS facilities. It also seems to enable an incremental approach to subsystem replacement, being even useful for kernel module development with no_std. It’s not a panacea, but it’s absolutely worth investigating, even if you get started with a thin FFI wrapper around an existing C library.

                                1. 6

                                  I’m not quite sure I’d call Rust’s support here “first class.” If it were first class, then I personally think I’d be able to do things like, “include this C header file and have the obvious things available to me.” Without that, you wind up needing to re-create a lot of the conditional compilation used in C headers for specific platform support. It’s not insurmountable, but there’s a lot of friction there.

                                  1. 1

                                    It feels first class compared to Go, but second class compared to C++.

                            2. 6

                              I think D is pretty good. It has optional GC, and you can write code which looks a lot like C. In addition, it has some nice sugar like foreach and ranges which make writing common C stuff easier.

                              1. 3

                                I struggle to see how D really differentiates itself from C++ tbh

                                1. 5

                                  Generics are done differently (no templates) which yields better compile times. It’s less of a kitchen sink language, since it was developed with 15 years of C++ hindsight. There is GC for when you want it.

                                  1. 2

                                    The bad compile times for C++ templates are due to monomorphisation and then optimisations being run for every single template instance basically independently. How does D improve on that? Does it optimise before instantiation?

                              2. 14

                                Very immature ecosystem, a lot of language churn, no established GUI frameworks.

                                Well, I guess that eliminates C then?

                                Should we start writing new software in Rust?

                                If I have to choose between

                                • some old C “experts” being forced to learn something new, and
                                • inflicting another 2 decades of broken, unsafe, poor quality software upon innocent users

                                I’ll pick the former immediately.

                                C developers had almost 50 years to demonstrate that they are able to write acceptable code. They couldn’t.

                                Let’s abandon this failed experiment and retrain them in a way that reduces the harm to the outside world, just like we did with the coal miners a few decades ago.

                                1. 0

                                  Well, I guess that eliminates C then?

                                  I don’t think C has had language churn ever, its ecosystem is very mature, and there are heaps of established stable GUI frameworks.

                                  I don’t really understand what you’re getting at here.

                                  inflicting another 2 decades of broken, unsafe, poor quality software upon innocent users

                                  No language can or will stop people from writing broken, unsafe, poor quality software.

                                  1. 10

                                    No language can or will stop people from writing broken, unsafe, poor quality software.

                                    Rust has a good record for stopping some really bad classes of breakage though, which is tremendously valuable. Sure you can still implement something with crypto weaknesses or arithmetic errors, but you’re probably not going to set the program counter to a user-provided buffer unless you really work for it.

                                    1. 2

                                      It has a good record at preventing some very narrow, specific classes of breakage. It achieves this with some large costs. I don’t like that people talk up the positives of Rust but never seem to remember to mention the downsides, and if anyone does mention those downsides they get downvoted into being hidden by the Rust Evangelism Strike Force.

                                      What I said was: “No language can or will stop people from writing broken, unsafe, poor quality software.” I said that in response to “inflicting another 2 decades of broken, unsafe, poor quality software upon innocent users”. I disagree with that because C does not cause software to be broken, unsafe or poor quality. In fact, most of the frustratingly poor quality programmes I’m forced to use are those written in languages other than C. Broken, poor quality software in my experience is mostly big bloated overly complicated programmes that try to do too much. What language they’re written in doesn’t seem to have much impact, with one big exception: C.

                                      C is not really designed for writing big programmes, and as a result, people that write C keep their programmes small. As a result, they tend to be of very high quality. This is just my experience, but it’s a very consistent experience. C programmers tend to care about producing good quality code.

                                      1. 3

                                        I’m not sure I understand the small programme claim: is the Linux kernel a small programme? is the Windows kernel a small programme? is GIMP a small programme? also, about quality, I think it’s hard to discuss, in essence boiling down to a “he said she said” & very subjective argument.

                                        As to Rust downsides, I totally agree it has those, but note that C advocates totally don’t mention C downsides in those discussions either :) also, all languages have some downsides, so every choice here is a compromise, question is, what weights one attaches to which pros & cons.

                                        1. 1

                                          Programming language discussions are always very subjective.

                                          1. 6

                                            Vulnerabilities (i.e., that get reported, get CVEs) are very much not subjective… and there are still vast numbers that are memory unsafety errors (seems like >50% in most studies I’ve seen), and they are going up. So being blasé that “C is fun to write” seems wildly irresponsible. Humans have empirically been shown to be incapable of writing memory safe code. Starting new projects in memory unsafe languages because of vague ideas about software ecosystem is just plain irresponsible (if you are writing code for a hardware platform where there is literally no other option, that’s a different story…)

                                          2. 1

                                            Where could one read about Rust downsides? Something relatively objective? Maybe the biggest 3 points fit in a comment here?

                                            1. 1

                                              Not a Rust user, just interested in the discussion.

                                              I’d say they are

                                              • difficult concepts to grasp when coming from other languages
                                              • lack of broad platform support
                                              • slow compile times

                                              I’d be happy to be corrected.

                                  2. 2

                                    scripting

                                    That vague adjective sure is doing a lot of heavy lifting in this sentence.

                                2. 4

                                  In this situation, I’m kinda thinking Nim could be an interesting option for the “end-developers”, given that it compiles to C. Though I also think some people from the Rust community may try to provide non-Google-backed support for Fuchsia too.

                                  1. 2

                                    “Dart is an object-oriented, class-based, garbage-collected language with C-style syntax.” In other words, if you know Java, you can probably pick it up pretty quickly.

                                    The same cannot be said for Rust.

                                  2. 7

                                    Interesting but incomplete, because while it talks about the scope of software it’s talking about, “production software on the target device”, it doesn’t distinguish between the type of software. Writing a device driver and writing man are quite different programs with different constraints, and you don’t necessarily want the same tool for both of them.

                                    1. 9

                                      This is just strange. Why do they fail to mention the most damning flaw of C++: unbridled, unmanageable complexity? Why don’t they mention the churn the languages is undergoing now with major new language features in every new language standard that drastically change how idiomatic c++ is written?

                                      Why is it claimed that you can write ‘straight line concurrent code’ in Rust but not C? You can write a fully functional fibre system for C that is essentially transparent for code using it (doesn’t need to know it is running in a fibre except that you can’t block) in less than a thousand lines of code. You don’t need async/await nonsense plastered over your code and to duplicate every bit of code into async and normal functions. That seems just as “straight line” than Rust to me.

                                      1. 9

                                        This is just strange. Why do they fail to mention the most damning flaw of C++: unbridled, unmanageable complexity? Why don’t they mention the churn the languages is undergoing now with major new language features in every new language standard that drastically change how idiomatic c++ is written?

                                        “C++ at Google” is generally considered different from “C++ in the wild”. They have a rather strict coding standard, with tooling to enforce it, plus a huge toolstack and practice built around it.

                                        You don’t need async/await nonsense plastered over your code and to duplicate every bit of code into async and normal functions. That seems just as “straight line” than Rust to me.

                                        You do know that fuchsia engineers were a huge driver behind the actual async/.await implementation? They have need for it.

                                        1. 1

                                          That’s something I didn’t consider actually. Google C++ is a pretty small subset of C++. That also explains why they ignored C++‘s co_await stuff but mentioned Rust’s: they don’t use new C++ features and they helped drive the implementation of Rust’s.

                                          1. 1
                                            1. 1

                                              C++: “Con: Support for asynchronous programming is weak.”

                                              Rust: “Pro: Asynchronous programs can be written using straight-line code.”

                                              Even though C++ obviously has much more mature support for a hugely wide variety of asynchronous programming models, as well as supporting co_await, while Rust only supports the equivalent of co_await (and not very well yet, as it was basically just introduced recently, though that should improve over time).

                                              That looks like ignoring it to me.

                                        2. 7

                                          This is just strange. Why do they fail to mention the most damning flaw of C++: unbridled, unmanageable complexity? Why don’t they mention the churn the languages is undergoing now with major new language features in every new language standard that drastically change how idiomatic c++ is written?

                                          Do they just understand and accept this complexity? Large C++ projects are not new to Google, just look at Chrome. From their perspective it’s more likely to be considered the norm and necessary complexity.

                                          It seems strange to outsiders, but culturally it is probably the most palatable option with known results. Choosing the known thing is probably much safer. I’m sure lots of the developers have probably had the same thoughts as you, but they feel that this approach has the impact they desire.

                                          1. 4

                                            You can write a fully functional fibre system for C that is essentially transparent for code using it (doesn’t need to know it is running in a fibre except that you can’t block) in less than a thousand lines of code.

                                            I’m curious what that would look like. Do you have any resources on hand?

                                          2. 5

                                            This con about go is also very interesting :

                                            The Fuchsia Platform Source Tree has had negative implementation experience using Go. The system components the Fuchsia project has built in Go have used more memory and kernel resources than their counterparts (or replacements) the Fuchsia project has built using C++ or Rust.

                                            1. 4

                                              Isn’t that the design of Go, though? I was under the impression that they optimised for latency at the expense of memory usage on purpose.

                                              1. 3

                                                That might be quite true, I don’t know about go’s goals.

                                                Note though, that they used go in the beginning and apparently hoped for something better. So it surprised them. And Go was designed at the same company.

                                                Maybe it was also a political decision to try to use go on the first place.

                                                1. 3

                                                  Maybe it was also a political decision to try to use go on the first place.

                                                  It is explained in the pro section for Go. They integrated gVisor’s Network Stack and that’s how it ended up there. It’s not a surprise that they’d then make some effort to try and use it elsewhere as an experiment. Unless the use of gVisor usage is political, it seems like a fairly innocuous and commonsense approach to evaluating Go usage for their needs.

                                                  1. 2

                                                    True. Maybe “political” was a bit strong.

                                                    I wanted to play devils advocate to my own argument that they at least believed in the beginning that go would be a good fit.

                                                  2. 1

                                                    It’s a big company and Go is pretty specialised as a language. It’s really for shifting bytes around network sockets and not much more. The only reason it exists is that Google does a metric shitton of shifting bytes around network sockets.

                                              2. 4

                                                Is it me or is Go an odd choice for mobile device development?

                                                1. 4

                                                  Go is similar to Java, which is used for mobile development. On the other hand, I think the document is indeed pointing out one relevant difference, that Go produces large binaries.

                                                2. 4

                                                  It would have been interesting to see Swift evaluated on this list. It’s used more and more for Apple’s OS frameworks, and I suspect it has decent interop with C++, since Apple has a lot of legacy code, and needs to consider that when choosing what to include in its replacement language.

                                                  As someone who likes Go a lot and uses it every day, I’m not at all surprised it’s not a good fit here. Especially if the core team is more familiar with C++/Rust etc. Still, I could see Go succeeding in many user space components. Components like the software update system could be handled well by Go’s features. It could also be a good language to write a init system.

                                                  1. 4

                                                    I suspect it has decent interop with C++

                                                    Everything I’ve read suggests it doesn’t really. Either you have to provide a C interface to your C++ code, or you need to wrap your C++ in Objective-C and use the Objective-C wrapper in Swift.

                                                    Having said that, I don’t use swift and much of what I found on the subject was several years old, so I’d be interested to hear from someone who knows what they’re talking about.

                                                    1. 2

                                                      Swift lacks concurrency support beyond Darwin.

                                                    2. 0

                                                      Suggest rust tag.

                                                      1. 2

                                                        Why? It talks about multiple languages.

                                                        1. 1

                                                          Only because it seems to be causing the most outrage.