Hacker News Reader

Comment by ilaksh | Hacker News Reader

I am not associated with nimrod in any way, just an enthusiastic new user. Before I found out about nimrod I thought Rust was the best new language.

View on HN

Nimrod, like D, does great things in terms of metaprogramming and static code generation whilst providing a GC that abstracts away from memory management. Rust on the other hand thrusts memory management into the programmers face, excelling at providing safe, deterministic control over allocation and a relatively advanced type system compared to the incumbent systems programming languages. Nimrod and D seem like worthy alternatives to Go and C#, where as Rust is providing a much needed alternative to the venerable C and C++ languages that have dominated systems progamming for the last forty years.

It seems to me like a marketing failure that Nimrod and D seem to be attempting to go after the low level systems programming domains when they should really be competing at a higher level of abstraction.

To add to this: Rust puts a lot of emphasis on memory safety, including in parallel code, while neither D nor Nimrod have such a strong focus on that.

Agreed. The language defaults to safety and immutability, and linear types and regions are built into the type system. With the addition of mandatory RAII and unsafe blocks, safe allocation and concurrency primitives can be built as libraries rather than being baked into the language.

Oberon and Modula-3 were quite capable GC enabled systems programming languages.

In Oberon's case, full GUI single workstations systems were used during several years at Swiss Federal Institute of Technology in Zurich (ETHZ).

OS vendors just don't care to bring into the mainstream such systems.

I don't know enough about Oberon and the Modulas as I should, but I'm guessing GC was the default and was required for safety? The libraries required GC too?

GC was originally intended to be the most common form of allocation in Rust, but once linear types and regions were properly implemented it turned out that GC wasn't nearly as necessary as was previously thought. It is definitely useful though for some use cases, which is why it will be built as a library, with language hooks to make it clean to use, but users definitely won't have to pay for it if they don't use it.

The GC was part of the kernel.

The whole operating system was implemented in Oberon, just with Assembly for the usual parts there is no way around it.

Both languages have value types and stack allocation as well. GC is only used for explicitly allocated heap data.

Modula-3 allows for declaration of untraced references as well.

Ahh - your comments about Unix taking the wrong path in another story have more context now - I wasn't aware that GC had been integrated into an actual working kernel in the wild. Very interesting!

If you want to read about the very first Oberon implementation, here is some info,

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/

Afterwards, there were improved systems which provided a better experience, improved the programming language and had some parts moved from Assembly into proper Oberon. Namely EthOS and Active Oberon (AOS/Bluebottle).

If such systems had got industry support, who knows how mainstream computing would be now.

"Rust thrusts memory management into the programmer's face."

How can anyone possibly think that is necessary or a good idea?

In some domains, it is necessary, and in others, it's quite a good idea.

Garbage collection is great, but not for everything.

What domains is it necessary/quite a good idea?

For example: realtime systems, rendering threads, embedded systems that require minimal runtimes. Smaller subroutines on the whole don't really need it, and those small performance gains can add up considerably in an intensive system. GC is mainly useful for things with undetermined lifetimes. Glue code essentially.

A rendering thread can stop for ms once a second.

What does this have to do with Rust?! Especially to the This week in Rust column?

It's about putting Rust in perspective and learning about alternatives.

The same way when a critic reviews a movie, he also mentions and compares to other movies.

Eh? It doesn't do that. It doesn't provide any context or assertions why one is better over the other. It comes of as a way to market a different language in a thread about Rust.

Here is example how I see OP in lieu of your analogy:

"I liked movie Gravity until I watched movie Her ..." and continues to ramble about movie Her.

Well, it'd be more accurate to not even have the "...", given the original comment.

How does nimrod compare to Julia?

Here is the lay of the land as I see it – I could be wrong though, so take it with a grain of salt:

Julia is dynamically typed and leverages LLVM's JIT support to generate efficient code at runtime. Julia has a clear goal of taking on the scientific and statistics domains where R, Matlab and Sci/NumPy are currently dominant. It is an elegantly designed language that provides blazingly fast bindings to established Fortran and C numerical libraries.

Nimrod is statically typed and compiles to C, C++ or Objective C. It seems to be aiming to be 'general purpose', but there has been efforts to position it as a systems level language. The biggest draw seems to be its expressive metaprogramming capabilities[0] and clean, python-esq syntax.

[0]: http://www.infoq.com/presentations/nimrod

I don't think that Julia is targeted only for scientific computing. http://stackoverflow.com/questions/17433435/what-makes-julia...

Reply on news.ycombinator.com