
Less is exponentially more (2012) - tpaschalis
https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
======
nshepperd
> Early in the rollout of Go I was told by someone that he could not imagine
> working in a language without generic types. As I have reported elsewhere, I
> found that an odd remark.

> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...

> If C++ and Java are about type hierarchies and the taxonomy of types, Go is
> about composition.

How do you get all the way through designing a programming language without
realizing how incredibly wrong-headed this is? "Inheritance hierarchies are
bad", so... you exclude generics (which are compositional, and have nothing to
do with inheritance), and only support subtyping polymorphism via 'interfaces'
(ie. inheritance)? That is the exact opposite of his claimed principles!

(And then as a minor concession to programming usability, he adds generics
anyway, but _only_ for built in types (maps and arrays), so advanced data
structures are still an exercise in void* wrangling.)

~~~
autarch
I was thinking exactly the same thing. I don't understand how you segue from
generics to "too many types are bad" to "inheritance is bad". I totally agree
with the last idea. Inheritance is not a great model for code and it quickly
becomes unwieldy.

But that has nothing to do with having an expressive type system and generics.

We can look at Rust for an example. It's "OO model", such as it is, is fairly
similar to Go's. You can define a thing that combines data and behavior. You
can define traits/interfaces that objects can implement. You can use those
trait/interface types in place of concrete types. But Rust also gives you
generics, sum types, and pattern matching. IMO, that makes for much cleaner
code than doing the equivalent in Go.

------
hyperman1
A 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-assed language. I dumped it, tried rust, and even with its slow compile
times I couldn't be happier.

Now a few releases later, they fixed sort so I can only implement compare.
Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A
is source code generation, a clear indication go isn't enough on its own. 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.

It was a near miss, though. SOme things are clearly correct. I want to look
again when they finally have generics, and some basic collections. I hope that
day comes and I can give it a new chance. But until then, less was simply not
enough .

~~~
throwaway894345
It's interesting the things that people think are essential and the things
they are willing to put up with. I'm willing to put up with writing my own
sort.Interface, adding in a few lines of boilerplate for error handling,
loops, and the odd linked-list/btree/etc. I'm not willing to script my own
build system in an imperative DSL or deal with dependency hell a la Java,
Python, C/C++, etc. I'm willing but _very_ reluctant to use a language that
requires me to write a bunch of scripts to automate publishing source code and
documentation packages. I'm willing but very reluctant to use a language with
minutes-long build times. I'm willing but very reluctant to use a language
that where most packages are poorly documented, lacking even basic type
information (looking at you, Python and JS). I'm willing but very reluctant to
use a language in which the ecosystem is an absolute mess due to the pervasive
use of inheritance. I'm unwilling to use a language that simply can't be
optimized (and "just write it in C" or "just use multiprocessing" are only
applicable to a narrow range of bottlenecks--good luck processing a large
Python data structure, for example).

This isn't Go fanboyism; I've worked with lots of languages in my career, and
I still get really excited and try new languages all the time, but they all
tend to optimize for nice-to-have things (such as a type system that can
handle those 1-5% of use cases where Go would have you drop to interface{}) in
exchange for essential things like sane tooling. Rust stands alone as a
possible exception, but only since it shipped non-lexical lifetimes, rust-
analyzer, and a long tail of other improvements that have recently brought its
usability down into a range that is acceptable for general application
development.

~~~
pydry
>I'm not willing to script my own build system in an imperative DSL or deal
with dependency hell a la Java, Python, C/C++, etc.

Ironically, the fact go tried to make me use GitHub as a stopgap package
manager (& denied one was necessary) while they built their own was what made
me run away screaming.

They've since fixed that but seeing them fail at what Perl managed in 1995 and
what became standard is larger languages around the turn of the millenium in a
brand new language in 2010 wasn't a great omen.

~~~
throwaway894345
People scoff about "GitHub as a package manager", but it hasn't chafed me
much. Moreover, the scoffing isn't very substantial--it's often some variation
of "but GitHub goes down all the time?! You will never be able to
build/distribute your software!", which is trivially refuted (the GitHub UI
goes down all the time, but its git service going down is much rarer; you can
use a caching proxy if you're really concerned about reliability of the git
service just like you would with a more typical package repo; GitHub isn't
necessary to distribute Go applications unlike Pypi/NPM/etc for Python/JS
apps). There are probably lots of good reasons for why the GitHub model is
inadequate, but for whatever reason these aren't brought up in the
aforementioned scoffing and I haven't stumbled on them (e.g., I don't have any
private repo dependencies for my projects, but perhaps it would be a PITA for
those who do?).

~~~
pydry
>it's often some variation of "but GitHub goes down all the time?!

It was never about github's downtime. It was about having to manage the code
of your dependencies yourself.

>you can use a caching proxy if you're really concerned about reliability

yay one more piece of infrastructure that will break.

>There are probably lots of good reasons for why the GitHub model is
inadequate, but for whatever reason these aren't brought up in the
aforementioned scoffing

I really think they were.

------
nobleach
While this philosophy has a lot of value, it just isn't for me. I did a few
apps in Go, and fought my way to a decent level of proficiency. I got to a
point where I could solve some problems without constantly consulting the
docs. But in the end, I wasn't enjoying the experience. The speed was great,
the compilation was great. All the selling points were true. But it was
missing so many things that I enjoyed using from other languages. (Mostly
methods for dealing with collections of data - everything in Go is a for
loop). I did another project in Kotlin shortly after and wow, that language
has everything AND the kitchen sink! But, I truly enjoyed myself more while
working with it. So, this is not me saying Go is "bad". It's actually quite
good. It's just not something I enjoy.

~~~
LandR
I feel the same, we are starting to use Go now and I really don't like it.

Things that in other languages I can do in half a dozen lines of code, I find
I'm writing 4x time more in go.

And I find it pretty unreadable, it's not nearly as expressive as other
languages I enjoy using.

There's too many missing features I use heavily in other languages that make
my life easier that I really miss them in go.

I will say I do like that its opinoinated on the formatting. Just takes away
an entire tiresome argument.

~~~
eriktate
> And I find it pretty unreadable, it's not nearly as expressive as other
> languages I enjoy using.

I tend to conflate higher expressiveness with being "clever" until you're
really proficient in the language. I think Go's main value prop is that it
performs well with very little ramp up time compared to languages with more
powerful features.

If you have a team of people who are really strong with something like OCaml
or Scala, they'll be amazingly productive. But if you have a rotating team of
engineers with varying backgrounds, it's hard to beat Go when you're talking
about time-to-productivity.

~~~
sanderjd
The basic set of more expressive operations (like map, filter, and
reduce/collect) are not "clever", they exist in lots of "boring" languages,
not just languages like OCaml and Scala. It is true that their semantics must
be learned, but this is also true of the semantics of for, while, if, switch,
function(), object.method(), etc. etc. We don't lament that learning how
function calls work is lengthening the ramp-up time of people who already know
how to write straight-line code and jumps.

~~~
nobleach
Yeah, I think the charge of "clever" is often thrown out when one uses a
different way of thinking. I'm not an FP zealot at all, but I do think
learning to think recursively does something to one's programming. (Working
through SICP or even The Little Schemer) My own personal take it that I
appreciated and enjoyed some of those paradigms far more. What I would NEVER
try to do is turn Java or Go into those paradigms though. I would, however,
like to have some of those handy niceties available by default. (I want to map
over a collection and apply a function to each member). But again, that's a
personal preference.

~~~
sanderjd
It is idiomatic in Java to use the streams api for mapping, filtering, and
reducing. It is a perfectly natural fit in the language. The only bummer is
that those operations can't be built directly into the collections api due to
compatibility concerns. It doesn't require thinking recursively or anything
clever or advanced, they are very simple operations.

------
free_rms
Pike's take is pretty unfair to C++11, given how ideas like 'rvalue
references' held up REALLY well.

Yes, they were introducing even more complexity to a complex language, but how
else are they supposed to incorporate better ways of doing things while
maintaining backwards compatibility?

I suppose one could always just build a new language that doesn't have the
historical cruft, but in this case that's Rust and not Go.

------
ses1984
>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?

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

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

------
acarl005
Whenever the topic of generics comes up, especially in Go, things seem to
devolve into a ragefest about inheritance and OOP. Why? I don't want the mess
of inheritance any more than the next chap. I just want generics for algebraic
types—a single definition for a List, Set, Map. I wish the error-handling
looked more like Rust's Result type instead of the double-return idiom.
Algebraic types alone (without inheritance) make things an order of magnitude
more expressive.

~~~
ansible
> _I wish the error-handling looked more like Rust 's Result type instead of
> the double-return idiom._

After this and a few other issues I had with Go's design, I just started
learning Rust. Though I hear good things about Swift these days, hopefully
they will provide full support for all popular platforms in the future.

~~~
tonyedgecombe
Swift is nice but I don't see it making much sense outside of the Apple
ecosystem.

~~~
winrid
It's a wonderful language. I'd love to work with it server side it I found
said job.

------
MereInterest
For any new language that I learn, my go-to thing to try is to implement 4th-
order Runge-Kutta solving of an ODE. This implementation must be usable for
both built-in types and user-defined types, and must have reasonable
performance for the language.

* C++, easily doable with templates.

* Python, easily doable with duck typing.

* Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input.

* Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply()

* Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading.

Complexity has to go somewhere. By aiming for a simple language, Go forces the
complexity to be in the developer side instead.

------
FpUser
_" People who are excited about C++11's new features are not going to care
about a language that has so much less. Even if, in the end, it offers so much
more."_

I find Go too limiting and definitely not offering "so much more". The author
is probably right mentioning "big teams". Sure if I have whole shebang of
programmers each nibbling at small particular task and appropriate budget it
will work. But comparing the amount of work per developer per time I can have
with more sophisticated "traditional" languages does not put Go in any good
standing in my opinion.

------
greendave
> What you're given is a set of powerful but easy to understand, easy to use
> building blocks from which you can assemble—compose—a solution to your
> problem. It might not end up quite as fast or as sophisticated or as
> ideologically motivated as the solution you'd write in some of those other
> languages, but it'll almost certainly be easier to write, easier to read,
> easier to understand, easier to maintain, and maybe safer.

I really like go, and I daresay it makes many things easy to implement and
understand, but I do find the flexibility/lack of sophistication allows one to
end up writing what amounts to improved C. Great for smaller projects, but
surprisingly difficult to manage as it grows.

------
pot8n
Golang didn't succeed because it is simple or powerful or any of the, I
apologize, nonsense your hear from the Gophers. Golang succeeded because it
was the only available relevant option and alternative to the aging Python and
Java when the cloud took off in the early 2010s.

~~~
AnimalMuppet
OK, but for Go to succeed in that environment, it had to be _better_ than
Python and Java at programming for the cloud. It doesn't matter that Python
and Java were "aging" \- programming languages don't die from old age. Go had
to be better than what was there.

And in what ways was it better? Power and simplicity (at least for writing
those kinds of programs).

~~~
sl1ck731
Why did it have to be better? It just had to be created and evangelized to a
specific group (and likely because it was by a specific company). I don't
think it has anything to do with "better" in one way or the other.

Developers are constantly looking for new languages to fiddle with without any
objective reasoning.

~~~
AnimalMuppet
Sure, they're looking for new languages to play with. They're not looking for
new languages to write major projects in, though. You write major projects in
languages that you have already fiddled in, and the fiddling has given you
confidence that they're up to the task. Nobody (sane) sees a publicity blurb
and decides to bet a major project on it.

Don't confuse "they came to a different conclusion than me" with "they're
sheep".

~~~
sl1ck731
I mean cargo culting tech and languages is practically a meme at this point in
tech. I'm not sure I can scientifically argue that its widespread but I think
it is equally futile to argue that it does not happen frequently.

~~~
AnimalMuppet
Does it happen? Sure. More often than it should? Absolutely.

Often enough to account for the popularity of Go? I strongly doubt it. It
could have accounted for Go's popularity in the first year or two. But now, Go
has been used by too many people to do too many things. Go's popularity now is
based on its ability to help you get things done, not on Google's name.

------
oftenwrong
This does a poor job of justifying the claim that golang is more expressive
despite having fewer features than similar languages. I agree to a certain
extent that golang's simplicity is an advantage. However, its simplicity does
actually make it less expressive.

For example, in Java one can trivially create a class like `Maybe<T>` with a
method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any
classes filling in the parameters. I believe golang is unable to express this.

------
smoorman1024
I've been working in golang professionally for about a year now coming from a
long career in C++. Although there is some simplicity to golang that can be
appreciated things like this below make me think that the premise of less is
more is fundamentally incorrect if you cannot accomplish everything that is
necessary.

[https://github.com/protocolbuffers/protobuf-
go/blob/master/i...](https://github.com/protocolbuffers/protobuf-
go/blob/master/internal/pragma/pragma.go#L29)

Specifically the last one of embedding an empty array of mutexes into a struct
prevents that struct from being copied. This is something that is easily and
explicitly accomplished in C++ by making the constructors private.

------
api
I 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 it imposes more cognitive load because now you have two different
approaches to every problem in the same language (one async, one not).

IMHO minimizing language-imposed cognitive load should be a core goal of any
programming language. Human brains are finite, and programmers should spend
the majority of their mental energy thinking about the problem being solved
not the language.

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

~~~
hactually
Getting 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
The 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.

~~~
wahern
Go was never intended to replace C++. It was aimed at a very specific target:
engineers, especially junior engineers, writing function-as-a-service
software. Thread-based concurrency (as in logical thread of execution, not
"kernel threads") with message-based synchronization, structural typing, and
static compilation were their answers to what in their experience were the
biggest impediments to writing good network software that could scale
reasonably well using the most natural programming approach.

All of the original creators were clearly of the "best tool for the job, even
if you have to build it from scratch" persuasion. How many different languages
and programming constructs can you find on Unix or Plan 9? The notion of
centralizing all development around a single all-purpose language, a la C++ or
Java, is anathema to their stated engineering principles and the opposite of
the design elements of the many computing environments they spent their
careers designing and using.

One can quite easily disagree with their design choices and tradeoffs. I find
static compilation short-sighted. But I do appreciate how it fits into their
overall approach; and in that way I find static compilation _less_ short-
sighted in Go than in Rust. Some aspects of goroutines are problematic.
Hassles with dealing with timeouts exposed flaws in their scheduling and
message passing abstractions. But those flaws are in the details, not the
fundamental model; and the better way to implement those details is more
difficult to determine. (I've had to wrestle with such questions myself as
I've written multiple async I/O libraries and frameworks. If Go had come out
10 years earlier my entire career trajectory may have been different.)

FWIW, I don't write any Go software. I admire it from a distance, the same way
I admire C++, Rust, and Java[1], while I slave away in C and several other
languages. Though, there's an honesty and clarity in Go that is lacking in
other languages, precisely because Go _isn 't_ trying to be an all-purpose
language, and because the authors have an understanding of (and deliberately
leverage) the interplay between design goals and implementation constraints
that can only come with having designed and implemented umpteen different
languages before.

[1] I did have a short tryst with Java a long time ago, but it actually ended
up driving me into the arms of C. Not because of the language, but because of
the ecosystem--licensing, tooling, interop, etc, was an extremely poor fit for
Linux, and in many ways still is.

~~~
apta
> Go was never intended to replace C++

As per the creators of the language who claimed that they got the idea of
writing a new language while waiting for C++ to compile, it was. You can read
up about this from them, they were quite clear about it. They even expressed
surprise as to why they didn't get the migration of C++ programmers they were
anticipating to golang, but instead got Python programmers.

It's not like the lack of green threads stopped people from writing highly
concurrent code. Libraries like Vertx, Reactivex, and Akka have existed for a
while now. Also, all major platforms have a notion of green threads/coroutines
(Java is getting the former and C++ is getting the latter). This was
practically the only thing golang had going for it, and once they're
implemented for those platforms, it's hard to make a case for golang given
it's bad design decisions.

> Hassles with dealing with timeouts exposed flaws in their scheduling and
> message passing abstractions.

That's a good point, which is why Java's green thread implementation is
superior to golang's. Timeouts and cancellations are designed in from the
start, as well as hierarchies of green threads (similar to Erlang's).

Again, it just show's that golang does the minimum, and pushes complexity onto
the user under the guise of simple language design.

> licensing, tooling, interop, etc, was an extremely poor fit for Linux, and
> in many ways still is.

The JVM is open source and has been for a while now. Could you elaborate on
why it's not a good fit for Linux?

~~~
hactually
> That's a good point, which is why Java's green thread implementation is
> superior to golang's.

So the future invention of something that doesnt currently exist is going to
be better than something that does exist is your argument?

------
vorpalhex
I code in Javascript/Node, and I also code in Go. They're both very useful
tools and they're useful in different ways. I find Go to be a good tool when I
know what I'm writing and I have clear forms in each step.

------
jasode
Previous discussion since the HN "past" link doesn't bring up the prior thread
because tld was ".de" instead of ".com" :
[https://news.ycombinator.com/item?id=6417319](https://news.ycombinator.com/item?id=6417319)

------
DLA
I'm going to jump in and take a hard Pro-Go stance. Based on experience
developing for more than 5 year with Go and deploying systems around the world
--in-house hosted and cloud.

I have immensely enjoyed the "less is exponentially more" philosophy with Go.
In Go there is one or a small number of way to do something. Contrast that
with C++ where there are any number of ways to do something and at least as
many styles of coding. Too much choice results in complexity.

IMO the generics debate is overblown. The systems I've build with go tend
toward heavy data processing (ETL, correlation, extraction and the like) and
service (JSON APIs supporting front-ends; event some front ends with Go
Templates). Never once was I like "my life sucks because I don't have
generics." Fair and balanced: Processing JSON in Go takes some getting used
to, especially when the JSON structure changes. However, there are some good
libs to help. It's just a friction point given the typed nature of Go.

The operational simplicity of Go cannot be overstated. Go's production of a
deployable binary with zero dependencies is a blessing. There's an amazing
deploy tool you can use called: cp. Compare that to the library version hell
that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You.

The cross compilation of Go code works beautifully. Just 2 weeks ago I had to
demonstrate a tool to a customer and due to COVID it was virtual. We had
problems with MS Teams connecting to our dev platform so literally 15 minutes
before the demo I cross-compiled to a Win binary and moved it to the machine
hosting the Teams call. Victory.

Because of go fmt, _all_ Go code looks the same. That's a massive advantage to
read/understand/use OPC (other people's code). Ditto for the automatic
documentation generation -- it looks the same and behaves the same across Go
projects.

I abhor the Java ecosystem for so many reasons I just don't have the energy to
go into. It's my opinion, so not up for debate. If Java works for you, by all
means have at it. Robust solid technology for sure. Not hating here; just
choosing.

So, my Go journey has been and continues to be fantastic. It is my preferred
platform for pragmatic reasons--the same sort of reasons it was developed by
Google in the first place. My team and I can get stuff done quickly. We can
scale it. We can leverage all the CPUs on a box running big data processing
flows. We can have automatic code-linked documentation and formatted code and
can leverage the same from others. We have build in testing. We can make high
performance services and servers with ease. We don't have to deal with
ridiculous configuration nonsense. We get instant compilations. We get great
tool support (vscode + Go for the win). We get a batteries very much included
stdlib.

And most of all we get a platform that understands and managed complexity in a
favorable way.

$0.02. Ok, maybe $0.05 (inflation).

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

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

\-- Factories of factories of factories. :)

\-- JVM install and config (many dials = control but also complexity).

\-- Impractical / painful to write without an IDE.

\-- Concurrency model, as compared to Go.

\-- Std lib not matched to work I use Go for.

\-- Memory consumption.

\-- Performance (for the work I do).

\-- Multiple inheritance (allows unnecessary complexity).

\-- [https://astaxie.gitbooks.io/build-web-application-with-
golan...](https://astaxie.gitbooks.io/build-web-application-with-
golang/en/03.2.html) vs. [https://medium.com/@ssaurel/create-a-simple-http-
web-server-...](https://medium.com/@ssaurel/create-a-simple-http-web-server-
in-java-3fc12b29d5fd)

\-- Oracle.

(edits: reformat pretty; compile times)

~~~
apta
> \-- 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.

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

~~~
apta
I know how to write golang, which is why I'm well aware of its shortcomings
and the issues its inferior design causes, and the costly bandaids that have
to be implemented to poorly attempt to mitigate said issues.

~~~
hactually
Got an example repo you've worked on as happy to help work with the ecosystem
rather than against it?

~~~
apta
It's a non-public code base.

~~~
hactually
So a single project, that you designed and built is causing you problems?

I don't think Go is the problem

~~~
apta
It's a huge code base, with literally thousands of sub-projects, with non-
overlapping teams working on them. When I see the same issues arise, the only
common thing is the language.

------
westicecoast32
I'm writing a language. I was wondering what you all suggest it have before
you would seriously try it out? I don't think most people cares about syntax;
does it need to be attached to a large project?

The beta of the last language I wrote had maybe half a dozen fans. I threw
away the compiler/language because I didn't really know how to write a
compiler back then. I'm writing a new one now

------
dang
See also:

[https://news.ycombinator.com/item?id=16548684](https://news.ycombinator.com/item?id=16548684)
(2018)

[https://news.ycombinator.com/item?id=6417319](https://news.ycombinator.com/item?id=6417319)
(2013)

Discussed at the time:
[https://news.ycombinator.com/item?id=4158865](https://news.ycombinator.com/item?id=4158865)

------
abjKT26nO8
Needs "(2012)" in the title.

------
kenforthewin
Please tag this with the date, 2012. Great but old blog post.

