Why I think Rust is the "language of the future" for systems programming • Hacker News Board

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

#151

Post by papsosouid » Thu, Sep 27, 2012, 2:46 PM UTC

cmccabe wrote: post #95

megaman821 wrote: post #64

Earlier quoted context omitted.

As languages, nothing. In design, their conservative nature.

Go is not a conservative language. A conservative language would be something like D, which is mostly a clone of C++ with a few extra features tossed in. Go is a highly opinionated language with at least three big new ideas: * goroutines for concurrency ("Don't communicate by sharing memory; share memory by communicating") * a new type system which is based on structural subtyping (some people have called this static…

None of those three "big new ideas" are big or new. Go is incredibly conservative, primitive even. It takes a few tiny things like those you mentioned from languages that have had them for decades, but leaves out so much important stuff that the language is barely useful at all.

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

#152

Post by zxcdw » Thu, Sep 27, 2012, 3:51 PM UTC

lmm wrote: post #146

zxcdw wrote: post #85

Earlier quoted context omitted.

...both of which are domain specific languages, or developed as such. I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the…

JLS7 is ~600 pages; the latest draft I could find (because apparently the actual standard isn't available online, a problem in itself) for C++11 was over 1200. I very much doubt a version bump will stem C++'s decline; while it contains plenty of improvements there are no really radical changes. What are the changes that you think will make people who chose C or go over C++03 switch to C++11?

Take a look at Herb Sutter's talk at Microsoft's GoingNative2012 conference: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

I really don't see where someone would pick C over C++ when starting a new project if not either due to 1) lack of (good enough) C++ implementation or 2) lack of confidence in using C++(this is personally a problem for me, as I've been programming in C much more than C++ and still feel unfamiliar with lots of things, the least not being the object oriented paradigm). Of course personal taste may differ, and this is understandable; I'd prefer more compact language but right now the domain I work in has no alternatives.

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

#153

Post by [deleted] » Thu, Sep 27, 2012, 4:06 PM UTC

philhippus wrote: post #134

>Stack-allocated data lets you often avoid dynamic allocation overhead and garbage collection (even closures can sometimes be entirely on the stack). There's an entire website named after the results of over-using the stack. Smart pointers and move semantics in C++11 completely smoke GC and memory management everywhere else. While I'm sure Rust is a nice language and I applaud its innovation,there's already a perfect…

[deleted]

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

#154

Post by pcwalton » Thu, Sep 27, 2012, 4:06 PM UTC

philhippus wrote: post #134

>Stack-allocated data lets you often avoid dynamic allocation overhead and garbage collection (even closures can sometimes be entirely on the stack). There's an entire website named after the results of over-using the stack. Smart pointers and move semantics in C++11 completely smoke GC and memory management everywhere else. While I'm sure Rust is a nice language and I applaud its innovation,there's already a perfect…

Rust enforces that you use its smart pointers safely, eliminating a huge class of errors and exploitable security vulnerabilities. C++ doesn't.

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

#155

Post by batista » Thu, Sep 27, 2012, 4:44 PM UTC

jksmith wrote: post #112

pcwalton wrote: post #8

Earlier quoted context omitted.

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 an…

Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run acros…

>C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years.

That doesn't even make sense. Both C# and Java (and JVM, CLR languages) will be used in new billion generating applications in the next 10 years and more.

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

#156

Post by batista » Thu, Sep 27, 2012, 4:54 PM UTC

zaphar wrote: post #114

tedunangst wrote: post #86

Earlier quoted context omitted.

99% sure that remark is in regard to C++. If it's about java, then it's just not true...

You've obviously never compiled java at google :-)

Java has jars and classes and dynamic calling. You don't compile everything into one big lump, nor you have to recompile millions of lines of code for one change in a file.

If Go wanted to compete on compile speed, then dynamic loading would be a better idea than having a simplistic compiler that compiles fast into one monolithic executable.

The main reason the Go compiler is fast, is because it is simple and doesn't do many passes and optimizations.

Which is like advertising the fact that your company makes a fast car, but forgetting to mention that it can only carry a driver if he weights 10kg.

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

#157

Post by batista » Thu, Sep 27, 2012, 4:56 PM UTC

bzbarsky wrote: post #96

zxcdw wrote: post #49

Earlier quoted context omitted.

I'm assuming you'd rather see them focus on declarative programming, because it seems to be the big thing among enthusiasts and hobbyists . Google works with software projects with planned lifetime of decades. It's far better to rely on imperative programming concepts which are tested and trusted with experience grown from what, 50's or so. Sure, declarative programming is a nice toy , but that's all. I'm yet to see…

Hedge fund trading code may not have "2030 and beyond" lifetime, but it's certainly something major companies are investing a good bit of money into. Also tends to be in OCaml...

Or rather: some hedge fund (of thousands all over the world) uses OCalml (Jane Street, IIRC).

That does not equate to "hedge fund trading code tends to be in Ocaml".

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

#158

Post by batista » Thu, Sep 27, 2012, 5:03 PM UTC

mseepgood wrote: post #135

zxcdw wrote: post #124

Earlier quoted context omitted.

I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff fro…

> No books. Nothing. No books? Go in Action; Evan Shaw; Manning; http://www.manning.com/shaw/ An Introduction to Programming in Go; Caleb Doxsey; http://www.golang-book.com Network Programming with Go; Jan Newmarch; Free e-book; http://jan.newmarch.name/golang/ Programming in Go: Creating Applications for the 21st Century; Mark Summerfield; Addison-Wesley Professional; http://qtrac.eu/gobook.html The Way To Go: A Tho…

Remove the books that are mostly too general introductions for novice programmers (the syntax etc). Remove the poorly edited, self published free ebooks. Remove the german language books.

Now divide by the number of C++ books published in the last decade.

You got something like 0.05?

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

#159

Post by haberman » Thu, Sep 27, 2012, 5:23 PM UTC

kombine wrote: post #147

haberman wrote: post #69

I'm a die-hard C guy. My motto for years has been "you can pry pointers and address spaces from my cold, dead hands." Of the new languages I've seen lately, Rust is my favorite. I love how it gives me better ways to express things I actually want to say without imposing GC on me. But even so, I can't see myself actually using it for much, because writing in a language other than C means buying in to that language's r…

The whole idea of modern systems languages like Rust or D is actually to avoid the need of using Python, Ruby etc. The language covers all your needs in a nice coherent package from top to bottom.

> The language covers all your needs

This is exactly the "one language" myopia that I was arguing against. Anyone who tries to sell me on a language or programming system that asks for complete buy-in and offers no interoperability story is immediately suspect in my book.

(FWIW, I don't think the Rust guys actually sell this line, so I'm arguing against you, not them).

No one will ever invent "the last language you'll ever need." One reason for this is that different languages excel at different things. For example, Rust is not as easy to sandbox as Python, Ruby, etc. It's also not as simple to write quick scripts in.

Another reason is that you'll never convince everyone in the world to use the same language. Even if you convinced them that they should use the same language (which is impossible), there are billions of lines of code in use that is written in different languages. If you can't interoperate with them, you are a rock, you are an island.

There's nothing "modern" about the idea that "we're going to make the last language you'll ever need."

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

#160

Post by grey-area » Thu, Sep 27, 2012, 6:24 PM UTC

zxcdw wrote: post #124

grey-area wrote: post #122

Earlier quoted context omitted.

There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions. Go was insp…

I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff fro…

Thanks for the cogent response, not sure why I was modded down, but never mind. I've been doing a few small experiments in Go just to see what it's like and have loved the compilation time, lack of cruft like header files, and the simplicity. The standard library for Go reminds me of Ruby in many ways as it mostly works exactly as you'd expect with few surprises, and it covers a surprisingly broad range.

I agree that hyperbole on the future of computing is overblown (I wonder if Rust now feels it has to compete with Go for hype!), but there are a lot of things in say Go which are not as nice in C, unicode strings, loops, slices, etc. So it's not entirely pointless to start again with all we have learned since 1969. All of the little niggles in C can be worked around, but overall Go feels like a cleaned up version of C which took a few ideas from C++ and other OOP languages and left the rest out as unnecessary. Given the problems vast hierarchies of classes sometimes cause, and the huge and growing complexity of C++, I can sympathise with that point of view.

To say that there are no tools or libraries is exaggerating slightly, there are tools for Go (see http://golang.org/pkg/), and books, just not as many, which is quite normal for a young language which has just hit 1.0. For Rust there will be far fewer as it is even less developed, but that's to be expected. As you say if Go or Rust ever do become popular it will be over decades, not within a year or two.