Why I think Rust is the "language of the future" for systems programming
winningraceconditions.blogspot.com
Why I think Rust is the "language of the future" for systems programming
1–10 of 193 posts
Re: Why I think Rust is the "language of the future" for systems programming
#2Sorry to be nitpicky but the font size/line-height makes it really hard to read. Perhaps make both a bit bigger for optimal reading?
Re: Why I think Rust is the "language of the future" for systems programming
#3Good article! Sorry to be nitpicky but the font size/line-height makes it really hard to read. Perhaps make both a bit bigger for optimal reading?
Re: Why I think Rust is the "language of the future" for systems programming
#4Good article! Sorry to be nitpicky but the font size/line-height makes it really hard to read. Perhaps make both a bit bigger for optimal reading?
https://addons.mozilla.org/en-US/firefox/addon/clearly/
Here's what appears to be the Chrome version:
https://chrome.google.com/webstore/detail/iooicodkiihhpojmme...
Makes it ridiculously easier to read basically everything on the web.
Re: Why I think Rust is the "language of the future" for systems programming
#5Re: Why I think Rust is the "language of the future" for systems programming
#6Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated" nature (very much like Python). Rust will appeal more to people who prefer "functional" trimmings (algebraic datatypes, pattern matching, liberal use of higher-order functions, Scheme-style macros) as well as folks fed up with C++ who aren't willing to give up complete control over memory and performance characteristics. The fact that both languages are built around a similar concurrency model is just convergent evolution.
It's tempting to cast Go vs. Rust as Google vs. Mozilla and/or Chrome vs. Firefox, but there's no practical reason that both languages cannot peacefully coexist and thrive.
Re: Why I think Rust is the "language of the future" for systems programming
#7Out of mild concern over the title (not that it ought to be changed, TFA doesn't really have a meaningful title), I'd like to preemptively defuse any potential flame war. Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated"…
Re: Why I think Rust is the "language of the future" for systems programming
#8Out of mild concern over the title (not that it ought to be changed, TFA doesn't really have a meaningful title), I'd like to preemptively defuse any potential flame war. Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated"…
Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost and control over the machine is crucial.
Re: Why I think Rust is the "language of the future" for systems programming
#9Google employs some of the brightest computer science minds in the world and turns out stuff like Go and Dart, which seem to be more aimed at enterprise Java programmers rather than computer scientists or programming enthusiasts.
Re: Why I think Rust is the "language of the future" for systems programming
#10Out of mild concern over the title (not that it ought to be changed, TFA doesn't really have a meaningful title), I'd like to preemptively defuse any potential flame war. Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated"…
Does Go not have higher order functions and pattern matching? If not, are they on the roadmap?
Go does not have pattern matching, to my knowledge, though without algebraic datatypes I don't think it's really a big deal.