If you’re trying to demonstrate something about Rust by pointing out that someone chose C over Perl, I have to wonder how much you know about the positive characteristics of C. Let alone Rust.
When it comes to nightly features use, it is good to note that a stable compiler, a nightly corresponding to the date beta for that stable was branched out and an arbitrary nightly are different. A branched-off nightly might have had beta back ports for fixing stable features that the nightly will not have, and a nightly feature that is subtly broken on stable but isn't used in std will not have received a backport. So using nightly feature on stable might mean every now and then skipping a stable version, and using a nightly compiler means having to do thorough testing after updating on arbitrary days. Any given nightly has high chances of being fine, but every update brings the possibility of bugs.
> Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.
Google is transitioning large parts of Android to Rust and there is now first-party code in Chromium and V8 in Rust. I’m sure they’ll continue to write new C++ code for a good while, but they’ve made substantial investments to enable using Rust in these projects going forward.
Also, if you’re imagining the board of a multi-trillion dollar market cap company is making direct decisions about what languages get used, you may want to check what else in this list you are imagining.
Unless rules have changed Rust is only allowed a minor role in Chrome.
> Based on our research, we landed on two outcomes for Chromium.
> We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++.
> We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation.
Also even though Rust would be a safer alternative to using C and C++ on the Android NDK, that isn't part of the roadmap, nor the Android team provides any support to those that go down that route. They only see Rust for Android internals, not app developers
If anything, they seem more likely to eventually support Kotlin Native for such cases than Rust.
The V8 developers seem more excited to use it going forward, and I’m interested to see how it turns out. A big open question about the Rust safety model for me is how useful it is for reducing the kind of bugs you see in a SOTA JIT runtime.
> They only see Rust for Android internals, not app developers
I’m sure, if only because ~nobody actually wants to write Android apps in Rust. Which I think is a rational choice for the vast majority of apps - Android NDK was already an ugly duckling, and a Rust version would be taken even less seriously by the platform.
That looks only to be the guidelines on how to integrate Rust projects, not that the policy has changed.
The NDK officially it isn't to write apps anyway, people try to do that due to some not wanting to touch Java or Kotlin, but that has never been the official point of view from Android team since it was introduced in version 2, rather:
> The Native Development Kit (NDK) is a set of tools that allows you to use C and C++ code with Android, and provides platform libraries you can use to manage native activities and access physical device components, such as sensors and touch input. The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:
> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.
> Reuse your own or other developers' C or C++ libraries.
So it would be expected that at least for the first scenario, Rust would be a welcomed addition, however as mentioned they seem to be more keen into supporting Kotlin Native for it.
You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented.
That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary architectures that nobody wants to have to actively maintain as part of the LLVM project. Right now, you usually need to use a fork of the whole LLVM project when using experimental backends.
> You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM.
This is exactly what I'm saying. Do you think HW drives SW or the other way around? When Rust is in the Linux kernel, my guess is it will be very hard to find new HW worth using, which doesn't have some Rust support.
In embedded, HW drives SW much more than the other way around. Most microcontrollers are not capable of running a Linux kernel as it is, even with NoMMU. The ones that are capable of this are overwhelmingly ARM or RISC-V these days. There’s not a long list of architectures supported by the modern Linux kernel but not LLVM/Rust.
Almost none of them, but that doesn’t make them “places no one uses”, considering everyone who can see these words is looking at a device with a bunch of C firmware running on microcontrollers all over the place.
You're putting words in my mouth there - that's not my point.
My point is that if they're not running linux, and the ones that are aren't running a modern kernel, then we shouldn't hold back development of modern platforms for ones that refuse to keep up.
Look at OpenAI - where there’s a will (and an army of lawyers), there’s a way. That said, I don’t think any of the big tech orgs would be interested in acquiring them. Google and Amazon even already have their own public CAs that are in the major trust stores.
I don’t know why the Snowden revelations would prompt a business necessity, at least not a rational one for most businesses. What would the NSA slurping up all your data do to your business, that was both bad enough and likely enough to plan for? What it would do to your country or you as an individual is separate from that.
1) A lot of these businesses have customers outside the U.S. Those customers, including some foreign governments, did not want their data to be snooped by the U.S. government. The business risk here is loss of customers.
2) There is no such thing as a private backdoor. If one entity (admittedly a very well resourced one) can snoop, so can others. The publicity also entices new players to enter the game. The business risk here is loss of reputation.
What does bothering to read some distributed systems literature have to do with demanding unnecessary perfection? Did NATS have in their docs that JetStream accepted split brain conditions as a reality, or that metadata corruption could silently delete a topic? You could maybe argue the fsync default was a tradeoff, though I think it’s a bad one (not the existence of the flag, just the default being “false”). The rest are not the kind of bugs you expect to see in a 5 year old persistence layer.
What fields? Cargo culting is annoying and definitely leads to suboptimal solutions and sometimes total misses, but I’ve rarely found that simply reading literature on a thorny topic prevents you from thinking outside the box. Most people I’ve seen work who were actually innovating (as in novel solutions and/or execution) understood the current SOTA of what they were working on inside and out.
I suspect they were more referring to curmudgeons not patching.
I was engaged after one of the worlds biggest data leaks. The Security org was hyper worried about the cloud environment, which was in its infancy, despite the fact their data leak was from on-prem mainframe style system and they hadn't really improved their posture in any significant way despite spending £40m.
As an aside, I use NATs for some workloads where I've obviously spent low effort validating whether it's a great idea, and I'm pretty horrified with the report. (=
Pulsar can do most of what NATS can, but at a much higher cost in both compute and operations (though I haven’t seen a head-to-head of each with durability turned on), along with some simply different characteristics (like NATS being suitable for sidecar deployment). NATS is fantastic for ephemeral messaging, but some of this report is really concerning when JetStream has been shipping for years.
reply