Ask HN: Should managed languages like C# be preferred over languages like Rust? | Hacker News Reader

Ask HN: Should managed languages like C# be preferred over languages like Rust?

4 pointsz3phyr3 comments

It's going to be 2014 soon; Many managed languages like Java/C# touted as the replacement to C/C++ in their niche are simply diminishing over recent trends. There is a huge surge of interest in native AOT compiled languages like Rust, C++14, Go etc. In foreseeable future, are we going to witness the rise of the other native language, or managed languages have still got some air? (In C/C++ niche of embedded, high performance, and heavy multimedia apps like game engines)

View on HN

Can you clarify what you mean by "managed languages"? I was under the impression that a "managed language" was one with garbage collection: Go and Rust fit into that category fairly well.

Concerning preferences, I would argue that these newer languages are preferable to last-generation languages like Java or C# because they provide _more_ management: the concurrency primitives (goroutines/channels in Go, tasks/pipes in Rust) remove the need for manual thread and lock management, it is all handled transparently by the runtime in a similar way that memory management is handled transparently by the Java and C# runtimes.

You seem to be generalizing a bit on the channels/goroutines and tasks/pipes... C# has the async/await pattern which is quite popular/powerful. I suspect recent incarnations of Java may have something similar as well (but not something I am up to speed on).

This is a different issue, I was referring more to concurrency using threads/locks vs. channels/goroutines and not to asynchronous I/O. However there is another point to be made here that helps to present the evolution of languages ;)

To contrast, in Go the async/await keywords are not even needed since asynchronous I/O is handled internally by the runtime; this parallels how the 'delete' keyword from C++ is not needed in Java or C# since the runtime handles deletion of memory. The idea is that the programmer does not even need to think about asynchronous details, it is completely transparent.

For example in Go (pretending that it has an await keyword) there is no difference between this:

    data := await socket.Read(...)

and this:

    data := socket.Read(...)

Both are asynchronous, but one of them avoids the need to be aware of the difference between synchronous and asynchronous I/O.

Reply on news.ycombinator.com