5 ms·

> Five years in, I think my journey has been successful so far. I’m proud of how far Rust has come. That said, there’s a lot more work to do. I’m still committe

by madez 9y ago

> Five years in, I think my journey has been successful so far. I’m proud of how far Rust has come. That said, there’s a lot more work to do. I’m still committed as ever to getting that work done, (...) It's good to hear that people behind Rust intent to continue working on Rust. One thing I'm missing, however, is what exactly is considered important to be solved. There are many things how Rust could be made more viable or attractive for a variety of scenarios. For example, I don't consider it important to be able to compile Rust to JavaScript, because I don't think JavaScript is a good thing. On the other hand, downstream packaging of Rust and libraries is important. There are scenarios where rustup and cargo are not acceptable. Is this on the radar? Another issue is target/host support and independent implementations. Rusts only Tier 1 platforms are of the backdoored x86-family. Is this not considered an issue to be solved to make the world a better place? I don't intent to blame, shame or finger-point anybody, but just point out critical remarks that come to mind.

vvanders 9y ago
Most of that is covered pretty well in "Rust in 2017"[1] which somehow didn't make it to the front page. Splitting out cargo and build systems is something that is explicitly called out and I'm pretty sure there's a bunch of work ongoing to get other Tier 1 targets online. [1] https://news.ycombinator.com/item?id=15980359 https://news.ycombinator.com/item?id=15980359
steveklabnik 9y ago
No blame/shame taken! Everyone has their own opinions as to the work to be done. We now have a yearly roadmap process for each year, and are soon going to be opening that up to community discussion. Feedback from everyone that cares about Rust is extremely important! That's also part of why I didn't elaborate; my thoughts on that are a whole big post unto itself. That said, my personal focus is on documentation, ease of use, and growth, so those are some broad areas in which I'd like to push hard on next year. The funny thing about goals is that they often tie into other goals, for example, I believe that documentation is a huge part of ease of use. Same with how other people's goals might fit into my goals; language design is also a big part of ease of use, for example. What I will say is that I'm currently prototyping a complete re-think of how Rust does documentation; I'm excited to share it but it's not ready yet. To briefly comment on some of the points you've raised: > I don't consider it important to be able to compile Rust to JavaScript We share this opinion, but compiling to WebAssembly is a whole different ballgame. > There are scenarios where rustup and cargo are not acceptable. Is this on the radar? It's hard to say without knowing more details of what exactly you mean; distros are already packaging Rust and libraries, for example. In general though, this is a thing we've put a ton of effort to in the past, and I expect to have even more in the future. > Rusts only Tier 1 platforms are of the the backdoored x86-family A few things; we've been thinking about reconsidering the tier system because it isn't a good representation of support. ARM is basically tier 1 but there's a tiny detail about it that prevents us from fitting it into today's "tier 1" rules. What we need to improve platform support is experts in those platforms to help us. With our current people, we're doing what we can, but we'd love for people to get involved and drive better support for more platforms. This stuff absolutely matters; consider Firefox, for example: they have Tier 1 platforms that aren't Tier 1 for us (ARM), but they do depend on us. That's a problem! > independent implementations There's one significant independent implementation, but in some sense, this is something we can't actually do ourselves, otherwise it wouldn't be independent. :) I personally don't think this is a massive problem for Rust today; eventually it would be nice though. It does factor into how we do some things, as we try to pretend as though we have alternative implementations, even though we really don't today, in preparation for that future.
- madez 9y ago
  Thanks for your elaborate comment. It is interesting to read and insightful. I just have comments for select sections: >> I don't consider it important to be able to compile Rust to JavaScript > We share this opinion, but compiling to WebAssembly is a whole different ballgame. If I understand correctly, WebAssembly is essentially the same as JavaScript, and therefore something I'd like to avoid. I do not want random executable code from websites, that my browser then automatically executes. I don't think sandboxing is a solution, because it's an inherently impossible problem. Externally controlled and unaccaunted executable code is _always_ bad. Instead, let's fix some restricted non-turing complete markup language, like HTML, and stay with that. It's an optimal solution. Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users. >> There are scenarios where rustup and cargo are not acceptable. Is this on the radar? > It's hard to say without knowing more details of what exactly you mean; distros are already packaging Rust and libraries, for example. In general though, this is a thing we've put a ton of effort to in the past, and I expect to have even more in the future. Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt? Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet. Anyhow, clearly this issue is noted and even already worked on. That's more I could ask for. Another thing I forgot to mention is IDE support. I read that Rust is now supposedly supported in Gnome Builder, but I see no option to create a Rust project. This is not the responsibility of the Rust team, and it's just an anecdote, but it affects Rust and it's usage and growth.
  - steveklabnik 9y ago
    You're welcome! And thanks for your posts too. > WebAssembly is essentially the same as JavaScript In some senses, but not others. Regardless of personal feelings though, WebAssembly isn't just happening, it's already happened. And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly; see https://mgattozzi.com/rust-wasm https://mgattozzi.com/rust-wasm for example. (I personally am very interested, but if the community was against it, would accept that. It seems like the majority, at this time, is pretty pro.) > How is Cargo and rustup better than Apt? There's a multitude of ways to tackle this problem, but I'll give you the biggest one: I'm a Windows user these days. Apt is 100% useless to me. This problem is the same even on Linuxes, while I do use Debian, I used to use Arch: Apt would be 100% useless to me. > Apt is perfectly usable without internet. Cargo is perfectly usable without internet. It's a hard requirement of projects like Firefox, and the various distros that are shipping Rust today. Now, we want to make it even easier to use without internet, so there's work to be done, but the fundamentals already exist and are used in production systems today. > Another thing I forgot to mention is IDE support. Yeah, this is super huge, agreed. We've been working on various things, but obviously it depends on what IDE you use, and there's a long tail there. We'll get there!
unknown_apostle 9y ago
What do you mean with backdoored for the x86 family?
- steveklabnik 9y ago
  I believe they're talking about https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine and http://www.amd.com/en-us/innovations/software-technologies/security http://www.amd.com/en-us/innovations/software-technologies/s...
abiox 9y ago
> For example, I don't consider it important to be able to compile Rust to JavaScript, because I don't think JavaScript is a good thing. what do you mean, exactly? people are interested in compilation to javascript principally because js is the language of the browser; if it was just another scripting language (like perl, ruby, lua, etc) there wouldn't have been such a transpiler explosion.
- madez 9y ago
  JavaScript and WebAssembly are used like DRM on steroids. I explained myself here a bit more: https://news.ycombinator.com/item?id=15982323 https://news.ycombinator.com/item?id=15982323 Edit: Those who downvoted, do you disagree, or was there another reason?
  - deleted 9y ago
    [deleted]
  - krapp 9y ago
    I didn't downvote you, but I do disagree. Javascript can be turned off, or modified at will in the browser, and its source is available and viewable. Most Javascript is FOSS licensed, and can be forked, edited and redistributed. Minified libraries usually have plaintext sources accompanying them, meaning they can be studied and validated. WebAssembly, meanwhile is barely being used at all, much less in any way that can be considered 'like DRM on steroids.' I understand a lot of people here don't like Javascript, and dislike WebAssembly even less for being a binary format, yet as languages and their environments go, Javascript makes itself far more amenable to user freedom than others, and WebAssembly still barely even exists.
  - Impossible 9y ago
    This isn't an inherent property of Javascript or the web though, and it happens with other languages. Javascript is better than many languages in that although it is often minified, anyone using a browser can view source and look at js code, which isn't the case for non-open source code in languages that compile to binary executables. Mobile platforms and eapecially game consoles have significantly more DRM backed into the platform than the web, and don't use javascript as a primary language for most applications.
SideburnsOfDoom 9y ago
> For example, I don't consider it important to be able to compile Rust to JavaScript, because I don't think JavaScript is a good thing. Seems to be confusion here between "I'm not interested in using that technology" and "Nobody should use that technology". If you're saying the first, fine. I often feel that way too, it's not that important a statement since you can just not use it and move on. Someone has to do Javascript though: targeting the web browser client is important and here to stay although it is evolving, and wasm is part of that evolution. If you're saying the second then that's not in line with existing reality. The ship has sailed on whether we're going to have apps running in the browser or not.
- StavrosK 9y ago
  > Someone has to do Javascript though: targeting the web browser client is important and here to stay although it is evolving, and wasm is part of that evolution. WebAssembly has nothing to do with Javascript, though. I don't think that's what the GP means.
  - SideburnsOfDoom 9y ago
    > WebAssembly has nothing to do with Javascript They are different VMs in the browser alongside each other, I was wrong about that (1) However, this comment says more about the ways that they are and aren't equivalent (2) Both are for "targeting the web browser client" so they have that in common, and a lot of the logic about their place in the world is therefore the same for both of them. 1) https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/design/issues/219 2) https://news.ycombinator.com/item?id=15982036 https://news.ycombinator.com/item?id=15982036
    - steveklabnik 9y ago
      > They are different VMs in the browser alongside each other My understanding is that this is not true; wasm is more of a particular mode or API of interacting with the existing JS VM rather than having its own. You want to re-use the JIT, etc, for wasm. Note that that issue is from 2015. That said I don't work on these implementations so maybe I'm wrong as well.
nickpsecurity 9y ago
VIA wasn't backdoored that I know about. That, a TRNG, a crypto engine, and virtualization support was why I designed around Artigo's a long time ago for little security boxes. Looking at it now, I see a quad-core with no mention of a management engine: https://www.viatech.com/en/silicon/processors/quadcore-e-series/ https://www.viatech.com/en/silicon/processors/quadcore-e-ser... There was also another article indicating they have a 28nm chip in works with better performance. They're designed by Centaur Technology in Austin, TX. Might not be immune to national security activities in that jurisdiction. They'll also be way slower than desktop-class chips of Intel and AMD. Yet, there are options for x86 past Intel and AMD. Like everything else, the odds of a backdoor from groups like NSA also gets lower the older the design you buy since most were focusing on software and crypto back then. EDIT to add link below. Anyone interested in hardware design, esp FOSS, might find their server farm impressive or daunting depending on how cheap you wanted CPU design to be. ;) http://www.centtech.com/?page_id=2723 http://www.centtech.com/?page_id=2723

by madez 9y ago

vvanders 9y ago

Most of that is covered pretty well in "Rust in 2017"[1] which somehow didn't make it to the front page. Splitting out cargo and build systems is something that is explicitly called out and I'm pretty sure there's a bunch of work ongoing to get other Tier 1 targets online. [1] https://news.ycombinator.com/item?id=15980359 https://news.ycombinator.com/item?id=15980359

steveklabnik 9y ago

No blame/shame taken! Everyone has their own opinions as to the work to be done. We now have a yearly roadmap process for each year, and are soon going to be opening that up to community discussion. Feedback from everyone that cares about Rust is extremely important! That's also part of why I didn't elaborate; my thoughts on that are a whole big post unto itself. That said, my personal focus is on documentation, ease of use, and growth, so those are some broad areas in which I'd like to push hard on next year. The funny thing about goals is that they often tie into other goals, for example, I believe that documentation is a huge part of ease of use. Same with how other people's goals might fit into my goals; language design is also a big part of ease of use, for example. What I will say is that I'm currently prototyping a complete re-think of how Rust does documentation; I'm excited to share it but it's not ready yet. To briefly comment on some of the points you've raised: > I don't consider it important to be able to compile Rust to JavaScript We share this opinion, but compiling to WebAssembly is a whole different ballgame. > There are scenarios where rustup and cargo are not acceptable. Is this on the radar? It's hard to say without knowing more details of what exactly you mean; distros are already packaging Rust and libraries, for example. In general though, this is a thing we've put a ton of effort to in the past, and I expect to have even more in the future. > Rusts only Tier 1 platforms are of the the backdoored x86-family A few things; we've been thinking about reconsidering the tier system because it isn't a good representation of support. ARM is basically tier 1 but there's a tiny detail about it that prevents us from fitting it into today's "tier 1" rules. What we need to improve platform support is experts in those platforms to help us. With our current people, we're doing what we can, but we'd love for people to get involved and drive better support for more platforms. This stuff absolutely matters; consider Firefox, for example: they have Tier 1 platforms that aren't Tier 1 for us (ARM), but they do depend on us. That's a problem! > independent implementations There's one significant independent implementation, but in some sense, this is something we can't actually do ourselves, otherwise it wouldn't be independent. :) I personally don't think this is a massive problem for Rust today; eventually it would be nice though. It does factor into how we do some things, as we try to pretend as though we have alternative implementations, even though we really don't today, in preparation for that future.

madez 9y ago
Thanks for your elaborate comment. It is interesting to read and insightful. I just have comments for select sections: >> I don't consider it important to be able to compile Rust to JavaScript > We share this opinion, but compiling to WebAssembly is a whole different ballgame. If I understand correctly, WebAssembly is essentially the same as JavaScript, and therefore something I'd like to avoid. I do not want random executable code from websites, that my browser then automatically executes. I don't think sandboxing is a solution, because it's an inherently impossible problem. Externally controlled and unaccaunted executable code is _always_ bad. Instead, let's fix some restricted non-turing complete markup language, like HTML, and stay with that. It's an optimal solution. Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users. >> There are scenarios where rustup and cargo are not acceptable. Is this on the radar? > It's hard to say without knowing more details of what exactly you mean; distros are already packaging Rust and libraries, for example. In general though, this is a thing we've put a ton of effort to in the past, and I expect to have even more in the future. Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt? Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet. Anyhow, clearly this issue is noted and even already worked on. That's more I could ask for. Another thing I forgot to mention is IDE support. I read that Rust is now supposedly supported in Gnome Builder, but I see no option to create a Rust project. This is not the responsibility of the Rust team, and it's just an anecdote, but it affects Rust and it's usage and growth.
- steveklabnik 9y ago
  You're welcome! And thanks for your posts too. > WebAssembly is essentially the same as JavaScript In some senses, but not others. Regardless of personal feelings though, WebAssembly isn't just happening, it's already happened. And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly; see https://mgattozzi.com/rust-wasm https://mgattozzi.com/rust-wasm for example. (I personally am very interested, but if the community was against it, would accept that. It seems like the majority, at this time, is pretty pro.) > How is Cargo and rustup better than Apt? There's a multitude of ways to tackle this problem, but I'll give you the biggest one: I'm a Windows user these days. Apt is 100% useless to me. This problem is the same even on Linuxes, while I do use Debian, I used to use Arch: Apt would be 100% useless to me. > Apt is perfectly usable without internet. Cargo is perfectly usable without internet. It's a hard requirement of projects like Firefox, and the various distros that are shipping Rust today. Now, we want to make it even easier to use without internet, so there's work to be done, but the fundamentals already exist and are used in production systems today. > Another thing I forgot to mention is IDE support. Yeah, this is super huge, agreed. We've been working on various things, but obviously it depends on what IDE you use, and there's a long tail there. We'll get there!

unknown_apostle 9y ago

What do you mean with backdoored for the x86 family?

steveklabnik 9y ago
I believe they're talking about https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine and http://www.amd.com/en-us/innovations/software-technologies/security http://www.amd.com/en-us/innovations/software-technologies/s...

abiox 9y ago

> For example, I don't consider it important to be able to compile Rust to JavaScript, because I don't think JavaScript is a good thing. what do you mean, exactly? people are interested in compilation to javascript principally because js is the language of the browser; if it was just another scripting language (like perl, ruby, lua, etc) there wouldn't have been such a transpiler explosion.

madez 9y ago
JavaScript and WebAssembly are used like DRM on steroids. I explained myself here a bit more: https://news.ycombinator.com/item?id=15982323 https://news.ycombinator.com/item?id=15982323 Edit: Those who downvoted, do you disagree, or was there another reason?
- deleted 9y ago
  [deleted]
- krapp 9y ago
  I didn't downvote you, but I do disagree. Javascript can be turned off, or modified at will in the browser, and its source is available and viewable. Most Javascript is FOSS licensed, and can be forked, edited and redistributed. Minified libraries usually have plaintext sources accompanying them, meaning they can be studied and validated. WebAssembly, meanwhile is barely being used at all, much less in any way that can be considered 'like DRM on steroids.' I understand a lot of people here don't like Javascript, and dislike WebAssembly even less for being a binary format, yet as languages and their environments go, Javascript makes itself far more amenable to user freedom than others, and WebAssembly still barely even exists.
- Impossible 9y ago
  This isn't an inherent property of Javascript or the web though, and it happens with other languages. Javascript is better than many languages in that although it is often minified, anyone using a browser can view source and look at js code, which isn't the case for non-open source code in languages that compile to binary executables. Mobile platforms and eapecially game consoles have significantly more DRM backed into the platform than the web, and don't use javascript as a primary language for most applications.

SideburnsOfDoom 9y ago

> For example, I don't consider it important to be able to compile Rust to JavaScript, because I don't think JavaScript is a good thing. Seems to be confusion here between "I'm not interested in using that technology" and "Nobody should use that technology". If you're saying the first, fine. I often feel that way too, it's not that important a statement since you can just not use it and move on. Someone has to do Javascript though: targeting the web browser client is important and here to stay although it is evolving, and wasm is part of that evolution. If you're saying the second then that's not in line with existing reality. The ship has sailed on whether we're going to have apps running in the browser or not.

StavrosK 9y ago
> Someone has to do Javascript though: targeting the web browser client is important and here to stay although it is evolving, and wasm is part of that evolution. WebAssembly has nothing to do with Javascript, though. I don't think that's what the GP means.
- SideburnsOfDoom 9y ago
  > WebAssembly has nothing to do with Javascript They are different VMs in the browser alongside each other, I was wrong about that (1) However, this comment says more about the ways that they are and aren't equivalent (2) Both are for "targeting the web browser client" so they have that in common, and a lot of the logic about their place in the world is therefore the same for both of them. 1) https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/design/issues/219 2) https://news.ycombinator.com/item?id=15982036 https://news.ycombinator.com/item?id=15982036
  - steveklabnik 9y ago
    > They are different VMs in the browser alongside each other My understanding is that this is not true; wasm is more of a particular mode or API of interacting with the existing JS VM rather than having its own. You want to re-use the JIT, etc, for wasm. Note that that issue is from 2015. That said I don't work on these implementations so maybe I'm wrong as well.

nickpsecurity 9y ago

VIA wasn't backdoored that I know about. That, a TRNG, a crypto engine, and virtualization support was why I designed around Artigo's a long time ago for little security boxes. Looking at it now, I see a quad-core with no mention of a management engine: https://www.viatech.com/en/silicon/processors/quadcore-e-series/ https://www.viatech.com/en/silicon/processors/quadcore-e-ser... There was also another article indicating they have a 28nm chip in works with better performance. They're designed by Centaur Technology in Austin, TX. Might not be immune to national security activities in that jurisdiction. They'll also be way slower than desktop-class chips of Intel and AMD. Yet, there are options for x86 past Intel and AMD. Like everything else, the odds of a backdoor from groups like NSA also gets lower the older the design you buy since most were focusing on software and crypto back then. EDIT to add link below. Anyone interested in hardware design, esp FOSS, might find their server farm impressive or daunting depending on how cheap you wanted CPU design to be. ;) http://www.centtech.com/?page_id=2723 http://www.centtech.com/?page_id=2723