Live data from Hacker News

Why I think Rust is the "language of the future" for systems programming

winningraceconditions.blogspot.com

1–10 of 193 posts

Re: Why I think Rust is the "language of the future" for systems programming

#3

Good 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?

Probably this would help :) http://viewtext.org/article?url=http%3A%2F%2Fwinningracecond...

Re: Why I think Rust is the "language of the future" for systems programming

#4

Good 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?

I just found this Firefox add-on today and I'm completely in love:

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

#6
Out 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" 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

#7
post #6

Out 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?

Re: Why I think Rust is the "language of the future" for systems programming

#8
post #6

Out 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"…

The two languages aren't really in the same space in the first place. Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all.

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

#9
Rust is what I had hoped Go would be.

Google 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

#10
post #7
post #6

Out 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?

I'm sure that Go has higher-order functions, I just mean that Rust encourages you to use higher-order functions all the time. For example: in Rust, `for` loops desugar to higher-order functions (it's very neat, actually). Furthermore, whereas in Go you spawn a goroutine with the `go` keyword, spawning a task in Rust is done by handing a function (usually a Ruby-esque closure) to the `task::spawn` library function. (Note also that "higher-order functions" are not the same as "first-class functions".)

Go does not have pattern matching, to my knowledge, though without algebraic datatypes I don't think it's really a big deal.

Post reply on HN