4 ms·

A lot of the productivity gain in higher-level languages comes from not having to manage memory. Having three different incompatible, differently allocated poi

by cmccabe 14y ago

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 GC was possible, even for Java. Android and .NET showed us that even without pauseless GC, the performance of GC'ed languages was adequate to build attractive user interfaecs. A lot of Rust's design choices mean that it's not really suitable as a web development or scripting language, and those two communities have shown themselves the most receptive to new languages. Mozilla has tried to rewrite their core product in a different language before. Look up "Javagator." It did not end well. But, who knows. Maybe this time really will be different.

pcwalton 14y ago
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.)
- cmccabe 14y ago
  It's a little misleading to say that GC makes "attractive user interfaces... significantly harder." For any business application, for example, using GC is a no-brainer. That's why I mentioned .NET in my response. Android games have been known to struggle with GC sometimes. However, garbage collection has gotten a LOT better on Android over the years. I wrote a small game in Android 1.1, back when GC pauses were anywhere from 100ms-250ms, and avoiding allocations was VERY important. Nowadays, most pauses are less than 5 ms, and the NDK is always available if you want to write native code and avoid GC altogether. In general, the game industry seems to be moving towards a model where you have "engines" and "level packs." The physics, graphics, etc. engines are developed by a small group of people in C or C++, and the level packs are in whatever scripty language you want. The development of the web reflects a similar split. You have the C/C++ engine, and the HTML/CSS/ECMAScript content. C and C++ have low programmer productivity and a lot of odd quirks, but nobody cares because the bulk of the development has moved higher up the stack. So attempts to replace C or C++ get a "if it's not broke, don't fix it" type response. This is one reason why golang, for example, has seen more users come in from the scripting and web development community than from the C++ community. C++ projects tend to be old, conservative projects that are at the bottom of some giant stack-- like Google's infrastructure, for example. Rust has some interesting ideas. The typestate concept in particular is interesting. I also do kind of get what they're going for with the 3 different memory types. I guess we'll see how it all works out.
scott_s 14y ago
Some tasks - such as implementing kernels - are poorly suited for garbage collection. And while there do exist garbage collectors that can be used in hard real-time scenarios (http://queue.acm.org/detail.cfm?id=1217268 http://queue.acm.org/detail.cfm?id=1217268), that's not the norm. I think there will always be a place, at the lowest levels, for manual memory management. Providing abstractions to make that as safe and manageable as possible is a Good Thing.
- cmccabe 14y ago
  Some tasks - such as implementing kernels - are poorly suited for garbage collection Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications. Of course there's a bunch of different definitions of "hard realtime" floating around, and rust would probably be suitable for some of them. I fully expect that someone will reply to this with something like, "Well MY definition of hard realtime is playing movies, and Rust is suitable for that." :) But when I think of hard realtime, I think of applications where you must have absolute determinism.
  - scott_s 14y ago
    Your definition of hard real time is the accepted definition; playing movies and such is soft real time. Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
    - cmccabe 14y ago
      I don't think Go is intended to replace C. It was intended to replace C++.
      - scott_s 14y ago
        C++ was intended to replace C, so it's intended to replace both.

by cmccabe 14y ago

pcwalton 14y ago

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.)

cmccabe 14y ago
It's a little misleading to say that GC makes "attractive user interfaces... significantly harder." For any business application, for example, using GC is a no-brainer. That's why I mentioned .NET in my response. Android games have been known to struggle with GC sometimes. However, garbage collection has gotten a LOT better on Android over the years. I wrote a small game in Android 1.1, back when GC pauses were anywhere from 100ms-250ms, and avoiding allocations was VERY important. Nowadays, most pauses are less than 5 ms, and the NDK is always available if you want to write native code and avoid GC altogether. In general, the game industry seems to be moving towards a model where you have "engines" and "level packs." The physics, graphics, etc. engines are developed by a small group of people in C or C++, and the level packs are in whatever scripty language you want. The development of the web reflects a similar split. You have the C/C++ engine, and the HTML/CSS/ECMAScript content. C and C++ have low programmer productivity and a lot of odd quirks, but nobody cares because the bulk of the development has moved higher up the stack. So attempts to replace C or C++ get a "if it's not broke, don't fix it" type response. This is one reason why golang, for example, has seen more users come in from the scripting and web development community than from the C++ community. C++ projects tend to be old, conservative projects that are at the bottom of some giant stack-- like Google's infrastructure, for example. Rust has some interesting ideas. The typestate concept in particular is interesting. I also do kind of get what they're going for with the 3 different memory types. I guess we'll see how it all works out.

scott_s 14y ago

Some tasks - such as implementing kernels - are poorly suited for garbage collection. And while there do exist garbage collectors that can be used in hard real-time scenarios (http://queue.acm.org/detail.cfm?id=1217268 http://queue.acm.org/detail.cfm?id=1217268), that's not the norm. I think there will always be a place, at the lowest levels, for manual memory management. Providing abstractions to make that as safe and manageable as possible is a Good Thing.

cmccabe 14y ago
Some tasks - such as implementing kernels - are poorly suited for garbage collection Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications. Of course there's a bunch of different definitions of "hard realtime" floating around, and rust would probably be suitable for some of them. I fully expect that someone will reply to this with something like, "Well MY definition of hard realtime is playing movies, and Rust is suitable for that." :) But when I think of hard realtime, I think of applications where you must have absolute determinism.
- scott_s 14y ago
  Your definition of hard real time is the accepted definition; playing movies and such is soft real time. Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
  - cmccabe 14y ago
    I don't think Go is intended to replace C. It was intended to replace C++.
    - scott_s 14y ago
      C++ was intended to replace C, so it's intended to replace both.