3 ms·
Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They prefer explicit and awkward concurrency construc
by wahern 7y ago
Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They prefer explicit and awkward concurrency constructs, perhaps because until Go, mainstream languages like JavaScript, C#, and Python implemented hacks largely because of implementation constraints, so it's all they know. They say thinks like, "I prefer knowing exactly when I might block". Yet you never hear them bemoan the fact that the OS hides process scheduling and VM paging; they don't complain that they can't hook into this at all, let alone be forced to do it 100% of the time for even the simplest code. They never ask that their language force them to be explicit about how and when a simple function call will setup a new stack frame. All of these things were, decades ago, the equivalent of fibers (or more generically asymmetric stackful coroutines). People were likewise skeptical about those things, but today these innovations--function calls, preemptive scheduling, virtual memory--are ubiquitous and invisible and the notion of doing away with them completely or even as default semantics, for all basic programming, would be inconceivable. What small cost they impose upfront by being the default (and often only) construct is vastly outweighed by their power; they're undeniably the correct way to model the vast majority of computing problems at the level with which they're concerned.
I agree, goroutines (or perhaps something a little more generic that doesn't conflate stack reification with scheduling) are absolutely the correct abstraction, and this will be proven in a few decades time. But until then we're stuck with people rationalizing the limitations of async constructs in their favorite languages; constructs primarily chosen because of quirky design constraints, principally C interop and C-based VM implementations that leak the semantics of the C ABI stack.
- apta 7y agoJava is going a similar route (project Loom), but they'll be implemented in a better way. Things like timeouts in golang are awkard to enforce, and monitoring hierarchies are not built-in. Java's Loom is already getting both.
- hactually 7y agoGetting getting getting, every time I head about how Golang is spanking other languages I see the "BUT MUH JAVA IS GETTING X IN Y $MONTHS". If you really can predict the future please tell me lotto numbers rather than being abrasive.
- apta 7y agoThe irony is that golang was created to replace C++ at Google, yet it didn't even make a dent in its usage for serious products. C++ and Java remain the heavy lifters there, as well as at other major establishments, precisely because of reasons like performance and (on the JVM) monitoring. golang ended up being more of a Python replacement.
- hactually 7y agoI'm not sure I understand the irony but keen to know what monitoring you are talking about?
- apta 7y ago* https://openjdk.java.net/jeps/328 https://openjdk.java.net/jeps/328 * https://www.baeldung.com/java-flight-recorder-monitoring https://www.baeldung.com/java-flight-recorder-monitoring * https://docs.oracle.com/javase/tutorial/jmx/overview/javavm.html https://docs.oracle.com/javase/tutorial/jmx/overview/javavm....
- hactually 7y agoThose are all focused on the JVM, not Java tho? Go doesn't have as many issues as the JVM on performance nobs to twiddle (a good thing) If we're comparing language exposed we've got pprof which can profile and generate flamegraphs etc all part of it as standard that blows your argument away IMO [0] [0] https://golang.org/doc/diagnostics.html https://golang.org/doc/diagnostics.html
- apta 7y agoThe JVM yes, and Java is the platform language, so it is the most efficient language for the JVM, and the one with least impedance mismatch. golang is not a magical solution that doesn't have problems. It has its fair share. Its gc is subpar for throughput purposes for instance. pprof is different. JFR provides live streaming events with minimal overhead. Regardless of what language you use, this feature is invaluable. It's not just for performance, but for debugging, monitoring, and tracing.