
Java is the COBOL of my generation and Go is its successor - jlhamilton
http://influxdb.org/blog/2014/04/30/java-is-the-cobol-of-my-generation-and-go-is-its-successor.html
======
noelwelsh
Sigh. We're still banging rocks together and amazed when occasionally there is
a spark?

Look, Ruby and Python -- their implementations just plain suck. There, I said
it. MRI and CPython are just a pile of crap. We've known since 1991-ish (see
Self) how to make performant runtimes for dynamic languages and 23 years later
Ruby and Python still have crappy slow interpreters with no useful concurrency
support. Note that Ruby and Python were both started around about that time
and are in fact older than Java. Sure the JVM team has a lot of resources, but
other language implementations, such as Racket, don't and they manage to solve
these performance issues.

So let's not get excited when a language implementation actually achieves a
decent baseline of performance. Let's expect that and move on.

Then there is Go's woeful head-in-the-sand type system and its dumb approach
to error handling. Errors values are logical ORs -- you can return a useful
value OR an error. In Go they are ANDs -- you return a value (which may not be
useful) AND an error. Just dumb. We've know how to do error handling without
exceptions and without boiler plate since about 1991 (Wadler; monads).
Generics since about 1985 (ML). Can we move on yet? Is a quarter-century long
enough?

Oh, and channels? That's Occam (1980s), if not earlier.

So what's Go? A language with an implementation that's not complete crap, and
an inability to absorb ideas known for 25 or more years. I'm supposed to be
excited that this will move our field forward? No thanks.

(This was a fun rant to write.)

~~~
pauldix
I think you're missing the point of the basic type system: simplicity. It's a
bigger win than you think when it comes to attracting new developers and
making code easier to read. Sure, there are languages that let you write more
succinct code and support all sorts of crazy typing, but one of the things
good code requires is readability.

Your code my be terse and elegant, but if other people can't understand it, it
won't matter. Code is as much communication to other developers as it is to
the computer it runs on. That's why I credit simplicity as Go's greatest
strength.

~~~
eudox
Either the language is complex or the application code is. Which one would you
prefer to keep simple?

~~~
wonderzombie
I think you're suggesting a false dichotomy.

Of course a complex language can be used to write simple code and vice versa.
Ultimately every program is going to increase in complexity-- that quote about
failure vs legacy nightmare applies here.

IMHO it's better to reduce the complexity of the language to a minimum so that
language/runtime complexity doesn't have a multiplicative effect on
application code complexity.

For instance, C++ is a complex language. That complexity inevitably accrues to
applications written in C++. This is a conscious trade-off of the language --
performance + high level programming, or what have you.

In the end, though, I am not sure I'd argue there's much correlation between
simplicity of the language and simplicity of the code. It's too hard to get
anyone to agree on what simple means anyway. Me, I prefer Hickey's "Simple
Made Easy" for that, but not everyone agrees.

ETA: I guess what I would say is: would you prefer to start with something
simpler and build complexity appropriate to the problem domain out of simple,
but sound ideas? Or would you prefer to start with a set of inherently complex
primitives and build something _else_ complex on top of that? It's subjective,
but I've probably leaked my bias in the phrasing.

~~~
chwahoo
I don't think his point is as broad as you're claiming. He's saying that
golang application code is complex due to (for example) lack of generics
because the language lacks that complexity.

------
wyager
Jesus, I hope not.

Go now is like Java in 1997. A mediocre language with lots of corporate
support and a big standard library. It's popular in the developer crowd right
now because it's A)simple B)has a good standard library and C)getting support
(in the forms of tools, tutorials, etc.) is easy.

We shouldn't let those things be the deciding factors in choosing what
language to stick with over the next ten or twenty years. That's what we did
with Java, and even though we're on revision 8, people are still (rightfully)
complaining about many of the same flaws that are still present 20 years
later.

As Java aged, developers realized that they didn't actually _want_ the type of
language that Java started out as, so over time, Java has accumulated features
like lambdas, generic programming, etc., but because the language wasn't
designed with it in the first place, it's all sub-optimal cruft.

Go has a lot of the same problems now. No generic support (What language
designer in 2014 builds something that idiomatically requires casting to the
top type? That was _precisely_ a huge problem for Java; Java (sort of) fixed
this by adding Generics in 2004), a mediocre type system (which gets
completely ignored pretty frequently anyway; see the previous issue),
inflexible (you can't extend important built-ins like range or make()), and
with none of the interesting features that programming languages have gotten
good at in the last few decades (pattern matching, immutability, null/nil-free
programming, etc.).

I really hope that developers can see past the hollow promises of corporate
support and a strong standard library and wait for a _language_ that is
actually good in and of itself, and not just because there are so many
developers propping it up. There are a number of very well-designed languages
on the horizon. The one closest to Go may be Rust, which has excellent
features like ML-style generic programming, pattern matching, an almost-
hindley-milner type system, strong support for immutable and functional
programming, etc.

~~~
mseepgood
> No generic support (What language designer in 2014 builds > something that
> idiomatically requires casting to the top > type? That was precisely a huge
> problem for Java

Even a seasoned Haskell programmer like Erik Meijer has a more nuanced view on
the topic than you:
[https://www.youtube.com/watch?v=on5DeUyWDqI&t=23m40s](https://www.youtube.com/watch?v=on5DeUyWDqI&t=23m40s)

> you can't extend important built-ins like range or make()

This was a deliberate design decision. When the Go team was asked about what
they like about Go one answer was:

"It's very simple to understand, and the code that I read on the page is the
code that is executed.

When I iterate over a slice, there's not some chance that there's an iterator
implementation that fetches a file from a web server in Romania and serves me
some JSON or something.

Instead, the language is very deliberately simple and contained so that it's
very easy to reason about code that you're reading."
[https://www.youtube.com/watch?v=sln-
gJaURzk](https://www.youtube.com/watch?v=sln-gJaURzk)

~~~
wyager
>Erik Meijer has a more nuanced view on the topic than you

I'd rather not watch a 40 minute video. Care to summarize?

>"and the code that I read on the page is the code that is executed... the
language is very deliberately simple and contained"

This is a dumb argument. The same thing can be said about assembly, and in
fact this property doesn't hold true once you introduce abstraction through
functions.

All well-written code is easy to read, and most poorly-written code is hard to
read. Go does not change that.

~~~
mseepgood
> I'd rather not watch a 40 minute video. Care to summarize?

I linked to the exact time where he starts to share his thoughts about
generics.

------
manishsharan
Does the OP even know what made COBOL successful and useful ? Or for that
matter , does the OP even know a Cobol programmer ? I suspect the answer is no
and yet his blog is being discussed on HN front page. Cobol predates the RDBMS
and made a lot of sense when writing structured data to flat file systems.
Cobol language and cobol programmers never aspired to do a general purpose
computing. Back in those days, the scientists wrote their programs in fortran
and businesses wrote their code in cobol and most computing was done on IBM
systems. Then came minicomputers with DBASE. And so on. If you are a canadian,
I can guarantee you that most of your RRSP backend data processing is still
being done on Cobol ; I had a bruising experience when a newly minted CIO
decided to do away with all cobol and replace it with modern langauges ( c#
etc.) Long story short, the CIO moved on to another unfortunate company ,
millions of dollars wasted and the cobol code is still working.

And now, get off my lawn !

~~~
jeremiep
New programmers who don't want to learn old technologies to maintain existing
code bases will most likely want to replace it with something they know. It's
almost always a very bad idea.

All of these "x is the future" articles show a huge lack of perspective on
what made languages successful in the first place and why they're still in use
today.

~~~
Karunamon
Often the "why they're still in use today" when describing legacy tech can be
described as a combination of fear of change, lack of resources, and technical
debt (the result of both of those things).

Not because it was or is the best tool, not because it's the most efficient or
the most performant or most readable, but because simple mundane politics and
FUD.

~~~
jeremiep
There's also the cost of upgrading a code base to a more modern language vs
the benefits of working in the new language.

Most legacy projects I've worked with were not that hard and costly to
maintain. Rewriting these code bases would definitely cost more than what
would be saved afterwards.

------
chimeracoder
COBOL is like bedbugs. Nobody _likes_ COBOL; the reason it sticks around is
because it's damn near impossible to get rid of.

COBOL is very hard to migrate out of production because it's incredibly
difficult to translate COBOL code to other languages. Everyone writes their
own version of their COBOL, and even translating one COBOL program to another
COBOL programmer's "dialect" is non-trivial. COBOL provides all the power of
LISP macros, except with none of the elegance - it's very hideous once you
peel back the layers.

On the other hand, it's very easy to translate Go to/from other C-family
languages. Indeed, there was a blog post recently on here about a company that
translated their entire Python codebase line-for-line into Go. The Go team is
even working on an automatic translator to translate the current gc compiler
codebase (written in C) into Go.

I've used Go as my primary language for almost two years now. I wouldn't say I
"love" Go - I love the things it lets me do. If Go is going to achieve the
same level of dominance that Java has, and the same level of persistence that
COBOL has, it's not going to be because it's got the ultimate form of lock-in
(legacy code) - it's going to be because it continues to let people do
powerful things very simply.

~~~
3am
Funny you mention it... almost replied to the post earlier saying that if I
were to bet my career on a single language it would certainly be COBOL. Not
glamorous, but it runs critical infrastructure and schools aren't exactly
pumping out mainframe programmers.

That said, I have not and would not recommend betting on a single language.
Being polyglot has its own advantages.

edit: any ideas for a first project with Go? Any place it's particularly well
suited for?

edit: I re-emphasize my 2nd paragraph, "I have not and would not recommend
betting on a single language"

~~~
TheCoelacanth
I don't think that's a very good bet. There is still a lot of COBOL sticking
around, but there are essentially zero new COBOL projects being started while
there are a non-zero number of COBOL projects being replaced with other
languages, so COBOL use is ultimately trending downward. You are essentially
betting that COBOL developers die out faster than COBOL itself does.

------
mark_l_watson
Well, I believe that developers should be able to choose their own tools
although work requirements can understandably override personal choices.

I used to be a 'Java guy' (for many years I was the number one Google search
result for "Java consultant") but I migrated to Ruby out of personal
preference, then to Clojure because I got a lot of work offers using Clojure,
and now I am struggling to learn Haskell. That said, the bits of Java
programming that I have been doing lately (mostly Java 8 with streams and
lambdas) has been a lot of fun.

Bottom line IMHO is that choice of programming language is not that important.
More important is having a good fit with existing code bases, lots of trained
developers, good libraries and frameworks, and adequate performance.

------
carsongross
I'll say it again:

If java was brainf&%k and we still got the JVM out of it, it would all be
worth it. And I think there's a good chance that Java's successor runs on it.

~~~
pauldix
Totally agree that the JVM is super powerful. I think it's Java's greatest
strength. However, I don't see any current JVM language as a potential
replacement. Scala is too complex. Clojure, while wonderful, is Lisp and no
one has been able to make that popular for 5 decades (not even pg).

~~~
carsongross
Oh, no worries, I fixed that for you:

[http://gosu-lang.github.io/](http://gosu-lang.github.io/)

;)

~~~
mark_l_watson
Wow, that is cool. How is the runtime performance?

~~~
carsongross
Not terrible, depending on what you are doing: it compiles down to the obvious
bytecode for most statements/expressions.

If you start using the open type system, you end up going through some
somewhat slow reflective code to make everything work, and that can be slower.

The biggest problems with Gosu right now are:

\- Startup time \- Tools support

We are working on both of those and hope to have better tools out over the
summer.

------
dyeje
"My prediction is much stronger than saying Go will be as popular as Ruby,
Python, or Node."

Was anybody else thrown off by this? I thought it was weird to throw Node in
there considering Go, Ruby, and Python are languages.

~~~
rubiquity
Most people say Node as to not confuse client-side JavaScript. e.g: Saying Go
will be as popular as JavaScript would be unreasonable, saying Go will be as
popular as JavaScript on the server is reasonable.

~~~
dyeje
Ah, thank you. That definitely makes more sense.

------
brl
> Some developers have noted Go’s lack of features or a few other things: no
> exceptions, nils instead of options, inability to specify dependency
> versions, mark and sweep GC, no macros, no generics.

Not having exceptions is one thing and probably a valid opinion, but
specifying library dependencies as whatever today's HEAD commit is on a GitHub
project always seemed to me incompatible with writing reliable software. Until
reading this article (and learning about godep) I thought that I must be
misunderstanding how dependencies are managed in Go, because how could that
possibly work? In practice how have people been dealing with this before tools
like godep?

------
smrtinsert
Does anyone know any good platforms for mobile cobol development?

------
mseepgood
Do never ever use Google trends to compare programming languages. The names of
programming languages have different meanings in different contexts.

------
iadapter
I wonder if this is a response to yesterdays post about modern Java [1].
Timing seems too close to be a coincidence.

On the other hand it does not address the points of the other post so I'm
probably wrong.

[1] [http://blog.paralleluniverse.co/2014/05/01/modern-
java/#comm...](http://blog.paralleluniverse.co/2014/05/01/modern-
java/#comment-1366371487)

------
adrianlmm
I beg to differ, not that Go doesn't have its place, but I think they can't
even be compared.

------
0xdeadbeefbabe
I don't understand these "rah rah rah Go!" posts. If it's so great then take
off your swami hat and do something with it [0].

[0] [https://www.docker.io/](https://www.docker.io/)

------
Tloewald
So... Go is the next COBOL?

~~~
coldcode
I'm still waiting on a merger of the two - GOBOL.

------
cliveowen
If anything Go is the successor of C, Java has nothing to do with Go.

~~~
pohl
Go has a historical connection to C because Pike and Thompson. However, Go
can't be the successor to C, because C is a systems language that can be used
without garbage collection. There's no way that Go can follow in C's
footsteps.

Go is most likely to be used where Java dominates today: web application
servers.

If the author of the current post has anything going for him, it's the fact
that the wave of mass adoption in technology always chooses the lesser
technology over the better alternatives of the time. So I think Go has a
bright future.

~~~
pjmlp
> There's no way that Go can follow in C's footsteps.

I am not a big fan of Go, but looking at Oberon based OSs used during the 90's
at Swiss Federal Institute of Technology in Zurich, it could be used.

Granted, maybe some extra features like direct compiler support for untraced
pointers and full processor mapping in the unsafe package would be welcome,
but the original Oberon could survive without them. By making a set of
assembly routines available as kernel package.

Which is no different than the assembly required by C to interact with the
hardware.

------
LaSombra
I still don't understand the hate of Java. No language is perfect. No OS is
perfect. No system is perfect. Some like, some don't.

And I agree with carsongross, the JVM is worth all the hate thrown at it and
it still active developed and I think it will go nowhere.

------
mda
I don't think Go is a replacement for Java.

------
slashnull
Go is the new cobol

------
puppetmaster3
Or D.

