New programming languages come and go. Most of them remain nothing more than academic toys or niche novelties. Rust, development of which is sponsored by Mozilla, might be one of the exceptions. The new language reached the 1.0 milestone today, marking the point at which its feature set is stabilized and developers can start to use it without having to worry too much about their code getting broken by a major change.
Rust is an attempt to offer the performance and control of a language like C or C++, while making it much harder to write the kind of security-compromising bugs that are abundant in those languages. Key to this is the language’s handling of memory and memory management.
Some of the biggest problems with C come from mishandling memory; predominantly reading or writing more data to a block of memory than the block of memory contains, reading or writing from blocks of memory that have been deallocated. Environments such as Java, .NET, and JavaScript handle these through a combination of bounds checking—ensuring that every attempt to read and write memory is constrained to the memory that has been allocated—and garbage collection—ensuring that memory is deallocated only once all the references to the memory (through which reads and writes are performed) are destroyed.
Together, these techniques protect against a great many developer mistakes and the security issues they cause, but they can come at a price; garbage collection tends to increase memory usage and can introduce some inconsistencies in program performance. They also often introduce issues when using old C or C++ libraries—often desirable because so much existing code uses these languages—and so special care has to be taken when mixing and matching.
Languages such as Java, C#, and JavaScript also do not use native code, instead tending to be converted to native code only at runtime. This has some advantages—programs need not be recompiled for different processor architectures, and program safety can be proven at runtime, a useful feature when running untrusted code (such as in the browser)—but also tends to limit performance. While there’s no essential reason for this, and one day runtime code generation has the potential to consistently beat native code compilers, as things stand today, the highest performance comes of compiling once, and distributing native code.
Loading comments...