91–100 of 184 posts
Isn’t a million dollar yearly budget really low considering how rich those companies are? That’s like 4 full time engineers. Not even a 5 a side football team.
Wait until you hear about how much funding the Python Software Foundation has in yearly donations... Quite a bit less than that.
Isn’t a million dollar yearly budget really low considering how rich those companies are? That’s like 4 full time engineers. Not even a 5 a side football team.
Earlier quoted context omitted.
It's entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code. (If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)
It's not entirely a myth. There are situations where you can't get the compiler to emit optimal code using only safe Rust. You can go a very long way with only safe Rust (and i do!), but not everywhere.
Earlier quoted context omitted.
Mozilla already tried re-writing the CSS engine in C++ before. They failed. C++ simply wasn't usable for writing a parallel CSS engine. "This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!"…
> C++ simply wasn't usable for writing a parallel CSS engine. I think it can be said that Mozilla was able to use Rust to achieve what they failed to with achieve with C++. It's not justified to claim that C++ is/was not suitable for this purpose. C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust. Maybe Rust has certain advantages which made t…
You could say the same thing about assembly programming or some language that uses GOTOs instead of structured control constructs ... or Brainfuck. Given infinite time and resources, you can implement anything in any language.
Claims about this or that language being unsuitable for a problem aren't really about stuff like Turing completeness, it's more about practical software engineering problems (e.g. does the language provide the right kind of support to the developers allow them to implement the required functionality in a reasonable amount of time with a reasonably small amount of bugs with the budget available).
Earlier quoted context omitted.
A brief reminder that Mozilla paid its top executive, Mitchell Baker, $2.4m in 2018. http://calpaterson.com/mozilla.html
She actually makes over $3 million now. https://www.zdnet.com/article/endangered-firefox-the-state-o...
> You may recall that we expected to be earning revenue in 2019 and 2020 from new subscription products as well as higher revenue from sources outside of search. This did not happen. Our 2019 plan underestimated how long it would take to build and ship new, revenue-generating products. Given that, and all we learned in 2019 about the pace of innovation, we decided to take a more conservative approach to projecting our revenue for 2020. We also agreed to a principle of living within our means, of not spending more than we earn for the foreseeable future.
[NOTE: per the link in the parent comment, "Mozilla's 2019 expenses came to $495.3 million, or almost $5 million more than revenue."]
> This approach is prudent certainly, but challenging practically. In our case, it required difficult decisions with painful results. Regular annual pay increases, bonuses and other costs which increase from year-to-year as well as a continuing need to maintain a separate, substantial innovation fund, meant that we had to look for considerable savings across Mozilla as part of our 2020 planning and budgeting process. This process ultimately led us to the decision to reduce our workforce.
https://techcrunch.com/2020/01/15/mozilla-lays-off-70-as-it-...
> Mozilla used Rust to build Stylo, the CSS engine in Firefox (replacing approximately 160,000 lines of C++ with 85,000 lines of Rust). I would have loved to see two competing teams rewrite it, one in C++ and the other in Rust. Saying that the rewrite is better does nothing to say WHY it's better. Refactored code is almost always radically better, even when it's in the same language, for reasons that might be insulti…
Mozilla already tried re-writing the CSS engine in C++ before. They failed. C++ simply wasn't usable for writing a parallel CSS engine. "This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!"…
Blaming the tool for own failure to do the job isn't all that persuasive.
> C++ simply wasn't usable for writing a parallel CSS engine.
It might be not so much the proof of C++ deficiency as simply another manifestation of mismanagement of the browser development by Mozilla Foundation.
> But Rust’s fearless concurrency has made parallelism practical!"
Because nobody ever wrote concurrent systems in C++?
Earlier quoted context omitted.
Mozilla already tried re-writing the CSS engine in C++ before. They failed. C++ simply wasn't usable for writing a parallel CSS engine. "This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!"…
> C++ simply wasn't usable for writing a parallel CSS engine. I think it can be said that Mozilla was able to use Rust to achieve what they failed to with achieve with C++. It's not justified to claim that C++ is/was not suitable for this purpose. C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust. Maybe Rust has certain advantages which made t…
By this measure, anything that is higher level than manually flipping bits in a binary is an inferior language.
Earlier quoted context omitted.
Mozilla already tried re-writing the CSS engine in C++ before. They failed. C++ simply wasn't usable for writing a parallel CSS engine. "This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical!"…
This blog from Mozilla [1] explains why rendering CSS is such a complex process. [1] https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...
Isn’t a million dollar yearly budget really low considering how rich those companies are? That’s like 4 full time engineers. Not even a 5 a side football team.
I guess that depends on where the engineers are, and how much they are paid - I've never known anyone (in coding) to be paid > £100k (~$140k) - but then maybe I move in the wrong circles! So you could certainly get more than 4 engineers on board, plus some project managers etc
To put this in a slightly larger context, here are three articles that look at the history of open source foundations and compare them: https://opensource.com/business/16/2/bright-lines https://towardsdatascience.com/the-unsung-heroes-of-modern-s... https://livablesoftware.com/study-open-source-foundations/
Something feels strange about the founding members of the Rust foundation. It looks like Rust is going to have a similar structure like the C++ committees or even the Linux Foundation (which Servo is now part of) given how big tech companies seems to have a wide presence in these technologies and these foundations which is fine for usage, but very worrying in terms of having seats at the board with the potential risk for them to drive that technology in their interests and we have no say about this.
I feel these announcements have glossed over this important aspect.