

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

It&#x27;s going to be 2014 soon; Many managed languages like Java&#x2F;C# touted as the replacement to C&#x2F;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&#x2F;C++ niche of embedded, high performance, and heavy multimedia apps like game engines)
======
robbrit
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.

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

~~~
robbrit
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.

