While it did get a huge amount of hype at various programming discussion forums in the recent past, a lot of this has died off, perhaps because of people becoming disillusioned with it.
I don't know what forums you're on but the Rust hype is fucking nuts on HN and reddit. I like Rust quite a lot as a language but I hear about it so much that I'm almost getting sick of it, like Node.js was dominating the hype cycle years ago and Ruby before that.
Also, while Swift has a very reasonable code of conduct, what are your thoughts about Rust's community, including its rather extreme focus on its code of conduct?
Lolwut? Swift's code of conduct is lifted almost directly from Rust's, they were both based off the same original document and written by the same person. I've also never seen any "extreme"ness or SJWness in all my time on the Rust forums.
As a frequent user of several LLVM-based projects I was curious if you could contrast where it stands today with your current vision of it when you first began, and also was curious whether your departure will impact LLVM's development.
An alpha release should be fully usable, with no known issues
Lol, when the hell has this ever been an accepted definition? Even released, "stable" software can't meet such a pristine standard of quality, let alone beta, let alone-let alone alpha, let alone-let-alone-let alone the pre-alpha that you've been judging it by.
And then a beta release is supposed to be... what? Alpha release are _always_ crashy piles of trash, methinks you've got your standards set too high my good friend.
Servo isn't, never has been, and has never been intended to be an end-user web browser. Mozilla keeps waffling on whether they want to _make_ it one (probably because they don't want to scare off all their existing contributors on the Gecko side) but their stated priorities have always been 1. do research into parallel execution of web content whose strategies can be uplifted into existing browsers and 2. actually be embeddable, because Gecko is utter shite at the embedded-browser-engine use case.
Rust already has a whole lot of ARM support, not all of it official. Lots of tentative embedded work being done with Rust at the moment. Here's a more updated version of the page you linked with much more detailed support information: https://github.com/alexcrichto...
Rust has pointers. Rust has pointers all over the place. What sets Rust apart is that the compiler checks code for improper pointer usage and disallows it unless you explicitly tell it to chill out using the "unsafe" keyword. It trivializes code auditing by making it so you just need to grep for the word "unsafe" to know where the source of any segfault (or any other memory error) must lie. So no, it's not a silver bullet (nothing is), but it's a hell of a lot easier to write low-level memory-safe code in Rust than it is in C.
Every language under the sun has a foreign function interface for the purpose of calling into C libraries. Does the existence of an FFI from Python obviate the need for Python? Does JNI obviate the need for Java?
yet another language attempting to fix bad coders, which is something a language cannot do
Phew, glad to hear it! I'll inform the telcos that they can rewrite their infra from Erlang to PHP, since you've handily disproven the notion of safety benefits that are intrinsic to a language.
When you write C, do you enable warnings such as -Wall, -Wextra, -Weverything, -Wetc? This is an example of a tool that helps to enforce strict practices that lead to more robust products. And if you think warnings are a waste of your time, then please let me know which projects you work on so that I can remove such recklessly cowboy-coded products from my machines. Experience is no excuse for believing oneself infallible.
Ah, I see, you're rejecting this language out-of-hand because you've read a mathematical proof that programming languages must necessarily be fraught with undefined behavior like C is, and that null-based error handling like C has is the absolute and unassailable pinnacle of robust software architecture.
If I may, could I ask you to link me to a text of said proof? I don't have an ACM membership, but since it's been known for "a long, long time" I would hope that it's passed into the public domain by now.
It's part of Rust's general policy of favoring explicitness, which is understandably controversial. Macros are very free-form and upon seeing a new one for the first time there's very little the programmer can assume about what they do (which, at the limit, can include running arbitrary code at compile time). In contrast, a function call is relatively easy to reason about.
It's not 100% necessary by any means, though losing the syntactic distinction distinction might make many macros virtually unparseable for all I know (macros are so free-form that the current parsing tactic is "if I see the exclamation point, consume paired delimeters until they balance out, at which point I know that I'm out of the macro and can continue parsing as normal).
Well, guess what, if that were possible, we would have the right tools by now.
Judging from this attitude, I'm starting to think that the fact that we don't have the right tools is because every time someone tries to design and implement the right tools they get shut down by chicken-or-the-egg fallacies like this one.
Alternatively, given the topic of this thread, you can take the Rust way, which gives you the benefits of manual memory management with the non-crashiness of GC, without imposing the refcount-bumping overhead of ARC (which isn't a lot, but it's non-zero).
Not to knock Swift, which I actually think is maybe the best application programming language emerging today. If only it were open-source and cross-platform...
Your final point about Servo and Oilpan is off. Servo has garbage collection in the same way that Chrome is growing garbage collection via Oilpan: for keeping track of objects in the DOM (in fact, Servo uses the SpiderMonkey GC for this, it's actually pretty neat. See https://blog.mozilla.org/resea... for details). Mozilla isn't afraid of garbage collection, they just happen to think that if you can get by without it then hey, why not?
A good memory allocator makes memory fragmentation a non-issue. Your system's default memory allocator probably fails at this, but by default Rust uses a custom fork of jemalloc, which is an allocator specifically designed for fragmentation avoidance and scalability in concurrent environments.
Does Ada do compile-time lifetime checking? The hype about Rust is only because it can prove that programs are memory-safe at compile time without any kind of runtime overhead, which as far as I know is only possible in Ada if you either use garbage collection or if you forbid dynamic memory allocation entirely.
Also, is it possible for Ada to expose a C interface such that I can write a reusable library in Ada and call it from Python, Java, C++, etc without requiring me to start an Ada runtime? This is another thing that's exciting about Rust.
The argument may be that Rust, like a lot of other types of tools, libraries, frameworks etc, tend to make easy things easier, but harder things harder.
When I think about hard problems, I think about things that are hard to do in C++ like storing internal references to the stack or reasoning about who's going to deallocate some bit of memory or about coordinating memory between threads. C++11/14 helps, but the hole that it's trying to dig the language out of is massively deep. Meanwhile, Rust makes these hard problems easy. We don't have enough experience with Rust yet to know what important things it truly makes hard, but memory safety is a big deal to me so I'm willing to take the chance on the unknown.
Is the "obviously wrong" assertion that C is an utter shitshow when it comes to producing software that's resistant to exploitable memory safety vulnerabilities? Not only is that not obviously wrong, I'm going to have to ask for a citation if you think anyone in the world seems to believe otherwise.
First of all, claiming that HN is some bastion of civility is lolworthy. Second of all, if you read those discussions it's actually amusingly opposite: one of the Rust developers basically does nothing but roam around and hem and haw and equivocate about how the language isn't going to solve all your problems and you shouldn't bust a nut over it. The people who get downmodded are actually just dumbasses (no shortage of those on HN, in fact it's a booming market).
Slashdot Mirror
While it did get a huge amount of hype at various programming discussion forums in the recent past, a lot of this has died off, perhaps because of people becoming disillusioned with it.
I don't know what forums you're on but the Rust hype is fucking nuts on HN and reddit. I like Rust quite a lot as a language but I hear about it so much that I'm almost getting sick of it, like Node.js was dominating the hype cycle years ago and Ruby before that.
Also, while Swift has a very reasonable code of conduct, what are your thoughts about Rust's community, including its rather extreme focus on its code of conduct?
Lolwut? Swift's code of conduct is lifted almost directly from Rust's, they were both based off the same original document and written by the same person. I've also never seen any "extreme"ness or SJWness in all my time on the Rust forums.
As a frequent user of several LLVM-based projects I was curious if you could contrast where it stands today with your current vision of it when you first began, and also was curious whether your departure will impact LLVM's development.
An alpha release should be fully usable, with no known issues
Lol, when the hell has this ever been an accepted definition? Even released, "stable" software can't meet such a pristine standard of quality, let alone beta, let alone-let alone alpha, let alone-let-alone-let alone the pre-alpha that you've been judging it by.
An alpha release is supposed to be usable.
And then a beta release is supposed to be... what? Alpha release are _always_ crashy piles of trash, methinks you've got your standards set too high my good friend.
Servo isn't, never has been, and has never been intended to be an end-user web browser. Mozilla keeps waffling on whether they want to _make_ it one (probably because they don't want to scare off all their existing contributors on the Gecko side) but their stated priorities have always been 1. do research into parallel execution of web content whose strategies can be uplifted into existing browsers and 2. actually be embeddable, because Gecko is utter shite at the embedded-browser-engine use case.
Chrome, Edge, Shitty Old Chrome, Chrome, and Chrome will continue to evolve.
FTFY
Rust already has a whole lot of ARM support, not all of it official. Lots of tentative embedded work being done with Rust at the moment. Here's a more updated version of the page you linked with much more detailed support information: https://github.com/alexcrichto...
Rust is dual-licensed under Apache 2/MIT, not MPL.
walking a file directory seems to be unsupported
Here's a lovely lib for that that has a good chance of appearing in the standard lib someday: https://crates.io/crates/walkd...
Rust has pointers. Rust has pointers all over the place. What sets Rust apart is that the compiler checks code for improper pointer usage and disallows it unless you explicitly tell it to chill out using the "unsafe" keyword. It trivializes code auditing by making it so you just need to grep for the word "unsafe" to know where the source of any segfault (or any other memory error) must lie. So no, it's not a silver bullet (nothing is), but it's a hell of a lot easier to write low-level memory-safe code in Rust than it is in C.
Every language under the sun has a foreign function interface for the purpose of calling into C libraries. Does the existence of an FFI from Python obviate the need for Python? Does JNI obviate the need for Java?
yet another language attempting to fix bad coders, which is something a language cannot do
Phew, glad to hear it! I'll inform the telcos that they can rewrite their infra from Erlang to PHP, since you've handily disproven the notion of safety benefits that are intrinsic to a language.
When you write C, do you enable warnings such as -Wall, -Wextra, -Weverything, -Wetc? This is an example of a tool that helps to enforce strict practices that lead to more robust products. And if you think warnings are a waste of your time, then please let me know which projects you work on so that I can remove such recklessly cowboy-coded products from my machines. Experience is no excuse for believing oneself infallible.
Ah, I see, you're rejecting this language out-of-hand because you've read a mathematical proof that programming languages must necessarily be fraught with undefined behavior like C is, and that null-based error handling like C has is the absolute and unassailable pinnacle of robust software architecture. If I may, could I ask you to link me to a text of said proof? I don't have an ACM membership, but since it's been known for "a long, long time" I would hope that it's passed into the public domain by now.
It's part of Rust's general policy of favoring explicitness, which is understandably controversial. Macros are very free-form and upon seeing a new one for the first time there's very little the programmer can assume about what they do (which, at the limit, can include running arbitrary code at compile time). In contrast, a function call is relatively easy to reason about. It's not 100% necessary by any means, though losing the syntactic distinction distinction might make many macros virtually unparseable for all I know (macros are so free-form that the current parsing tactic is "if I see the exclamation point, consume paired delimeters until they balance out, at which point I know that I'm out of the macro and can continue parsing as normal).
Actually, it will. I appeal to our shared subject line: "Have you actually tried using Rust?"
Well, guess what, if that were possible, we would have the right tools by now.
Judging from this attitude, I'm starting to think that the fact that we don't have the right tools is because every time someone tries to design and implement the right tools they get shut down by chicken-or-the-egg fallacies like this one.
Alternatively, given the topic of this thread, you can take the Rust way, which gives you the benefits of manual memory management with the non-crashiness of GC, without imposing the refcount-bumping overhead of ARC (which isn't a lot, but it's non-zero). Not to knock Swift, which I actually think is maybe the best application programming language emerging today. If only it were open-source and cross-platform...
Your final point about Servo and Oilpan is off. Servo has garbage collection in the same way that Chrome is growing garbage collection via Oilpan: for keeping track of objects in the DOM (in fact, Servo uses the SpiderMonkey GC for this, it's actually pretty neat. See https://blog.mozilla.org/resea... for details). Mozilla isn't afraid of garbage collection, they just happen to think that if you can get by without it then hey, why not?
A good memory allocator makes memory fragmentation a non-issue. Your system's default memory allocator probably fails at this, but by default Rust uses a custom fork of jemalloc, which is an allocator specifically designed for fragmentation avoidance and scalability in concurrent environments.
Does Ada do compile-time lifetime checking? The hype about Rust is only because it can prove that programs are memory-safe at compile time without any kind of runtime overhead, which as far as I know is only possible in Ada if you either use garbage collection or if you forbid dynamic memory allocation entirely. Also, is it possible for Ada to expose a C interface such that I can write a reusable library in Ada and call it from Python, Java, C++, etc without requiring me to start an Ada runtime? This is another thing that's exciting about Rust.
The argument may be that Rust, like a lot of other types of tools, libraries, frameworks etc, tend to make easy things easier, but harder things harder.
When I think about hard problems, I think about things that are hard to do in C++ like storing internal references to the stack or reasoning about who's going to deallocate some bit of memory or about coordinating memory between threads. C++11/14 helps, but the hole that it's trying to dig the language out of is massively deep. Meanwhile, Rust makes these hard problems easy. We don't have enough experience with Rust yet to know what important things it truly makes hard, but memory safety is a big deal to me so I'm willing to take the chance on the unknown.
Is the "obviously wrong" assertion that C is an utter shitshow when it comes to producing software that's resistant to exploitable memory safety vulnerabilities? Not only is that not obviously wrong, I'm going to have to ask for a citation if you think anyone in the world seems to believe otherwise.
Security is not a property created by tools. It is a property created by understanding and experience.
This is a false dichotomy. Security is created by understanding and experience, and *enforced* by tools.
First of all, claiming that HN is some bastion of civility is lolworthy. Second of all, if you read those discussions it's actually amusingly opposite: one of the Rust developers basically does nothing but roam around and hem and haw and equivocate about how the language isn't going to solve all your problems and you shouldn't bust a nut over it. The people who get downmodded are actually just dumbasses (no shortage of those on HN, in fact it's a booming market).