Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

winningraceconditions.blogspot.com

Post reply on HN
Print view View original

101–110 of 193 posts

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

#101

Post by gnuvince »

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…

Perhaps the language Clay (http://claylabs.com/clay/) might fit your tastes better?

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

#103

Post by pcwalton »

cmccabe wrote: post #100
scott_s wrote: post #38

Earlier quoted context omitted.

Do you have reasons why it's going too far, or is that just an emotional reaction? Consider that these pointer types map exactly to the pointer-type templates provide by C++11: unique_ptr, shared_ptr and weak_ptr: http://en.cppreference.com/w/cpp/memory In the interest of starting discussion and not just stating facts, I will take the position that I think Rust's adoption of these concepts into the language is a Good…

A lot of the productivity gain in higher-level languages comes from not having to manage memory. Having three different incompatible, differently allocated pointer types to fool around with slows you down. The creators of Rust are hoping that the speedup from not having to do global garbage collection in most scenarios will balance out the loss of productivity. Personally, I'm skeptical. Azul showed us that pauseless…

It's not impossible to build attractive user interfaces with garbage collection, but it is significantly harder, both for users and developers of the system. Android system apps go to great effort to avoid using the GC during critical animations, while in iOS this is much easier. Implementing a good garbage collector is a lot of work, and it's very difficult to tune; even the JVM, which has had an enormous amount of man-hours put into it, struggles with GC pressure under some loads.

Additionally, the applications we want Rust to be suitable for aren't competing with GC'd languages. They are competing against applications written in C++, with manual memory management and no automatic storage reclamation. They will be put head-to-head in benchmarks with them. We don't take performance regressions, and relying on global GC would be a significant risk. The Javagator is, in fact, an excellent example here!

(As an aside, the pointer types are not all incompatible; all pointers can become &T, and the vast majority of functions take & pointers.)

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

#104

Post by burntsushi »

megaman821 wrote: post #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.

I am a computer scientist that has performed research using Go because I love working with Go. I absolutely despise Java. So I'd say that your assessment is a bit off.

I also look forward to trying Rust as well. Having algebraic data types makes me giddy.

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

#105

Post by krickle »

zxcdw wrote: post #49
megaman821 wrote: post #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.

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…

My understanding is that a significant number of quants use Haskell.

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

#108

Post by zxcdw »

cmccabe wrote: post #98
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…

Yes, truly the only thing holding C++ back has been lack of features. Have a link: http://yosefk.com/c++fqa/

Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?

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

#109

Post by pacala »

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…

> We don't want to encourage the conflation of errors and exceptions that occur in languages such as Java.

I'm not getting this argument:

    checked exception == error
    runtime exception == panic

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

#110

Post by sanderjd »

zxcdw wrote: post #49
megaman821 wrote: post #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.

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…

You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize.

Having said all that, yes, I believe major commercial projects are started in those languages, though I have no idea if anybody plans them into the 2030s.

Post reply on HN