Slashdot Mirror

Memory management is an issue that has me excited about Rust. Rust memory management is explicit, easy to use, deterministic, efficient and safe. The language designers understand that garbage collection is costly and that endemic use of a garbage collector limits applicability.

Although Rust does have reference counted heap objects on the so-called "exchange" heap, memory is normally allocated on the stack or on a "local" heap (via an "owned" pointer) that has "destructor-based memory management," much like C++ objects but without the leaks and wild pointers.

The result is the vast majority of allocated memory is not managed by the garbage collector. Use of the exchange heap is exceptional and explicit, yet immediately available when necessary. Otherwise, memory "management" is reduced to efficient stack pointer manipulation or simple, deterministic destruction. Compile time checks preclude bad pointers and simple leaks so common with traditional systems languages.

There is a series of detailed blog posts about Rust memory management here.

Rust was inspired by the need for an efficient, AOT compiled systems programming language that is productive, concise and at least as safe as contemporary "managed" languages. Its memory management scheme goes directly to the point of this story.

What's so special about this language anyway, that couldn't be done using C source (perhaps with some extensions) but a different compiler and runtime system?

I've only spent a few minutes reading through the tutorials, but I'm thinking section 3.1 is probably significant:

http://static.rust-lang.org/doc/tutorial.html#syntax-basics

Summing up my recent comment on another story:

Historically C has been irreplaceable for serious system programming, and on the other side of Ousterhout's Dichotomy we had decent scripting languages like Python, Ruby, Tcl, Lua, etc. Now we're seeing the slow emergence of a new generation of languages that are close enough to the power and efficiency of C, and also offer much greater developer productivity and safety: D, Go, Rust, Nimrod, etc.

--libman

This was a NULL-pointer exception, not a buffer issue. But I do agree that it makes more sense to invest in building IRCd software which is written in string-safe and pointer-safe languages. Mozilla's rust language, for example looks promising for use in IRCd. The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.

However, it is easier for most people hacking on IRCd to just pick up a 2.8-derivative.

If there was a smaller copyfree C compiler available (no C++ / ObjC bs), then it would have been much preferable to LLVM / Clang as part of FreeBSD base. Unfortunately projects like pcc / ack / etc are further behind. Perhaps Open / Net / DragonFly BSD are holding out for those, but FreeBSD needed to ditch gcc ASAP.

C is the system language of the UNIX generation. UNIX uses a very specific modular approach to managing complexity that is much better than OOP. C++ / ObjC add nothing to system programming but useless complexity. They were designed for the very opposite of the UNIX philosophy: huge chaotic app / game projects where dozens of programmers are all stepping on each-other's toes. They might have some virtues when it comes to Web browsers and widget toolkits, but that's not what UNIX is centered on. Languages that aren't particularly distinguished on either side of Ousterhout's Dichotomy (Java, C#, Haskell, etc) are a complete waste of noosphere. Plenty of decent scripting languages are available for people who want productivity (Python, Ruby, Lua, etc), and the small parts of their code that are performance-critical can then be optimized with C to get the best of both worlds.

The supremacy of C as the system language may be challenged someday, but not by C++ or ObjC. It will be a whole new generation of languages, of which D / Go / Rust / Nimrod are very early examples, and the post-POSIX OS'es of the future will be written from scratch in such languages. But UNIX should remain C.

--libman

First, an actual link to the language's site.

Second, isn't it time we stop reinventing the same language over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Are We There Yet?.

First, an actual organism is making a reply.

Second, isn't it time we stop breeding the same species over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Creationism Evolved.

( Good luck with your Stagnation & resulting Extinction, I choose to Adapt and Evolve -- Even if this means some small efforts are wasted in dead ends along the way. )

First, an actual link to the language's site.

Second, isn't it time we stop reinventing the same language over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Are We There Yet?.

If you have never used either of the two editors with supported syntax highlighting then just use Emacs as it has always clearly better than Vim.

1. Feel free to back up some or all of those claims about "constant refusal".

2. The migration to Rust will be gradual, and although it uses some new syntax and permits new paradigms, the code's not that hard to read.

I could now go on about how a developer not interested in facing new challenges, such as a change in language or project, does not have the right mindset to be a good programmer, but that may be a bit harsh.