3 ms·

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

by robbrit 13y ago

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 13y ago
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 13y ago
  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.

by robbrit 13y ago

jmspring 13y ago

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 13y ago
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.