See also:
https://news.ycombinator.com/item?id=16548684 (2018)
https://news.ycombinator.com/item?id=6417319 (2013)
Discussed at the time: https://news.ycombinator.com/item?id=4158865
Less is exponentially more (2012)
71–80 of 102 posts
Re: Less is exponentially more (2012)
#72Earlier quoted context omitted.
Exactly, that is why it was needed to add the Google branding into the mixing potion. Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences. You missed the sarcasm on my comment.
Ah, I see. Sarcasm often doesn't come across in a post. But yes, I was surprised by your post, because it didn't sound like your usual position. I should have suspected sarcasm. But I disagree with you. Bell Labs was adequate branding for C and Unix, but not for Limbo or Plan 9. Sun's branding (and relentless support) was necessary for Java, but who did the same for Python, Perl, or Ruby? It's not just the branding o…
Python, all the well known places that Guido worked for that served as "X uses Python".
Ruby, mostly unknown until Rails.
Perl, got integrated early on on UNIX as the standard IT tool.
Re: Less is exponentially more (2012)
#73I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language. I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and…
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.
Re: Less is exponentially more (2012)
#74A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-asse…
Even if it does get generics, it's not enough to fix all the issues with the language.
Java and C# are getting native compilation soon (GraalVM, CoreRT), and when they do, it's hard pressing to see why anyone would settle for an inferior language (golang) over mature and better designed systems.
Re: Less is exponentially more (2012)
#75Earlier quoted context omitted.
> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. If you can gather some energy, I'd be interested in that.
Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences. -- Compile times! -- Operational complexity vs. Go. -- Built-in tooling vs. Go. -- Verbose XML configuration files. -- Lots of libs favor XML vice JSON. -- Deeply-nested code directories. -- Class-centric model (only). -- Verbosity and boilerplate. -- Fact…
> -- Compile times!
golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file.
> -- Operational complexity vs. Go.
The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.
> -- Verbose XML configuration files. > -- Lots of libs favor XML vice JSON. > -- Factories of factories of factories. :)
Nothing to do with the language.
> -- Deeply-nested code directories.
I've seen the same in golang code due to its packaging.
> -- Verbosity and boilerplate.
golang is more verbose and error prone for any non-trivial code base
> -- JVM install and config (many dials = control but also complexity).
The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM.
> -- Concurrency model, as compared to Go.
Java is getting green threads (see project Loom), and they'll be superior to what golang offers.
> -- Impractical / painful to write without an IDE.
Irrelevant for any non-trivial code base, since golang needs and IDE as well.
> -- Std lib not matched to work I use Go for.
let's see what golang has to offer anything remotely similar to java.util.concurrent.*
> -- Memory consumption.
Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more.
> -- Performance (for the work I do).
They're on par, and for any non-trivial code base, Java tends to be faster.
> -- Multiple inheritance (allows unnecessary complexity).
Java doesn't support multiple inheritance.
Re: Less is exponentially more (2012)
#76I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language. I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and…
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 t…
Java 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.
Re: Less is exponentially more (2012)
#77Earlier quoted context omitted.
> I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it.…
Kinda sad that this is getting downvoted, regardless of whether you agree it is certainly a cogent argument.
Whatever argument it's trying to make would have been better received without the blatant insults.
Re: Less is exponentially more (2012)
#78Earlier quoted context omitted.
Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences. -- Compile times! -- Operational complexity vs. Go. -- Built-in tooling vs. Go. -- Verbose XML configuration files. -- Lots of libs favor XML vice JSON. -- Deeply-nested code directories. -- Class-centric model (only). -- Verbosity and boilerplate. -- Fact…
> -- Compile times! golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file. > -- Operational complexity vs. Go. The JVM is superior for operations, observability,…
> -- Operational complexity vs. Go.
The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.
>> Disagree on operations part. Take a bare machine and with various configurations (some you don't control) and be ready to drop and run. Nothing beats Go. You cannot be simpler than copy a binary. Yes, the JVM has all sorts of observability. And also a load of tuning that often needs to occur. Go just runs and generally has outstanding performance.
> -- Deeply-nested code directories.
I've seen the same in golang code due to its packaging.
>> Go code is generally not as deeply nested. Often you have //. Not stuff like:
tomcat/java/org/apache/tomcat/websocket/server/xxxx.java
> -- Std lib not matched to work I use Go for.
let's see what golang has to offer anything remotely similar to java.util.concurrent.*
>> Friend, I'm talking about all the packages here: https://golang.org/pkg/
> -- Memory consumption.
Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more.
>> Yes, mu point (Xmx, GC settings, future things). Many dials == complexity.
> -- Concurrency model, as compared to Go.
Java is getting green threads (see project Loom), and they'll be superior to what golang offers.
>> More Java getting/future vs. Go has today. "they'll be superior to what golang offers." Since we are predicting the future, can I also get next week's S&P500 level for my trades?
>> Let me know when you can remotely close to writing https://github.com/eranyanay/1m-go-websockets/tree/master/4_...
Again as I opened with, these are my experiences. If Java and the future versions of Java and the tolling, IDEs, CI/CD tools, inspectors, etc, work for you. Great. Have at it.
I will keep deploying rock solid Go applications with minimal complexity and maximal performance/reliability, out of the box. I shall enjoy flatter code trees, working without a IDE when necessary (totally possible), enjoying simple make files for builds, and solving a ton real world problems with minimal external libraries (again, dependencies ~= complexity ~= risk).
Checkout some great stats from the 2019 Go Survey here: https://blog.golang.org/survey2019-results
I will depart with a final thought about Go: Why are increasingly more and more web-scale infrastructure projects being written in Go? (CockroachDB, Openshift, NATS, Docker, Istio, Etcd, Docker, K8S, large parts of AWS, Azure, and CGP).
Re: Less is exponentially more (2012)
#79>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?
To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class-based" languages, not anything to do with types in general.
> To be honest programmers have a habit of being very loose with language.
I wish this weren't true. It's quite damning.
It's less bad in a real-time conversation, with fast feedback about how well we're being understood. But it still hints that we don't have the concepts clear in our own minds.
Re: Less is exponentially more (2012)
#80Earlier quoted context omitted.
Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences. -- Compile times! -- Operational complexity vs. Go. -- Built-in tooling vs. Go. -- Verbose XML configuration files. -- Lots of libs favor XML vice JSON. -- Deeply-nested code directories. -- Class-centric model (only). -- Verbosity and boilerplate. -- Fact…
> -- Compile times! golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file. > -- Operational complexity vs. Go. The JVM is superior for operations, observability,…
Reading this, it honestly looks like you don't know how to write Golang and wish you could write more Java.
That's fine but pretending you're an SME and throwing off false equivalencies is really dishonest.