25 ms·

Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming

523 points by adamnemecek 6y ago

VWWHFSfQ 6y ago
What role (if any) does GCC play in Rust? I understand that Rust relies on LLVM. If the industry continues to move more and more to Rust then will GCC begin to lose relevance? Or will the GCC developers add a Rust ~~backend~~ frontend? Has there been any movement toward that anyway? There are many gaps in my understanding of Rust with regard to LLVM and GCC.
- klysm 6y ago
  I’m not sure about GCC, but a significant amount of work has gone into a cranelift based backend for rust (https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift).
- steveklabnik 6y ago
  https://users.rust-lang.org/t/call-for-help-implementing-an-independent-rust-frontend-for-gcc/32163/ https://users.rust-lang.org/t/call-for-help-implementing-an-...
- konschubert 6y ago
  Wouldn’t you need to add a RUST frontend?
  - VWWHFSfQ 6y ago
    ah right
- redrobein 6y ago
  > There are many gaps in my understanding of Rust with regard to LLVM and GCC. The rust compiler generates some intermediate code (LLVM IR) that's fed into LLVM, which optimizes and turns it into machine code. You can check out what this looks like in the rust playground. Getting GCC to compile rust would be a matter of getting the rust compiler to generate GCC IR. Cranelift (built with rust) is an alternative to LLVM with it's own IR. The cranelift backend for rust should help future projects that want to do something similar, I guess.
- orangeshark 6y ago
  There was a rust frontend for GCC[0]. Will need a lot to work though. [0]: https://gcc.gnu.org/wiki/RustFrontEnd https://gcc.gnu.org/wiki/RustFrontEnd
- fsloth 6y ago
  "will GCC begin to lose relevance" Systems programming is not web where they change the framework and 'script flavour every six months. Systems programs live for decades - and hence their critical infrastructure like GCC will as well. C will be with us at least 3 decades more. Longer if Linux kernel will use it still.
- Jyaif 6y ago
  > then will GCC begin to lose relevance? That has already began. For example all the popular browsers (Chrome and all the derivatives, FF, Safari) moved away from GCC.
jph 6y ago
Rust is definitely great for systems programming, and the speed is fantastic too. Take a look at some of the system utility tools on crates.io, such as ripgrep (like grep), bat (like cat), fd-find (like find), lolcate-rs (like locate), procs (like ps).
- CameronNemo 6y ago
  All of those are MBs in size, compared to KBs for their C counterparts. Something needs to budge in Rust land for small utilities to be viable.
  - deleted 6y ago
    [deleted]
  - zozbot234 6y ago
    See https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107
  - forrestthewoods 6y ago
    > All of those are MBs in size, compared to KBs for their C counterparts. What difference does that make in the real world?
    - CameronNemo 6y ago
      An order of magnitude difference... my ARM boards have 16 MB SPI flash. No way I am fitting more than a single rust binary on there.
      - gpm 6y ago
        No way are you fitting a normal operating system on there. You can certainly compile rust to fit on there without any trouble though, you just have to try... the same way you have to try to compile any language in that sort of environment really. You can get to about 30kb while still keeping the standard library [1], you can get something with a fully featured web server in a few hundred kb [2]. [1] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust [2] https://jamesmunns.com/blog/tinyrocket/ https://jamesmunns.com/blog/tinyrocket/
Rochus 6y ago
There is no reason to assume it is the "Best Chance". There are a lot of other chances too, some even since more than two decades (e.g. Ada/Spark). Even C++ itself has not yet shot all the powder. And just as one can write secure code in C++, it will turn out in time that even with Rust not everything is as secure as propaganda would have you believe. I would be interested to know if this is really the official opinion of Microsoft, or if someone just wants to make a name for himself.
- zozbot234 6y ago
  Ada doesn't have a borrow checker.
  - Rochus 6y ago
    Why should it need one?
    - wtetzner 6y ago
      To support freeing heap allocations in a memory-safe way without relying on a GC.
      - Rochus 6y ago
        see https://news.ycombinator.com/item?id=15874273 https://news.ycombinator.com/item?id=15874273
        deleted 6y ago
        [deleted]
        deleted 6y ago
        [deleted]
      - Rochus 6y ago
        Here another one: https://news.ycombinator.com/item?id=17601789 https://news.ycombinator.com/item?id=17601789
crazypython 6y ago
I don't see why people take "Rust has affine types" and "affine types help us have safe systems programming" and then think "Rust is the only safe systems programming language."
- deleted 6y ago
  [deleted]
- Ar-Curunir 6y ago
  What are some other memory-safe languages that occupy the same position in the trade-off space as Rust?
  - crazypython 6y ago
    D with its borrow checker. D has a GC- yes- but that merely gives you the option of having tracing delete your memory. You can manually free GC memory and have it freed through RAII.
    - Ar-Curunir 6y ago
      Um, how is that better than Rust, which has better integration of, and soundness for its borrow checker?
- carapace 6y ago
  "best chance" not "only" FWIW, I suspect C with proper tools is fine, just fine. Also Ada is still a thing.
- fluffything 6y ago
  Because people like you, who suggest that there are alternatives, fail to mention them. Which other languages close to C, without a run-time, and without a garbage collector, give you proven memory and thread safety? Not C, not C++, not D, not Nim, not Go, not Swift, not Ada, ...
  - jfkebwjsbx 6y ago
blargmaster33 6y ago
Also included a SJW check to make sure any developer is a radical leftist.
fourcommas 6y ago
You shouldn't trust someone who misleads with: "Now, 70% of the CVEs originating at Microsoft are memory safety issues, Levick said. “There is no real trend it’s just staying the exact same,” he said. “Despite massive efforts on our part to fix this issue it still seems to be a common thing.”" There is a trend, and the trend has been a MASSIVE reduction in memory errors. The percentage of security issues that are memory errors says nothing of the totals, which is what matters. Microsoft could go through 2021 with only one CVE and we'd see articles like this saying "100% of security vulnerabilities are caused by memory errors, we must switch to Rust!"
- snazz 6y ago
  I agree. While Rust is clearly a step forward in programming languages (and we need a step forward), modern tools built to deal with the issues common in C and C++ like coverage-guided fuzzers, ASan, Valgrind, etc. have made huge improvements in finding memory safety vulnerabilities and other issues. Mitigations have also improved, making it more difficult to exploit memory safety issues. While I think that unmanaged (i.e. no runtime or interpreter) memory-safe programming languages are a good idea, they're not magic and we shouldn't ignore the other major security tooling improvements recently.
  - saagarjha 6y ago
    I should note that fuzzers/address sanitizer/Valgrind are very good tools, but they are not perfect. Projects that use them heavily still see issues due to memory-safety bugs. (And yes, memory-safe programming languages are not a magic bullet to fix all bugs; they just help with memory safety…)
- zozbot234 6y ago
  > There is a trend, and the trend has been a MASSIVE reduction in memory errors. The percentage of security issues that are memory errors says nothing of the totals, which is what matters. Except that CVE's seem to be increasing over time across the industry, not falling. There is no overall reduction in the numbers.
ncrmro 6y ago
Just starting to get into rust, got a nice a rest boilerplate that uses sqlx (compile time verification of sql) and some embedded stuff on a pi working with rust (PWM, Serial) My questions is where to find jobs with rust. I’m really enjoying it, but my resume is heavy python/react atm
- mpfundstein 6y ago
  start a business and do your projects in Rust. most clientd just care avout outcome. thats what I do and i have a lotnof fun trying new stuff with every new project.
  - scandox 6y ago
    Those clients may have trouble taking those projects in house or bringing them to another 3rd party developer! As an advisor on these kind of projects I usually advise clients to be very conservative about the tech used by 3rd party developers or agencies..
    - mpfundstein 6y ago
      the strategy of course is to serve them as long as possible ;-) no seriously. you are right. however that never had been a problem. mostly weird langauge choices also attract pretty capable developers.
  - ncrmro 6y ago
    Currently doing that, not a big fan of 40 hours for some one else.
    - mpfundstein 6y ago
      of course you should try to keep IP and resell if possible. there is no proper endgame in services. still better than being a slave employee
- kmonsen 6y ago
saagarjha 6y ago
> Rust excels in creating correct programs. Correctness means, roughly, that a program is checked by the compiler for unsafe operations, resulting in fewer runtime errors. This is a fairly low bar for correctness, and not really one I would really agree with :/
- neutronicus 6y ago
  Launching the missiles is memory-safe! Deleting the production database is a thornier philosophical question, but Rust's position is that it is.
  - saagarjha 6y ago
    Yeah, there's a couple of issues, one of which you mentioned :) Others are the fact that "runtime errors" are not necessarily bad; the goal is to prevent exploitable runtime errors. Crashing when you detect an out-of-bounds access is a bug and a runtime error, but one that is safe from a security perspective and as such something that Rust will do readily when necessary.
- dbaupp 6y ago
  Calling just “memory safety” correctness is a low bar and misses all sorts of other correctnesses (type safety, progress, matching-the-spec, etc.). However, it is a fundamental property: without memory safety, no other correctness can be guaranteed.
  - tapirl 6y ago
    So is it a property more important for inexperienced programmers?
    - entha_saava 6y ago
      You think only inexperienced programmers cause memory errors? I am no fan of rust and actually hate its evangelism. But this is ridiculous.
rvz 6y ago
That's if you use 'Safe Rust', then the safety guarantees hold true. However, the risks increase as soon as you start using unsafe{} or import a crate that also has unsafe{} code which is why I like using cargo-geiger on my projects to see the unsafe{} uses in my code and dependencies [0]. Use unsafe{} at your own risk. [1] [0] https://github.com/rust-secure-code/cargo-geiger https://github.com/rust-secure-code/cargo-geiger [1] https://arxiv.org/abs/2003.03296 https://arxiv.org/abs/2003.03296
- adamnemecek 6y ago
  Unsafe is not a problem in my experience. The same way a kernel might have some part written in asm (for freebsd it's like 1% I believe) your rust code will have 1% of Unsafe code. Might be more depending on what you are doing. However the same way few bugs happen in the asm code of a kernel, your unsafe will not have many bugs.
  - saagarjha 6y ago
    Actually, a lot of bugs happen in the assembly part of the kernel. Processors are hard ;)
    - loeg 6y ago
      Do you have a source for that claim?
      - saagarjha 6y ago
        A couple examples off the top of my head: all the recent speculative execution stuff, OpenBSD's buggy SMAP implementation, some recent bugs ARM's PAN.
        adamnemecek 6y ago
        OK thats how many 10? How many are not asm bugs? Like it's not many considering the total number of bugs.
boromi 6y ago
Has anyone worked on rust for microcontrollers? STM32 and Arduiono ?
- Rust4w4y 6y ago
  Easy peasy: https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/
dijit 6y ago
A lot of 'anti-rust' sentiment here. Personally, I think the article is somewhat correct. Well vetted and tested C (or C++) is great, but even the guys who are looking for these things get it wrong sometimes. Rust isn't perfect, and I think the negative reaction is people thinking that evangelists consider it perfect. But I certainly wouldn't call it perfect, and I'm rather fond of Rust. That said, I still think it's the "best chance", that doesn't mean it's the only possible thing to make headway into more safe systems, but it means that it has the 'best chance'.. Maybe you can make D memory safe, but when I was getting into D development I couldn't even get a compiler working. Maybe Ada is your favourite, but I don't know anyone writing Ada and integrating it with a C codebase. -- Frankly it comes down to the fact that Rust was designed specifically for replacing components of a large C++ codebase that it will be adopted. If you can write a driver that works with linux that's written in rust and you don't have as many memory safety issues or concurrency problems (and theres no overhead) then that's reasonable. Even if Rust never gets supported by the kernel's buildsystem officially or if the code can not be upstreamed.
- pcstl 6y ago
  "Anti-rust sentiment"? I'm a Rust user, a fan of the language, and I believe it's a great step forward for systems programming. However, it's kind of ridiculous how on any thread about Rust, anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. Just look at what happened to the comments critical of Rust on this post. The Rust community really needs to take care not to become an echo chamber.
  - rvz 6y ago
    > The Rust community really needs to take care not to become an echo chamber. Exactly. The language has been proven to be stable, however a valid argument is the unsoundness risks of a project when they begin to depend on lots of third-party crates. The moment one imports a crate or third party dependency into their project, unless the dependency explicitly specifies the lack of unsafe{}, all bets are off on the 'safety guarantees', especially when 'that crate' is used in multiple projects.
CoolGuySteve 6y ago
Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. While Intel/AMD have put incredible effort into hyperthreading, virtualization, predictive loading, etc, page faults have more or less stayed the same since the NX bit was introduced. The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. Per-process hardware encrypted memory would also mitigate spectre and friends as reading another process's memory would become meaningless.
- zozbot234 6y ago
  > Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. ... The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. This isn't really true. The main performance cost of these safety checks (and largely of others such as overflow checking) is inability to optimize because the compiler needs to preserve partial results/states in case a fault occurs. The checks themselves are trivial.
  - CoolGuySteve 6y ago
    Partial results like, say, a hardware exception firing instead of forcing the compiler to reason about it? I want efence on steroids.
    - arcticbull 6y ago
      To the maximum extent, bounds checking should be elided via greater compiler knowledge of what exactly is happening. This would leave arbitrary bounds checks limited to user input, in which case the vast majority of the performance penalty goes away right? "Bounds" are a higher-order programming language concept that I suggest may not have a place in hardware.
      - steveklabnik 6y ago
bob1029 6y ago
What is the exact aspect of "systems programming" that precludes the use of higher-level languages which are safe by default? Unless we are writing device drivers or OS kernels, why are we using these low-level languages for mission-critical applications? Even parts of managed languages which are typically frowned upon from a "systems programming" perspective, such as GC, can be viewed as a positive when trying to iterate. GC can be treated like a backstop which helps to keep your application from exploding while you work on memory management, and then you can incrementally address heap alloc (aka latency) concerns with an application that actually runs (for a little while at least). Trying to iterate on memory pressure and related concerns with a C/C++ application is nothing short of nightmare fuel from my perspective, but I spend most of my time in higher-level languages these days. I think it is also very hard to make a performance argument in 2020. Especially when you are comparing low level against something like the newest C#/.NET Core stack. Just take a look at the most recent TechEmpower plaintext benchmark (round 19). How many new business "systems" are being "programmed" that aren't ultimately just web servers passing HTML/JSON around, executing business logic, and reading/writing bits of data to some database?
- throw_m239339 6y ago
  > What is the exact aspect of "systems programming" that precludes the use of higher-level languages which are safe by default? Unless we are writing device drivers or OS kernels, why are we using these low-level languages for mission-critical applications? IMHO "systems" here means running on an OS, not network systems or internet apps. So None, but you want to write libraries that are easily linked to all manners of 3rd party languages and can squeeze the last drop of OS performance. Your language with automatic garbage collection cannot do that. If all you end up doing is wrapping stuff with C or C++ headers then better use C or C++ at first place.
- zozbot234 6y ago
  > GC can be treated like a backstop which helps to keep your application from exploding while you work on memory management, and then you can incrementally address heap alloc (aka latency) concerns with an application that actually runs (for a little while at least). This is not a good approach in general. GC is only really needed in applications when working with data that's graph-like and potentially involves cycles of object references. A software project should be properly designed at the outset so that GC can be used in a "pluggable" way where it's strictly needed. Rust will probably enable this kind of use in the future, but other languages such as Go can already be used to comparable effect, seeing as they're generally limited to smaller pieces of code ("microservices") running in their own separate address space.
carapace 6y ago
Does anyone have a link to a good Rust vs. D comparison?
GnarfGnarf 6y ago
Is Rust a good choice for applications programming? Does it support GUI (dialogs, etc).
- ArchieMaclean 6y ago
  https://areweguiyet.com/ https://areweguiyet.com/ TL;DR it has some support; however most libraries are just C bindings, or else they are very domain-specific. You can, but it is not as smooth as using other languages.
- adamnemecek 6y ago
  I think it a language that let's you write your own GUI toolkit. Like all gui solutions are kinda bad.
- RMPR 6y ago
  https://areweguiyet.com/ https://areweguiyet.com/ https://runrust.miraheze.org/wiki/GUI_Creation https://runrust.miraheze.org/wiki/GUI_Creation
- raphlinus 6y ago
  I am finding Rust to be a most excellent language for implementing GUI. There are several active projects working on this (linked in sibling comments), and I think progress is encouraging.
childintime 6y ago
It's sort of ironic that today I tried to install Rust through rustup-init.exe, on Windows, and it didn't work because of its dependency on Microsoft Visual C++ Build Tools 2019. Rustup keeps saying "Install the C++ build tools before proceeding", though it did install from the rustup provided link. Developer installs continue heavily invested in dangling pointers (called paths) and other unsafe practices, C/C++ style. I find that baffling.
- steveklabnik 6y ago
  The context here is that this is the only way to get link.exe; if there were any easier way to do it, we would!
  - jfkebwjsbx 6y ago
    Why do you need link.exe? Why don’t you use LLVM’s linker?
    - steveklabnik 6y ago
      It’s sort of definitional, the MSVC target uses the MSVC linker by default. Some platforms, like wasm, do use lld by default, and you can override the linker if you choose. MSVC is the default because it’s the platform default, just as the Linux targets default to glibc rather than MUSL, for example.
      - jfkebwjsbx 6y ago
        One can argue that using the default linker is a good choice, and that is a good argument, but I don’t see how that is definitional. Btw, wasn’t Chrome and others switching soon to LLD?
        steveklabnik 6y ago
        I mean “The MSVC target uses the MSVC linker so that’s why you need the MSCV linker.” Yes, they are. Not sure how that’s relevant, though.
rbanffy 6y ago
I would go as far as saying it's Microsoft's best chance at safe systems programming, but no further. I love Rust, but I'd refrain from such sweeping statements until other options evolve and get the opportunity to be time tested.
moonchild 6y ago
Surprised this is coming from the company that helped build f* (https://fstar-lang.org/ https://fstar-lang.org/)
- phkahler 6y ago
  The second danger to Rust would be MS pulling Embrace, Extend, Extinguish with it. Dont think so? What are they on now, DX12? Still trying to own the graphics API.
choeger 6y ago
If only it had dynamic linking... I know, I know, efficient, separate compilation and parametric polymorphism are hard to get together, but a systems language should not follow the same compilation model as, e.g., Haskell.
- zozbot234 6y ago
  You can use dynamic linking, it's just restricted to the C ABI. But this has its benefits in that if your dylibs are written properly, they'll be usable from C and C-compatible languages as well. "Wrapping" code can be statically linked and provide higher-level features.
combatentropy 6y ago
When people talk about Rust's advantage in safety, is it just the compile-time checks about Ownership? Could not the C compiler be given the same thing, with a flag like "strict mode"? Sorry if my question is really stupid. My experience has been with scripting languages, not systems programming. But I read the chapter in the Rust Book about Ownership, and I think I get it. In a sense, is not the compiler simply inserting function calls to free() in the right places (and warning you if it can't)? Couldn't this be added to the C compiler? In fact I'm not sure what the difference is from a linter. The article has the phrase "C/C++ Can’t Be Fixed", so it anticipates my question. But its answer is that programmers either won't remember or won't bother to set their C to "strict mode", run the linter, or whatever, because "static analysis comes with too much overhead: It needs to be wired into the build system. . . . If it’s not on by default it won’t it won't help." But if this is the only argument, it seems weak. I agree that it is more effort, but isn't it much more effort to switch out your entire language and ecosystem?
- rubber_duck 6y ago
  "strict mode" is not a subset - you need stronger type information than what C provides to get Rust level checking - if you wanted to add that to C and also make it expressive enough to be usable you'd eventually end up with something that's closer to Rust than C.
- nicoburns 6y ago
  The issue is that C/C++ Can’t Be Fixed backwards compatibly. You would need to add lifetime annotations: existing code wouldn't compile. You could make a Rust-style language that is closer to C, but it wouldn't be any to use than Rust. And at that point why not just use Rust. It doesn't require you to switch out the entire ecosystem, you can happily link Rust and C, and C++ together in one binary. In fact, as an end-user it's sometimes easier to use a popular C library from Rust because someone will have wired it into Cargo (Rust's build system) and it will "just work": you don't have to mess around with working out what kind of build system the library is using and integrate it with whatever your using.
  - jfkebwjsbx 6y ago
hansdieter1337 6y ago
My first thought: oh no. M$ likes Rust and will probably contribute and demolish it. Just look at the Github system status history since M$ took over. Or Azure, Windows 10, ...
fortran77 6y ago
I'm disappointed they didn't double-down on what I feel is the best general purpose programming language C# (and related F#). It has a great toolset, generates good code, and with a good microkernel architecture (which Windows 10 is, mostly) 90% of "systems" programming would be fine in a garbage-collected language.
exdsq 6y ago
I heard the Rust API changes between versions such that it’s a bit of a pain upgrading systems. Is this true? Also, I’ve read traits can be used as invariants for a pseudo-dependent type system. Has anyone had experience with this? I’m considering learning it instead of C++ for some systems work.
- jfkebwjsbx 6y ago
  If your systems work do not require stable compilers or rely too much on external C++ APIs, then you will be mostly fine.
  - exdsq 6y ago
    It’s mostly to trace process performance, network load, stuff like that.
- jasondclinton 6y ago
  > I heard the Rust API changes between versions such that it’s a bit of a pain upgrading systems. Is this true? No, this isn't true. https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html#what-is-rust-2018 https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html... was the last change and it was optional and automated migration.
- dagmx 6y ago
  For your first point, you might be thinking of ABI and not API? Rust doesn’t have a stable ABI but the API is non breaking as long as you aren’t on nightly AND opting into unstable features. If you stay on stable Rust, you’ll not really have breaking changes between versions. Regarding ABI , that means that if you compile rust into a library with one version, you can’t reuse that compiled library in a newer version of the compiler, unless you go through a stable ABI like exposing a C interface. However if you recompile your code, it’ll work. You need to keep them compiled by the same compiler version.
vinay_ys 6y ago
I think 'best chance' at safe programming is the advances in chip design. I expect PMMU to become more sophisticated and solve more of the memory safety problems in hardware than in software. Then, the programming model will evolve and safety features will become more language agnostic and broadly available. Then, I fully expect compiler+runtime+os to evolve to take advantage of these hardware features for software written in any language.
stephc_int13 6y ago
This is magical thinking, switching language won't solve the problem. Complexity is the problem, hard-to-read code is the problem, over-engineering is the problem.
- asperous 6y ago
  I think its systems thinking. With 40,000 developers, Microsoft is too large to fix the problems you mentioned. They need a broad stroke change to reduce vulnerabilities. The article says they've tried many things and believe moving to rust might work.
  - stephc_int13 6y ago
    Yeah, MS clearly has serious maintenance issues with their codebase, for obvious reasons. They tried many things in the past, including C# and .NET, I'm not sure if that really helped or made things worse.
- muldvarp 6y ago
  > This is magical thinking, switching language won't solve the problem. It won't solve the problem, but it can be an important step towards a solution. > Complexity is the problem, hard-to-read code is the problem, over-engineering is the problem. I actually disagree. Many memory safety issues are not the result of hard-to-read or over-engineered code, but are instead due to careless memory management. Safe Rust code (no matter how hard-to-read or over-engineered) can guarantee memory safety.
  - stephc_int13 6y ago
    If it was that easy to fix, this problem would have been fixed a long time ago, by many other "safe" languages. My bet is that Rust won't help nearly as much as people tend to think.
    - muldvarp 6y ago
      > If it was that easy to fix, this problem would have been fixed a long time ago, by many other "safe" languages. There are many other memory safe languages. Those usually have a GC though. > My bet is that Rust won't help nearly as much as people tend to think. Why not? Memory safety issues are common and safe Rust code eliminates them.
userbinator 6y ago
Best chance at creating an even more dystopian future where authoritarian governments and corporations control exactly what "your" computing devices can do and you can't "jailbreak" out of? Yes, I know Rust is not a panacea, but I feel like the whole paranoia around safety/security is just leading us towards that sort of society, technology included. It seems that there was somewhat of a balance before, which allowed for some sort of "civil disobedience" (jailbreaking, rooting, cracking, etc.), and now that freedom is slowly disappearing.
- signal11 6y ago
  This is the strangest critique of writing more secure code I've seen. Yes, more secure code does reduce the chance of jailbreaks, but insecure code is overwhelmingly used more by criminals and state actors to try and break into your computer. Secure Code helps all computer users, the 'little guy' most of all. And you can always vote with your wallet (or, you know, vote) to keep your digital liberties. Blaming a better tool for eroding your liberties seems ... strange.
  - missosoup 6y ago
    State actors and high tier criminal orgs will always have a way into your digital life. In a way, making code more secure is just creating an asymmetry where regular joe can't break into a device but only state actors and other major players can. I can sort of understand GP's sentiment. If someone really wants to hack me, they will. Or they'll find some other vector. The prevalence of memory safe code doesn't really impact my own security as an individual. But it does impact my ability to jailbreak and own my devices. There was a similar discussion around the intel Trusted Computing concept. It was not a platform that ultimately benefited the user, it was a platform for user-hostile forces to 'trust' that the user isn't interfering with the code they want to execute on the user's device. Slowly but surely we're moving towards a world where user devices are merely thin clients over corporate and government owned systems, and don't really belong to the user at all.
  - asdff 6y ago
    A good hacker can always break in. In fact the most common and most effective hacking doesn't involve technology at all: social engineering. All this sort of walled garden thinking does is make it just a little bit more challenging for people to learn more about the tools they've purchased and own outright, and how to best make use of them for their own needs. Today, when macOS gives me warnings and asks permission for inane things, like terminal needing permission to look into ~/Downloads or ~/Documents, I and everyone else with some experience in technology just rolls their eyes at this request and move on. This would be like if my new toothbrush asked me 'are you sure you want to brush your teeth in this bathroom?' However, to someone not familiar with technology and Apple's security logic of recent years, these requests might seem terrifying, and scare off what could be bright minds who could have contributed to the field of computer science had they not been questioned at every turn by their operating system of their intentions. You learn by breaking things, after all.
lambingan 6y ago
Here you Can Download the Latest Apps and Games https://kingmodapk.com/ https://kingmodapk.com/ For Android and Ios User
jfkebwjsbx 6y ago
When is Microsoft going to release first-class Rust support in Visual Studio and Windows, including debugger and official Rust bindings for their most commonly used APIs like Win32, Direct3D, etc.?
- s_y_n_t_a_x 6y ago
  I don't think this is exactly what you want, but you might be interested in it: https://github.com/microsoft/winrt-rs https://github.com/microsoft/winrt-rs
  - jfkebwjsbx 6y ago
    Not really, but thanks! Hopefully they will start adding more bindings...
- adamnemecek 6y ago
  VS Code is the best Rust editor.
  - jfkebwjsbx 6y ago
    Yes, but an editor is just one of the pieces.
tyrion 6y ago
The fact that Microsoft keeps saying it wants to move away from C/C++ is great IMHO. > Microsoft c++ continues to be written and will continue to be written for a while I interpret this as saying that they cannot instantaneously convert all their existing code to Rust, and it seems fair enough. However, it seems a little odd to start new projects in C/C++ when you are publicly saying it's the wrong thing to do. Infact, just a little over a month ago they announced a new QUIC implementation written in C/C++ (MsQuic) Is this to be expected since Microsoft is such a big company? Or maybe that lib is not important and is not going to be used in, say, Edge? Moreover, isn't networking code the worst kind of code to write in C/C++ (I am thinking of heartbleed for example)? I would really love some explanation.
- adolfojp 6y ago
  The more I learn about Microsoft the more this joke makes sense: https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org_charts%22_comic_by_Manu_Cornet.png https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org...
- pjmlp 6y ago
  Which is why they are the main drivers for C++ Core Guidelines, and have contributed the initial effort of a C++ lifetime analyses to clang, while making it available in all Visual Studio editions, including Community. They are quite clear that a constraint version of C++ still gets to play in a secure world. And while Azure Sphere still gets to be written in C (due to Linux kernel), it has a security layer (Pollonium) that takes care of bad code. Finally, since they failed to move people into UWP programming model, sandboxing has been coming into Win32 as well, to the point that on Windows 10X, everything is sandboxed, including Win32 apps.
fuddle 6y ago
I'm a big fan of Rust, they only issue I have is that the compile time is painfully slow. Hopefully it can be improved in the future.
pizlonator 6y ago
PL is still a fast moving field, so claims that any language is a “best chance” for something are likely to have a short shelf life.
kbenson 6y ago
A lot of tooling is built around C/C++. In particular, Microsoft binaries are now almost completely built on the Microsoft Visual C++ compiler which produces MSVC binaries, whereas Rust relies on LLVM. Maybe providing/funding a different back-end would be a worthwhile endeavor for Microsoft to do or fund.
winrid 6y ago
Great. Now rewrite all the slow C# apps in Windows. :)
libman 6y ago
Nim and D are better.
pull_my_finger 6y ago
If they want to use Rust, and have more faith in it than their own Verona[1], then they should discontinue Verona dev and let those developers go back to Pony[2]. I imagine having their core team working on Verona full-time is considerably delaying Pony development. [1] - https://github.com/microsoft/verona https://github.com/microsoft/verona [2] - https://github.com/ponylang/ponyc https://github.com/ponylang/ponyc (edit: formatting)
lloydatkinson 6y ago
It's a shame its such an ugly language then

523 points by adamnemecek 6y ago

What role (if any) does GCC play in Rust? I understand that Rust relies on LLVM. If the industry continues to move more and more to Rust then will GCC begin to lose relevance? Or will the GCC developers add a Rust ~~backend~~ frontend? Has there been any movement toward that anyway? There are many gaps in my understanding of Rust with regard to LLVM and GCC.

klysm 6y ago
I’m not sure about GCC, but a significant amount of work has gone into a cranelift based backend for rust (https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift).
steveklabnik 6y ago
https://users.rust-lang.org/t/call-for-help-implementing-an-independent-rust-frontend-for-gcc/32163/ https://users.rust-lang.org/t/call-for-help-implementing-an-...
konschubert 6y ago
Wouldn’t you need to add a RUST frontend?
- VWWHFSfQ 6y ago
  ah right
redrobein 6y ago
> There are many gaps in my understanding of Rust with regard to LLVM and GCC. The rust compiler generates some intermediate code (LLVM IR) that's fed into LLVM, which optimizes and turns it into machine code. You can check out what this looks like in the rust playground. Getting GCC to compile rust would be a matter of getting the rust compiler to generate GCC IR. Cranelift (built with rust) is an alternative to LLVM with it's own IR. The cranelift backend for rust should help future projects that want to do something similar, I guess.
orangeshark 6y ago
There was a rust frontend for GCC[0]. Will need a lot to work though. [0]: https://gcc.gnu.org/wiki/RustFrontEnd https://gcc.gnu.org/wiki/RustFrontEnd
fsloth 6y ago
"will GCC begin to lose relevance" Systems programming is not web where they change the framework and 'script flavour every six months. Systems programs live for decades - and hence their critical infrastructure like GCC will as well. C will be with us at least 3 decades more. Longer if Linux kernel will use it still.
Jyaif 6y ago
> then will GCC begin to lose relevance? That has already began. For example all the popular browsers (Chrome and all the derivatives, FF, Safari) moved away from GCC.

jph 6y ago

Rust is definitely great for systems programming, and the speed is fantastic too. Take a look at some of the system utility tools on crates.io, such as ripgrep (like grep), bat (like cat), fd-find (like find), lolcate-rs (like locate), procs (like ps).

CameronNemo 6y ago
All of those are MBs in size, compared to KBs for their C counterparts. Something needs to budge in Rust land for small utilities to be viable.
- deleted 6y ago
  [deleted]
- zozbot234 6y ago
  See https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107
- forrestthewoods 6y ago
  > All of those are MBs in size, compared to KBs for their C counterparts. What difference does that make in the real world?
  - CameronNemo 6y ago
    An order of magnitude difference... my ARM boards have 16 MB SPI flash. No way I am fitting more than a single rust binary on there.
    - gpm 6y ago
      No way are you fitting a normal operating system on there. You can certainly compile rust to fit on there without any trouble though, you just have to try... the same way you have to try to compile any language in that sort of environment really. You can get to about 30kb while still keeping the standard library [1], you can get something with a fully featured web server in a few hundred kb [2]. [1] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust [2] https://jamesmunns.com/blog/tinyrocket/ https://jamesmunns.com/blog/tinyrocket/

Rochus 6y ago

There is no reason to assume it is the "Best Chance". There are a lot of other chances too, some even since more than two decades (e.g. Ada/Spark). Even C++ itself has not yet shot all the powder. And just as one can write secure code in C++, it will turn out in time that even with Rust not everything is as secure as propaganda would have you believe. I would be interested to know if this is really the official opinion of Microsoft, or if someone just wants to make a name for himself.

zozbot234 6y ago
Ada doesn't have a borrow checker.
- Rochus 6y ago
  Why should it need one?
  - wtetzner 6y ago
    To support freeing heap allocations in a memory-safe way without relying on a GC.
    - Rochus 6y ago
      see https://news.ycombinator.com/item?id=15874273 https://news.ycombinator.com/item?id=15874273
      - deleted 6y ago
        [deleted]
      - deleted 6y ago
        [deleted]
    - Rochus 6y ago
      Here another one: https://news.ycombinator.com/item?id=17601789 https://news.ycombinator.com/item?id=17601789

crazypython 6y ago

I don't see why people take "Rust has affine types" and "affine types help us have safe systems programming" and then think "Rust is the only safe systems programming language."

deleted 6y ago
[deleted]
Ar-Curunir 6y ago
What are some other memory-safe languages that occupy the same position in the trade-off space as Rust?
- crazypython 6y ago
  D with its borrow checker. D has a GC- yes- but that merely gives you the option of having tracing delete your memory. You can manually free GC memory and have it freed through RAII.
  - Ar-Curunir 6y ago
    Um, how is that better than Rust, which has better integration of, and soundness for its borrow checker?
carapace 6y ago
"best chance" not "only" FWIW, I suspect C with proper tools is fine, just fine. Also Ada is still a thing.
fluffything 6y ago
Because people like you, who suggest that there are alternatives, fail to mention them. Which other languages close to C, without a run-time, and without a garbage collector, give you proven memory and thread safety? Not C, not C++, not D, not Nim, not Go, not Swift, not Ada, ...
- jfkebwjsbx 6y ago

blargmaster33 6y ago

Also included a SJW check to make sure any developer is a radical leftist.

fourcommas 6y ago

You shouldn't trust someone who misleads with: "Now, 70% of the CVEs originating at Microsoft are memory safety issues, Levick said. “There is no real trend it’s just staying the exact same,” he said. “Despite massive efforts on our part to fix this issue it still seems to be a common thing.”" There is a trend, and the trend has been a MASSIVE reduction in memory errors. The percentage of security issues that are memory errors says nothing of the totals, which is what matters. Microsoft could go through 2021 with only one CVE and we'd see articles like this saying "100% of security vulnerabilities are caused by memory errors, we must switch to Rust!"

snazz 6y ago
I agree. While Rust is clearly a step forward in programming languages (and we need a step forward), modern tools built to deal with the issues common in C and C++ like coverage-guided fuzzers, ASan, Valgrind, etc. have made huge improvements in finding memory safety vulnerabilities and other issues. Mitigations have also improved, making it more difficult to exploit memory safety issues. While I think that unmanaged (i.e. no runtime or interpreter) memory-safe programming languages are a good idea, they're not magic and we shouldn't ignore the other major security tooling improvements recently.
- saagarjha 6y ago
  I should note that fuzzers/address sanitizer/Valgrind are very good tools, but they are not perfect. Projects that use them heavily still see issues due to memory-safety bugs. (And yes, memory-safe programming languages are not a magic bullet to fix all bugs; they just help with memory safety…)
zozbot234 6y ago
> There is a trend, and the trend has been a MASSIVE reduction in memory errors. The percentage of security issues that are memory errors says nothing of the totals, which is what matters. Except that CVE's seem to be increasing over time across the industry, not falling. There is no overall reduction in the numbers.

ncrmro 6y ago

Just starting to get into rust, got a nice a rest boilerplate that uses sqlx (compile time verification of sql) and some embedded stuff on a pi working with rust (PWM, Serial) My questions is where to find jobs with rust. I’m really enjoying it, but my resume is heavy python/react atm

mpfundstein 6y ago
start a business and do your projects in Rust. most clientd just care avout outcome. thats what I do and i have a lotnof fun trying new stuff with every new project.
- scandox 6y ago
  Those clients may have trouble taking those projects in house or bringing them to another 3rd party developer! As an advisor on these kind of projects I usually advise clients to be very conservative about the tech used by 3rd party developers or agencies..
  - mpfundstein 6y ago
    the strategy of course is to serve them as long as possible ;-) no seriously. you are right. however that never had been a problem. mostly weird langauge choices also attract pretty capable developers.
- ncrmro 6y ago
  Currently doing that, not a big fan of 40 hours for some one else.
  - mpfundstein 6y ago
    of course you should try to keep IP and resell if possible. there is no proper endgame in services. still better than being a slave employee
kmonsen 6y ago

saagarjha 6y ago

> Rust excels in creating correct programs. Correctness means, roughly, that a program is checked by the compiler for unsafe operations, resulting in fewer runtime errors. This is a fairly low bar for correctness, and not really one I would really agree with :/

neutronicus 6y ago
Launching the missiles is memory-safe! Deleting the production database is a thornier philosophical question, but Rust's position is that it is.
- saagarjha 6y ago
  Yeah, there's a couple of issues, one of which you mentioned :) Others are the fact that "runtime errors" are not necessarily bad; the goal is to prevent exploitable runtime errors. Crashing when you detect an out-of-bounds access is a bug and a runtime error, but one that is safe from a security perspective and as such something that Rust will do readily when necessary.
dbaupp 6y ago
Calling just “memory safety” correctness is a low bar and misses all sorts of other correctnesses (type safety, progress, matching-the-spec, etc.). However, it is a fundamental property: without memory safety, no other correctness can be guaranteed.
- tapirl 6y ago
  So is it a property more important for inexperienced programmers?
  - entha_saava 6y ago
    You think only inexperienced programmers cause memory errors? I am no fan of rust and actually hate its evangelism. But this is ridiculous.

rvz 6y ago

That's if you use 'Safe Rust', then the safety guarantees hold true. However, the risks increase as soon as you start using unsafe{} or import a crate that also has unsafe{} code which is why I like using cargo-geiger on my projects to see the unsafe{} uses in my code and dependencies [0]. Use unsafe{} at your own risk. [1] [0] https://github.com/rust-secure-code/cargo-geiger https://github.com/rust-secure-code/cargo-geiger [1] https://arxiv.org/abs/2003.03296 https://arxiv.org/abs/2003.03296

adamnemecek 6y ago
Unsafe is not a problem in my experience. The same way a kernel might have some part written in asm (for freebsd it's like 1% I believe) your rust code will have 1% of Unsafe code. Might be more depending on what you are doing. However the same way few bugs happen in the asm code of a kernel, your unsafe will not have many bugs.
- saagarjha 6y ago
  Actually, a lot of bugs happen in the assembly part of the kernel. Processors are hard ;)
  - loeg 6y ago
    Do you have a source for that claim?
    - saagarjha 6y ago
      A couple examples off the top of my head: all the recent speculative execution stuff, OpenBSD's buggy SMAP implementation, some recent bugs ARM's PAN.
      - adamnemecek 6y ago
        OK thats how many 10? How many are not asm bugs? Like it's not many considering the total number of bugs.

boromi 6y ago

Has anyone worked on rust for microcontrollers? STM32 and Arduiono ?

Rust4w4y 6y ago
Easy peasy: https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/ https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/

dijit 6y ago

A lot of 'anti-rust' sentiment here. Personally, I think the article is somewhat correct. Well vetted and tested C (or C++) is great, but even the guys who are looking for these things get it wrong sometimes. Rust isn't perfect, and I think the negative reaction is people thinking that evangelists consider it perfect. But I certainly wouldn't call it perfect, and I'm rather fond of Rust. That said, I still think it's the "best chance", that doesn't mean it's the only possible thing to make headway into more safe systems, but it means that it has the 'best chance'.. Maybe you can make D memory safe, but when I was getting into D development I couldn't even get a compiler working. Maybe Ada is your favourite, but I don't know anyone writing Ada and integrating it with a C codebase. -- Frankly it comes down to the fact that Rust was designed specifically for replacing components of a large C++ codebase that it will be adopted. If you can write a driver that works with linux that's written in rust and you don't have as many memory safety issues or concurrency problems (and theres no overhead) then that's reasonable. Even if Rust never gets supported by the kernel's buildsystem officially or if the code can not be upstreamed.

pcstl 6y ago
"Anti-rust sentiment"? I'm a Rust user, a fan of the language, and I believe it's a great step forward for systems programming. However, it's kind of ridiculous how on any thread about Rust, anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. Just look at what happened to the comments critical of Rust on this post. The Rust community really needs to take care not to become an echo chamber.
- rvz 6y ago
  > The Rust community really needs to take care not to become an echo chamber. Exactly. The language has been proven to be stable, however a valid argument is the unsoundness risks of a project when they begin to depend on lots of third-party crates. The moment one imports a crate or third party dependency into their project, unless the dependency explicitly specifies the lack of unsafe{}, all bets are off on the 'safety guarantees', especially when 'that crate' is used in multiple projects.

CoolGuySteve 6y ago

Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. While Intel/AMD have put incredible effort into hyperthreading, virtualization, predictive loading, etc, page faults have more or less stayed the same since the NX bit was introduced. The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. Per-process hardware encrypted memory would also mitigate spectre and friends as reading another process's memory would become meaningless.

zozbot234 6y ago
> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking. ... The world would be a lot safer if we had hardware features like cacheline faults, poison words, bounded MOV instructions, hardware ASLR, and auto-encrypted cachelines. This isn't really true. The main performance cost of these safety checks (and largely of others such as overflow checking) is inability to optimize because the compiler needs to preserve partial results/states in case a fault occurs. The checks themselves are trivial.
- CoolGuySteve 6y ago
  Partial results like, say, a hardware exception firing instead of forcing the compiler to reason about it? I want efence on steroids.
  - arcticbull 6y ago
    To the maximum extent, bounds checking should be elided via greater compiler knowledge of what exactly is happening. This would leave arbitrary bounds checks limited to user input, in which case the vast majority of the performance penalty goes away right? "Bounds" are a higher-order programming language concept that I suggest may not have a place in hardware.
    - steveklabnik 6y ago

bob1029 6y ago

What is the exact aspect of "systems programming" that precludes the use of higher-level languages which are safe by default? Unless we are writing device drivers or OS kernels, why are we using these low-level languages for mission-critical applications? Even parts of managed languages which are typically frowned upon from a "systems programming" perspective, such as GC, can be viewed as a positive when trying to iterate. GC can be treated like a backstop which helps to keep your application from exploding while you work on memory management, and then you can incrementally address heap alloc (aka latency) concerns with an application that actually runs (for a little while at least). Trying to iterate on memory pressure and related concerns with a C/C++ application is nothing short of nightmare fuel from my perspective, but I spend most of my time in higher-level languages these days. I think it is also very hard to make a performance argument in 2020. Especially when you are comparing low level against something like the newest C#/.NET Core stack. Just take a look at the most recent TechEmpower plaintext benchmark (round 19). How many new business "systems" are being "programmed" that aren't ultimately just web servers passing HTML/JSON around, executing business logic, and reading/writing bits of data to some database?

throw_m239339 6y ago
> What is the exact aspect of "systems programming" that precludes the use of higher-level languages which are safe by default? Unless we are writing device drivers or OS kernels, why are we using these low-level languages for mission-critical applications? IMHO "systems" here means running on an OS, not network systems or internet apps. So None, but you want to write libraries that are easily linked to all manners of 3rd party languages and can squeeze the last drop of OS performance. Your language with automatic garbage collection cannot do that. If all you end up doing is wrapping stuff with C or C++ headers then better use C or C++ at first place.
zozbot234 6y ago
> GC can be treated like a backstop which helps to keep your application from exploding while you work on memory management, and then you can incrementally address heap alloc (aka latency) concerns with an application that actually runs (for a little while at least). This is not a good approach in general. GC is only really needed in applications when working with data that's graph-like and potentially involves cycles of object references. A software project should be properly designed at the outset so that GC can be used in a "pluggable" way where it's strictly needed. Rust will probably enable this kind of use in the future, but other languages such as Go can already be used to comparable effect, seeing as they're generally limited to smaller pieces of code ("microservices") running in their own separate address space.

carapace 6y ago

Does anyone have a link to a good Rust vs. D comparison?

GnarfGnarf 6y ago

Is Rust a good choice for applications programming? Does it support GUI (dialogs, etc).

ArchieMaclean 6y ago
https://areweguiyet.com/ https://areweguiyet.com/ TL;DR it has some support; however most libraries are just C bindings, or else they are very domain-specific. You can, but it is not as smooth as using other languages.
adamnemecek 6y ago
I think it a language that let's you write your own GUI toolkit. Like all gui solutions are kinda bad.
RMPR 6y ago
https://areweguiyet.com/ https://areweguiyet.com/ https://runrust.miraheze.org/wiki/GUI_Creation https://runrust.miraheze.org/wiki/GUI_Creation
raphlinus 6y ago
I am finding Rust to be a most excellent language for implementing GUI. There are several active projects working on this (linked in sibling comments), and I think progress is encouraging.

childintime 6y ago

It's sort of ironic that today I tried to install Rust through rustup-init.exe, on Windows, and it didn't work because of its dependency on Microsoft Visual C++ Build Tools 2019. Rustup keeps saying "Install the C++ build tools before proceeding", though it did install from the rustup provided link. Developer installs continue heavily invested in dangling pointers (called paths) and other unsafe practices, C/C++ style. I find that baffling.

steveklabnik 6y ago
The context here is that this is the only way to get link.exe; if there were any easier way to do it, we would!
- jfkebwjsbx 6y ago
  Why do you need link.exe? Why don’t you use LLVM’s linker?
  - steveklabnik 6y ago
    It’s sort of definitional, the MSVC target uses the MSVC linker by default. Some platforms, like wasm, do use lld by default, and you can override the linker if you choose. MSVC is the default because it’s the platform default, just as the Linux targets default to glibc rather than MUSL, for example.
    - jfkebwjsbx 6y ago
      One can argue that using the default linker is a good choice, and that is a good argument, but I don’t see how that is definitional. Btw, wasn’t Chrome and others switching soon to LLD?
      - steveklabnik 6y ago
        I mean “The MSVC target uses the MSVC linker so that’s why you need the MSCV linker.” Yes, they are. Not sure how that’s relevant, though.

rbanffy 6y ago

I would go as far as saying it's Microsoft's best chance at safe systems programming, but no further. I love Rust, but I'd refrain from such sweeping statements until other options evolve and get the opportunity to be time tested.

moonchild 6y ago

Surprised this is coming from the company that helped build f* (https://fstar-lang.org/ https://fstar-lang.org/)

phkahler 6y ago
The second danger to Rust would be MS pulling Embrace, Extend, Extinguish with it. Dont think so? What are they on now, DX12? Still trying to own the graphics API.

choeger 6y ago

If only it had dynamic linking... I know, I know, efficient, separate compilation and parametric polymorphism are hard to get together, but a systems language should not follow the same compilation model as, e.g., Haskell.

zozbot234 6y ago
You can use dynamic linking, it's just restricted to the C ABI. But this has its benefits in that if your dylibs are written properly, they'll be usable from C and C-compatible languages as well. "Wrapping" code can be statically linked and provide higher-level features.

combatentropy 6y ago

When people talk about Rust's advantage in safety, is it just the compile-time checks about Ownership? Could not the C compiler be given the same thing, with a flag like "strict mode"? Sorry if my question is really stupid. My experience has been with scripting languages, not systems programming. But I read the chapter in the Rust Book about Ownership, and I think I get it. In a sense, is not the compiler simply inserting function calls to free() in the right places (and warning you if it can't)? Couldn't this be added to the C compiler? In fact I'm not sure what the difference is from a linter. The article has the phrase "C/C++ Can’t Be Fixed", so it anticipates my question. But its answer is that programmers either won't remember or won't bother to set their C to "strict mode", run the linter, or whatever, because "static analysis comes with too much overhead: It needs to be wired into the build system. . . . If it’s not on by default it won’t it won't help." But if this is the only argument, it seems weak. I agree that it is more effort, but isn't it much more effort to switch out your entire language and ecosystem?

rubber_duck 6y ago
"strict mode" is not a subset - you need stronger type information than what C provides to get Rust level checking - if you wanted to add that to C and also make it expressive enough to be usable you'd eventually end up with something that's closer to Rust than C.
nicoburns 6y ago
The issue is that C/C++ Can’t Be Fixed backwards compatibly. You would need to add lifetime annotations: existing code wouldn't compile. You could make a Rust-style language that is closer to C, but it wouldn't be any to use than Rust. And at that point why not just use Rust. It doesn't require you to switch out the entire ecosystem, you can happily link Rust and C, and C++ together in one binary. In fact, as an end-user it's sometimes easier to use a popular C library from Rust because someone will have wired it into Cargo (Rust's build system) and it will "just work": you don't have to mess around with working out what kind of build system the library is using and integrate it with whatever your using.
- jfkebwjsbx 6y ago

hansdieter1337 6y ago

My first thought: oh no. M$ likes Rust and will probably contribute and demolish it. Just look at the Github system status history since M$ took over. Or Azure, Windows 10, ...

fortran77 6y ago

I'm disappointed they didn't double-down on what I feel is the best general purpose programming language C# (and related F#). It has a great toolset, generates good code, and with a good microkernel architecture (which Windows 10 is, mostly) 90% of "systems" programming would be fine in a garbage-collected language.

exdsq 6y ago

I heard the Rust API changes between versions such that it’s a bit of a pain upgrading systems. Is this true? Also, I’ve read traits can be used as invariants for a pseudo-dependent type system. Has anyone had experience with this? I’m considering learning it instead of C++ for some systems work.

jfkebwjsbx 6y ago
If your systems work do not require stable compilers or rely too much on external C++ APIs, then you will be mostly fine.
- exdsq 6y ago
  It’s mostly to trace process performance, network load, stuff like that.
jasondclinton 6y ago
> I heard the Rust API changes between versions such that it’s a bit of a pain upgrading systems. Is this true? No, this isn't true. https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html#what-is-rust-2018 https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html... was the last change and it was optional and automated migration.
dagmx 6y ago
For your first point, you might be thinking of ABI and not API? Rust doesn’t have a stable ABI but the API is non breaking as long as you aren’t on nightly AND opting into unstable features. If you stay on stable Rust, you’ll not really have breaking changes between versions. Regarding ABI , that means that if you compile rust into a library with one version, you can’t reuse that compiled library in a newer version of the compiler, unless you go through a stable ABI like exposing a C interface. However if you recompile your code, it’ll work. You need to keep them compiled by the same compiler version.

vinay_ys 6y ago

I think 'best chance' at safe programming is the advances in chip design. I expect PMMU to become more sophisticated and solve more of the memory safety problems in hardware than in software. Then, the programming model will evolve and safety features will become more language agnostic and broadly available. Then, I fully expect compiler+runtime+os to evolve to take advantage of these hardware features for software written in any language.

stephc_int13 6y ago

This is magical thinking, switching language won't solve the problem. Complexity is the problem, hard-to-read code is the problem, over-engineering is the problem.

asperous 6y ago
I think its systems thinking. With 40,000 developers, Microsoft is too large to fix the problems you mentioned. They need a broad stroke change to reduce vulnerabilities. The article says they've tried many things and believe moving to rust might work.
- stephc_int13 6y ago
  Yeah, MS clearly has serious maintenance issues with their codebase, for obvious reasons. They tried many things in the past, including C# and .NET, I'm not sure if that really helped or made things worse.
muldvarp 6y ago
> This is magical thinking, switching language won't solve the problem. It won't solve the problem, but it can be an important step towards a solution. > Complexity is the problem, hard-to-read code is the problem, over-engineering is the problem. I actually disagree. Many memory safety issues are not the result of hard-to-read or over-engineered code, but are instead due to careless memory management. Safe Rust code (no matter how hard-to-read or over-engineered) can guarantee memory safety.
- stephc_int13 6y ago
  If it was that easy to fix, this problem would have been fixed a long time ago, by many other "safe" languages. My bet is that Rust won't help nearly as much as people tend to think.
  - muldvarp 6y ago
    > If it was that easy to fix, this problem would have been fixed a long time ago, by many other "safe" languages. There are many other memory safe languages. Those usually have a GC though. > My bet is that Rust won't help nearly as much as people tend to think. Why not? Memory safety issues are common and safe Rust code eliminates them.

userbinator 6y ago

Best chance at creating an even more dystopian future where authoritarian governments and corporations control exactly what "your" computing devices can do and you can't "jailbreak" out of? Yes, I know Rust is not a panacea, but I feel like the whole paranoia around safety/security is just leading us towards that sort of society, technology included. It seems that there was somewhat of a balance before, which allowed for some sort of "civil disobedience" (jailbreaking, rooting, cracking, etc.), and now that freedom is slowly disappearing.

signal11 6y ago
This is the strangest critique of writing more secure code I've seen. Yes, more secure code does reduce the chance of jailbreaks, but insecure code is overwhelmingly used more by criminals and state actors to try and break into your computer. Secure Code helps all computer users, the 'little guy' most of all. And you can always vote with your wallet (or, you know, vote) to keep your digital liberties. Blaming a better tool for eroding your liberties seems ... strange.
- missosoup 6y ago
  State actors and high tier criminal orgs will always have a way into your digital life. In a way, making code more secure is just creating an asymmetry where regular joe can't break into a device but only state actors and other major players can. I can sort of understand GP's sentiment. If someone really wants to hack me, they will. Or they'll find some other vector. The prevalence of memory safe code doesn't really impact my own security as an individual. But it does impact my ability to jailbreak and own my devices. There was a similar discussion around the intel Trusted Computing concept. It was not a platform that ultimately benefited the user, it was a platform for user-hostile forces to 'trust' that the user isn't interfering with the code they want to execute on the user's device. Slowly but surely we're moving towards a world where user devices are merely thin clients over corporate and government owned systems, and don't really belong to the user at all.
- asdff 6y ago
  A good hacker can always break in. In fact the most common and most effective hacking doesn't involve technology at all: social engineering. All this sort of walled garden thinking does is make it just a little bit more challenging for people to learn more about the tools they've purchased and own outright, and how to best make use of them for their own needs. Today, when macOS gives me warnings and asks permission for inane things, like terminal needing permission to look into ~/Downloads or ~/Documents, I and everyone else with some experience in technology just rolls their eyes at this request and move on. This would be like if my new toothbrush asked me 'are you sure you want to brush your teeth in this bathroom?' However, to someone not familiar with technology and Apple's security logic of recent years, these requests might seem terrifying, and scare off what could be bright minds who could have contributed to the field of computer science had they not been questioned at every turn by their operating system of their intentions. You learn by breaking things, after all.

lambingan 6y ago

Here you Can Download the Latest Apps and Games https://kingmodapk.com/ https://kingmodapk.com/ For Android and Ios User

jfkebwjsbx 6y ago

When is Microsoft going to release first-class Rust support in Visual Studio and Windows, including debugger and official Rust bindings for their most commonly used APIs like Win32, Direct3D, etc.?

s_y_n_t_a_x 6y ago
I don't think this is exactly what you want, but you might be interested in it: https://github.com/microsoft/winrt-rs https://github.com/microsoft/winrt-rs
- jfkebwjsbx 6y ago
  Not really, but thanks! Hopefully they will start adding more bindings...
adamnemecek 6y ago
VS Code is the best Rust editor.
- jfkebwjsbx 6y ago
  Yes, but an editor is just one of the pieces.

tyrion 6y ago

The fact that Microsoft keeps saying it wants to move away from C/C++ is great IMHO. > Microsoft c++ continues to be written and will continue to be written for a while I interpret this as saying that they cannot instantaneously convert all their existing code to Rust, and it seems fair enough. However, it seems a little odd to start new projects in C/C++ when you are publicly saying it's the wrong thing to do. Infact, just a little over a month ago they announced a new QUIC implementation written in C/C++ (MsQuic) Is this to be expected since Microsoft is such a big company? Or maybe that lib is not important and is not going to be used in, say, Edge? Moreover, isn't networking code the worst kind of code to write in C/C++ (I am thinking of heartbleed for example)? I would really love some explanation.

adolfojp 6y ago
The more I learn about Microsoft the more this joke makes sense: https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org_charts%22_comic_by_Manu_Cornet.png https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org...
pjmlp 6y ago
Which is why they are the main drivers for C++ Core Guidelines, and have contributed the initial effort of a C++ lifetime analyses to clang, while making it available in all Visual Studio editions, including Community. They are quite clear that a constraint version of C++ still gets to play in a secure world. And while Azure Sphere still gets to be written in C (due to Linux kernel), it has a security layer (Pollonium) that takes care of bad code. Finally, since they failed to move people into UWP programming model, sandboxing has been coming into Win32 as well, to the point that on Windows 10X, everything is sandboxed, including Win32 apps.

fuddle 6y ago

I'm a big fan of Rust, they only issue I have is that the compile time is painfully slow. Hopefully it can be improved in the future.

pizlonator 6y ago

PL is still a fast moving field, so claims that any language is a “best chance” for something are likely to have a short shelf life.

kbenson 6y ago

A lot of tooling is built around C/C++. In particular, Microsoft binaries are now almost completely built on the Microsoft Visual C++ compiler which produces MSVC binaries, whereas Rust relies on LLVM. Maybe providing/funding a different back-end would be a worthwhile endeavor for Microsoft to do or fund.

winrid 6y ago

Great. Now rewrite all the slow C# apps in Windows. :)

libman 6y ago

Nim and D are better.

pull_my_finger 6y ago

If they want to use Rust, and have more faith in it than their own Verona[1], then they should discontinue Verona dev and let those developers go back to Pony[2]. I imagine having their core team working on Verona full-time is considerably delaying Pony development. [1] - https://github.com/microsoft/verona https://github.com/microsoft/verona [2] - https://github.com/ponylang/ponyc https://github.com/ponylang/ponyc (edit: formatting)

lloydatkinson 6y ago

It's a shame its such an ugly language then