6 ms·

I know that HN loves Rust and at the risk of being burned at the stakes, i'd say Rust is overrated. Lets get real, it doesn't have that many users, its not even

I know that HN loves Rust and at the risk of being burned at the stakes, i'd say Rust is overrated. Lets get real, it doesn't have that many users, its not even on top of TIOBE. If you are going to start a career in Rust, good luck finding any jobs. I saw maybe one or 2 in the past, and it requires knowledge of C/C++ anyways. You might say, "its new language give it a break" but I bet Kotlin will overtake it by the end of 2017. There is currently no incentive in learning it other than as a hobby language. And im saying this as someone who dived into Rust, drank the coolaid, not an outsider. Servo is an "experimental" browser engine. While Chromium is cranking out features, servo is yet to reach version 1.0. Thunderbird - was "discontinued" by Mozilla MDN is a mess. The topics are all over the place and its hard to navigate. php.net docs is much more organized. You can criticize Go but it has a more thriving ecosystem than Rust. As much I'd like them to succeed, I dont think Mozilla is doing very good right now. They churn out technologically good products, but business wise, they dont know what they're doing. And without money, they wont be able to fight the big companies like Google, MS, FB.

pjmlp 9y ago
> You can criticize Go but it has a more thriving ecosystem than Rust. I think Go has already become unavoidable for those working in cloud like environments, thanks to Docker and Kubernetes. Anyone working on those areas needs a working knowledge of Go, even he/she dislikes the language.
pcwalton 9y ago
> Servo is an "experimental" browser engine. While Chromium is cranking out features, servo is yet to reach version 1.0. This would be a more convincing point if any of memory safety, parallel styling, parallel layout, retained mode rendering as suggested by the GPU vendors, and so forth were on Chromium's roadmap.
- pjmlp 9y ago
  I agree with you, but in the end it is a Beta vs VHS uphill battle.
- vatotemking 9y ago
  You mentioned these features as selling points but at the current state of things parallel styling/layout are buggy. Servo is buggy. And its not 100% proven better (emphasis on "experimental") than current tech. Chrome may not have these on the roadmap but its stable. The styling and layout algorithms are battle tested. Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.
  - pcwalton 9y ago
    I'd be more than willing to hear your technical thoughts as to why the features I mentioned are not "100% proven better" than the status quo. From my point of view, having measured this stuff over and over again for years, it's undeniable that they result in wins. The remaining bugs are features at the margins and will not affect the overall results. You seem confident, so I'm sure you have specific technical reasons, right? > Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value. Doing nothing is an even bigger risk. I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?
    - bokan 9y ago
      The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web. Disclaimer: I work on Chrome.
      - pcwalton 9y ago
        > Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques. This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo. The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.
_ph_ 9y ago
The killer argument for Rust, especially when writing a web browser, is security. I don't care about the general market share of Rust - personally I prefer Go for the things I usually do, but I am very excited for a web browser written in Rust.
olavgg 9y ago
I strongly disagree with that MDN is a mess, it is one of the best places to find good documentation about web development. Especially for the more advanced topics. For example I had issues with the Math.round() method, and at MDN they have a great example of how to fix it! https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is just one of many examples!
steveklabnik 9y ago
rustjobs.rs There are not a ton but there are more than zero.
ry_ry 9y ago
If it gains any meaningful traction, I'm kinda expecting WebAssembly will make Rust a useful additional language for web devs currently working with stuff like C#, Python or JS. It's definitely put it firmly on my radar as something to pick up recently, and since I don't already know C or C++ it feels like a good starting point.

pjmlp 9y ago

> You can criticize Go but it has a more thriving ecosystem than Rust. I think Go has already become unavoidable for those working in cloud like environments, thanks to Docker and Kubernetes. Anyone working on those areas needs a working knowledge of Go, even he/she dislikes the language.

pcwalton 9y ago

> Servo is an "experimental" browser engine. While Chromium is cranking out features, servo is yet to reach version 1.0. This would be a more convincing point if any of memory safety, parallel styling, parallel layout, retained mode rendering as suggested by the GPU vendors, and so forth were on Chromium's roadmap.

pjmlp 9y ago
I agree with you, but in the end it is a Beta vs VHS uphill battle.
vatotemking 9y ago
You mentioned these features as selling points but at the current state of things parallel styling/layout are buggy. Servo is buggy. And its not 100% proven better (emphasis on "experimental") than current tech. Chrome may not have these on the roadmap but its stable. The styling and layout algorithms are battle tested. Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.
- pcwalton 9y ago
  I'd be more than willing to hear your technical thoughts as to why the features I mentioned are not "100% proven better" than the status quo. From my point of view, having measured this stuff over and over again for years, it's undeniable that they result in wins. The remaining bugs are features at the margins and will not affect the overall results. You seem confident, so I'm sure you have specific technical reasons, right? > Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value. Doing nothing is an even bigger risk. I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?
  - bokan 9y ago
    The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web. Disclaimer: I work on Chrome.
    - pcwalton 9y ago
      > Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques. This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo. The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.

_ph_ 9y ago

The killer argument for Rust, especially when writing a web browser, is security. I don't care about the general market share of Rust - personally I prefer Go for the things I usually do, but I am very excited for a web browser written in Rust.

olavgg 9y ago

I strongly disagree with that MDN is a mess, it is one of the best places to find good documentation about web development. Especially for the more advanced topics. For example I had issues with the Math.round() method, and at MDN they have a great example of how to fix it! https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... This is just one of many examples!

steveklabnik 9y ago

rustjobs.rs There are not a ton but there are more than zero.

ry_ry 9y ago

If it gains any meaningful traction, I'm kinda expecting WebAssembly will make Rust a useful additional language for web devs currently working with stuff like C#, Python or JS. It's definitely put it firmly on my radar as something to pick up recently, and since I don't already know C or C++ it feels like a good starting point.