

Is Java the Cobol of tomorrow and Go the Java of the future? - minaandrawos
http://influxdb.com/blog/2014/04/30/java-is-the-cobol-of-my-generation-and-go-is-its-successor.html

======
bad_user
The argument on looking at Go's trend in isolation is a really weak one. Let's
also look at Clojure in isolation:
[https://www.google.com/trends/explore#q=clojure](https://www.google.com/trends/explore#q=clojure)
\- and oh look, Clojure runs on the JVM.

> _If I were a developer getting started today, I’d make a career bet on Go_

Advice on picking languages as career bets are especially weak. In my
experience, careers are being built on being able to get stuff done and in the
long list of things that a developer has to learn to get stuff done, the
language itself is very uninteresting considering everything else combined.
Personally it takes me 2-3 weeks to become functional in any new programming
language, I've worked with half a dozen thus far in production and I played
with another dozen in my free time. The language itself is like a drop in an
ocean, compared to more fundamental knowledge that makes one productive, like
math, algorithms, concurrency and parallelism, hardware, usability, domain
specific knowledge, libraries, frameworks, being able to interact with a
community, etc...

> _Go is a simple language by design. You can read the spec and other
> materials on the Golang website and start being productive in a single day_

Simplicity in the language doesn't translate to simplicity in the solutions
that you're building. This is a fundamental divide, since often people are
mistaking simplicity for easy, for being familiar. It's not in the original
sense of the word - simplicity is the opposite of complexity, which means
interwoven or entangled and in the context of software it means building
reusable / modular components, that do one thing well and that can be stacked
/ connected together to build bigger solutions and to keep complexity
manageable.

Go is in fact anti-simplicity. Its lack of generics, given its static typing,
is a really good example of a design fuck-up, since for building reusable
higher-level abstractions, one really, really needs generics and this is an
objective fact - note that we aren't talking about dynamic languages here,
which don't care about static typing or for being close to the metal. There's
no point in denying that and Go will end up like both Java and C++, both of
which didn't have generics in the beginning - and so it will end up with a
half-baked solution with lots of corner cases and that people will hate, until
the next language comes along also lacking generics, because "simplicity",
repeating the cycle ad-nauseam.

In fact a programming language is supposed to be extensible, because both in
natural speech and in our systems, we are extending our language all the time
to manage complexity. If this gives birth to features that are harder to
learn, that's a freaking drop in the ocean compared to all the shit that we
must do when implementing complex business logic. I recommend watching Guy
Steele's "Growing a Language" presentation, it's very enlightening:
[https://www.youtube.com/watch?v=_ahvzDzKdB0](https://www.youtube.com/watch?v=_ahvzDzKdB0)

But then again, extensible languages and higher-level abstractions are raising
the bar to entry, which often goes against the other generally accepted
solution for managing complexity, which is to hire more average Joes that can
sit in a chair and type.

> _Simple languages are easier to learn._

 _Familiar_ languages are easier to learn. There, fixed the typo. And if
you're only learning familiar stuff, then you're not learning anything new ;-)

I keep going back to Alan Kay's quote which will be relevant for a long, long
time: "Most software today is very much like an Egyptian pyramid with millions
of bricks piled on top of each other, with no structural integrity, but just
done by brute force and thousands of slaves."

~~~
Artemis2
I love Go because it fits in my head. There are tons of applications for which
Go won't be the best fit, but Go is fantastic for some others.

~~~
swah
Everyone loves that. But most people also want to write algorithms that work
on different kinds of collections.

I think its just a matter of Go arriving at a good proposal for generics.

------
threeseed
Do I believe Java will be the next COBOL. Absolutely. Do I believe Go will be
the next Java. Absolutely not.

1) It ignores where Java is being used. It is dominant within the enterprise.
Features like a single binary, lack of a reverse proxy or taking advantage of
multiple cores aren't at all compelling. We have dedicated ops teams happy to
automate deployments, hardware load balancers and are rarely doing anything
CPU intensive.

2) It ignores language trends. Functional programming is what is hot right
with Scala and Clojure being what most enterprises are choosing to adopt for
the next big project. Why ? Because they can leverage all their existing Java
libraries/practices but without the boilerplate and language overhead of Java.

3) It ignores architectural trends. Go's concurrency approaches are nice but
aren't that special and again aren't that useful in most cases. Unless you are
someone like Cloudflare it is far easier to just horizontally scale your app
servers across seperate instances. It's more expensive but hardly worth
deciding your platform over.

~~~
thescrewdriver
We've been using Scala for a while now. It's a major step-up from Java in
terms of sheer programming enjoyment (contrary to what the criticism parrots
who don't actually use it would have you believe). Java is still very widely
used, but most don't use it by choice anymore but rather because it's the
default or what the existing code is written in. Go is a non-starter for us
due to a lack of support for existing Java libs, and isn't all that
interesting compared to the alternatives.

------
julianpye
Maybe it makes sense to understand why Java is where it is today. It is not
because programmers thought it was the best technology, but because of
politics. At the time of introduction, Microsoft held a clear platform
monopoly and the key skills in demand were C++/MFC and the like. Sun was the
underdog and Java was positioned to become a counterweight to this monopoly
and many companies supported it heavily just to provide a balance. From a
developer standpoint Go is superior, but would the same political support
happen for a Google-invented language?

~~~
kitd
You paint Java as the child of corporate scheming (maybe unintentionally), but
it was more nuanced than that. Java's success was due to several trends coming
to together at the same time.

The bulk of serious programming in the early 1990s was in C or C++. Cross-
platform C libraries in those days were either abysses of mind-blowing
complexity or just pure snake-oil.

Since everything MS did was Windows, anything that came along to provide a
good development experience (which Java did in comparison in those days) AND
be cross-platform (one of its founding principles) couldn't help but be
successful.

So politics was certainly not the only factor.

~~~
gutnor
Just adding up to those points.

Compiling at the time was a problem. Adding a new library could mean hours of
digging up to find out why you can't even link the damn thing in your project
- if that's even possible. That's before even talking about cross-platform.

Java was also a modern OO language, safer to use than C++ and with everything
you needed right there in the JDK, all of that backed with solid documentation
( internet was not what it is now, if you were the lucky few with access at
all )

In particular, java had a great easy approach to threading out of the box,
working everywhere.

------
adamors
> Go’s performance isn’t a big win for Java developers since they’re already
> doing pretty well. But for us dynamic language refugees, Go’s performance is
> liberating. No dealing with reverse proxies to send things to multiple
> processes. Real threading and the ability to take advantage of every core.
> Async IO, but without all the callbacks.

Jesus, are people really this excited about features that existed for at least
15 years in other languages?

This one language for everything mentality is ushering in a huge NIH cycle.

~~~
viraptor
Near-C performance, static/strong types, async io without callbacks, well
integrated multithreading... maybe I'm missing something obvious, but which
(not obscure) 15-yo language provides this set of features?

~~~
spion
Performance - not really that near to C

Static types - of the worst kind that get in the way of creating any
significant abstractions (no parametric polymorphism or generics) and don't
provide much safety (no nil safety). For a new modern language, this is just
weird.

Well integrated multithreading - yes. 40-year-old error handling strategy:
also yes.

Haskell, Scala, F#, C# are all much better choices that I think fulfill all
your criteria (Well, one might argue that functional languages are obscure,
but that's increasingly not the case these days)

I find the popularity of Go rather depressing. If Go becomes the next Java,
the inventors of C would set the programming world decades back in the past
for the _second_ time.

~~~
spion
in reply to cookiemonster11, the wrong part is that it doesn't work well.

When you asked for exceptions you actually wanted an Either type, which means
the function either return a result or an error ( _not_ both).

You also want something that propagates errors automatically (the monadic
bind) in case you don't want to check every result.

An Either type lets you get the best of both worlds. It lets you model exactly
whether an error can or cannot happen (unlike exceptions that are not
optional). It lets you check every return value directly via pattern matching
(similarly to Go) but also, the compiler will warn you if you "forget" to
handle the error case. Finally, the bind operator lets you chain operations in
a way that only executes in case of no errors, plus attach a single error
handler at the end to handle any of the errors (in a manner similar to
exceptions)

So yeah, there are better solutions today.

~~~
TheLoneWolfling
How I wish nullable types worked in C-like languages:

You cannot dereference a nullable value normally. However, inside a (x !=
null) block, or rather anywhere the compiler can infer that the value cannot
be null, it automagicially turns into a non-nullable type. And there's the
null-safe dereference operator (.? or similar) that returns null in case the
first value is null.

Similarly with casting - if you have an if block with an instanceof check,
within that block the variable has the type given by the check.

You still have to have a runtime-checked NPE in some cases (in case of
hotswapping, casting to non-nullable types (which should be allowed but throws
a _checked_ excption), etc), but mostly this avoids the issues with NPEs, I
think.

I agree that pattern matching can be powerful, and underutilized in most
language designs.

Alternatively, I've been growing more in favor of the idea of not having null
at all in the base language - if you actually need it it's relatively easy to
implement if you have boolean algebra on types (Nullable<x> being equivalent
to Either<x, Null>, where Null is an enumerated type with one value, null.
Like what you said). And that way it's explicit, and people are more likely to
use a better (read: more informative) exception type). Null ends up being an
exception with no additional information, which can work in some cases, but
often you want additional information. Even just "NotInitialized" or something
like that is often better.

------
mseebach
I think the author is mostly right, but he fails to recognize that the
difference between COBOL and Java is much, much bigger than the difference
between Java and Go. Right now, I think that the full Java ecosystem is
"better" (to the extend that can be meaningfully measured) than the equivalent
in Go, to an extend COBOL probably never was to Java. Obviously that gap will
close, and fast, but it's an example of just how relatively close those two
languages are.

And then this:

> Any developer that cares about their demand in the market (and salary
> potential) and any employer wishing to hire should factor language life-
> cycle into their language choice. I’m sure there are still COBOL programmers
> out there, but I wouldn’t want to be one of them if I was looking for a job
> and I wouldn’t want to be an employer trying to find a competent COBOL
> programmer or anyone that wanted to learn.

Few things scream "name your salary" in this business like being a competent
and willing COBOL programmer. I'm not sure that learning COBOL from scratch is
a viable career path these days (there's a chicken-and-egg problem, you're not
going to become great a any language without actually working in it, and
nobody is going to let you work in it before you're pretty great), but I WOULD
"want to be one of them if I was looking for a job".

~~~
NateDad
> Few things scream "name your salary" in this business like being a competent
> and willing COBOL programmer.

Uhh.... if you can find someone looking for a COBOL programmer in your area,
perhaps. But the number of COBOL jobs out there is pretty tiny. Anyone with a
COBOL system is looking frantically for a way to decommission it. That's not
the kind of project I want to base my family's income on.

~~~
roel_v
"But the number of COBOL jobs out there is pretty tiny."

No it's not. They're not advertised on monster.com, true. It's used in niche
markets (well, if you call e.g. banking a niche market) and those systems
aren't going to be 'decommisioned' anytime soon. There are literally _dozens_
of just vendors of Cobol compilers / environments / toolkits in business
_today_. Like the GP said, I'm not claiming going into Cobol as a 21 year old
is a wise career move. But Cobol consultants certainly bill a multiple of what
Ruby, Go or even Java consultants bill here in Western Europe.

------
foononomepls
Dream on. You cannot predict the future from the presents past. Go is hyped a
lot but at the end it's not that much needed as Google wants it to. Java is
easy to learn, very fast and hast tons of frameworks and documentation.

For other stuff there is still c++ and python with QT and if for some folks
ofc there are ruby, perl, Haskell and so on.

Also, and this is an important point go was invented by Google and Google is
not the cool hip company it used to be it is. Ow the complete opposite and
part of orwells vision...

~~~
tragic
> You cannot predict the future from the presents past.

Every time you open your lungs in the expectation that they will fill with 20%
oxygen and nothing toxic, you are 'predicting the future from the presents
past'. The past is the only basis for forming expectations about the future,
even if you're dealing with smaller probabilities, such as the rise and fall
of programming languages.

> Also, and this is an important point go was invented by Google and Google is
> not the cool hip company it used to be it is. Ow the complete opposite and
> part of orwells vision...

Really? Go is obviously very trendy right now, and Angular - in my anecdotal
experience - is on top in the front-end wars. Google is coming up with plenty
trendy technology at the moment. Unless the Go compiler's phoning home, the
Orwell stuff is just laughably irrelevant, and will be treated as such by the
bulk of developers.

I have no idea if Go is destined for really big things. But the fact that it's
a small ecosystem now doesn't matter - Java was pretty small back in '95\. It
depends on whether it allows developers to solve the next decade of
engineering problems in a satisfying way, relative to its competitors. We
shall see.

~~~
aikah
> Every time you open your lungs in the expectation that they will fill with
> 20% oxygen and nothing toxic, you are 'predicting the future from the
> presents past'.

The fact that one is breathing right now doesnt mean one will still be
breathing 5 minutes from now. You can predict the future.You can maximize
chances something happen,you just cant be sure 100%.

Yet chances are that :

\- Business arent going to drop the JVM "en masse" for Go,just because Go is
cool. And frankly , from a syntax perspective , Go is not that great. It has
almost no functional features, and a very weak OO model.

> I have no idea if Go is destined for really big things. But the fact that
> it's a small ecosystem now doesn't matter - Java was pretty small back in
> '95.

Nothing like what the Java ecosystem is today existed before Java, that's a
huge difference. And the fact that the JVM runs multiple languages makes it
unlikely it will be obsolete,ever.

Concurrency backed in a language is cool,but not necessary. concurrency can
easily be a lib or a framework.

I've been in enterprise long enough to know that enterprise likes boring
enterprise languages for most part(java) and glue languages (scripting
languages) because deadlines ... while Go might have been great at replacing
C,which it doesnt, I still think there is some room for a safer C for system
programming. I dont think Go features are interesting enough for entreprise
solutions. There is nothing Go can do that the JVM cant.

------
jhh
I don't see why the future wouldn't be polyglot, in the sense that there isn't
one language as dominant as Java has been.

There is now much better language interop than in the past, e. g looking at C
interop in Julia and Java interop in Clojure and other JVM languages.

Using HTTP on distributed queues on less unreliable, faster networks than in
the past makes building distributed systems using many different languages
easier (SOA, Microservices).

On the clientside there are strong proprietary ecosystems which dictate the
use of a specific language (more or less), Android, Windows (C#), Apple (Obj.
C, Swift).

Therefore I think it is plausible to assume that no single language will (have
to) become as dominant as Java has been

------
masklinn
If Java is the Cobol of tomorrow and Go is the Java of tomorrow, doesn't that
make Go the Cobol of the future (after tomorrow)?

~~~
threeseed
Or it may go down as another part of the Google's failed projects list
alongside Google+, Glass, Reader, Wave etc.

~~~
mseebach
Unlike any of those projects, Go is fully developed under a liberal FOSS
license, so if Google looses interest (and Go is actually good), development
can be picked up by the community.

------
wheaties
Same could be said for Idris, Haskell, Scala, Clojure, Node.is, etc. Nothing
against Go, I like it, it's just one more language to choose from.

------
johan_larson
I had a chance to do a bit of Go work while at Google. Coming from the
complexities of C++/STL, the simplicity was a blessed relief.

Unfortunately, I don't think that simplicity will last. Other popular
languages like the C family and Java were pretty simple when they started out.
But C became C++ became C++ with STL, with all the attendant complexities.
Similarly, early Java was a pretty clean language, but they added generics and
various libraries, to say nothing of the swamp of a tooling ecosystem built
around the language. "Your experience is in Hyperstruts? Sorry pal, we only
work in JToolkitMVC."

If Go becomes a big success, I predict it will walk the same path, gaining
complexity either in the language itself or in the surrounding libraries or
frameworks. Simplicity is a sign of immaturity, and it will not last.

------
knocte
I won't try Go until it implements generics and changes its hide-error-by-
default behaviour.

~~~
MereInterest
Completely agree on the second part. It feels utterly silly that they refuse
to use exceptions on the basis that errors should be explicit, but then allow
for errors to be silently ignored just by not assigning them to variables.

~~~
NateDad
In practice this is not a problem that is encountered pretty much ever. If you
are afraid of it, run errcheck[1] on your code, and it'll tell you if you've
missed anything.

[1] [https://github.com/kisielk/errcheck](https://github.com/kisielk/errcheck)

~~~
MereInterest
If you don't mind me asking, what is it that keeps it from coming up? I
understand that the multiple return values help, since then you don't need to
go with the clunky C-style of passing in pointers that will be used as output.

Error codes always feel like they rely too much on everybody deliberately
following good coding practice, since the default is to ignore the error code.
I prefer using exceptions, because then the error can't be ignored by default,
and must be explicitly silenced if it is not desired. Then again, that is a
large python influence on me.

~~~
bad_user
I also think the arguments against using exceptions are flawed. For example
it's a common pattern to use a supervisor that catches exceptions and
depending on context and severity, to log the errors, to restart the guilty
component, to send an error report, to fallback to something else, to crash
the whole process and so on.

The idea being that unexpected errors happen and you need to react to them in
some way, preferably without relying on the developer to do something for
everything potentially error prone that he does, because we can't anticipate
everything bad that can happen, yet in spite of this, we can make the system
resilient to errors.

------
joshuaellinger
I am a rare (for Hacker News) C# dev and I've just been toying around with Go.
There is stuff to like but my feeling is that the biggest weakness of the
language is that it is designed to solve the problems that Google has
(surprise), which is only a fraction of the problems that the world has.

It is a scalpel verses a swiss-army knife. The question is which do you need.

If you are doing Internet-related things (server-side plumbing and apps, not
search), it looks like a pretty darn good fit. It naturally leads you build up
a set of small start tools that you combine to build a larger service. The
channels metaphor is a really nice way to deal with concurrency.

If you are building anything else (desktop, LOB apps, DB front-ends, mathy
stuff, etc.), it looks a bit limited. For example, it doesn't have a modulus
operator. Not a big deal but it shows that the language designers are more
concerned about supporting their target domain than supplanting Java, much
less C#.

Really, the thing that I fine the most troublesome is this feeling that the
designers of the language have such a focused vision that it will hinder the
growth in the future but, for now, it needs that to keep from becoming
overgrown like C# is.

~~~
touristtam
Modulus Operator? Like the following: [http://msdn.microsoft.com/en-
us/library/0w4e0fzs.aspx](http://msdn.microsoft.com/en-
us/library/0w4e0fzs.aspx)?

If this is the case, maybe you should check the doc:
[http://golang.org/ref/spec#Arithmetic_operators](http://golang.org/ref/spec#Arithmetic_operators)

try this:
[http://play.golang.org/p/WA0vX7zmNb](http://play.golang.org/p/WA0vX7zmNb)

I'll leave a copy of the code so you can try it locally as well (and in case
the link to play.golang.org breaks)

package main

import "fmt"

func main() { a := 47 b := 6 c := a % b fmt.Println("input: ", a, b)
fmt.Println("output: ", c) }

[edit]: someone beat me to it :/

------
cryptos
I've spend some time with Go, but never felt overly productive with it. As
someone else in this discussion mentioned a simple language doesn't mean that
solutions in this language are simple! Look at what real problems you have to
solve in you applications, and then tell me that generics in a statically
typed language are not important! Go applications are full of useless code to
circumvent this restriction. Want to make something immutable? Not very
convenient in Go, very easy in most other (statically typed) languages.

While Scala has a complex type system it is a simple language at it's heart.
For example try-catch is not a special language feature but another
application of the powerful pattern matching. It will take a little longer to
learn Scala compared to Java, but you get a much better tool to solve the most
problems. And you get all the libraries and the tools (any Go IDE on the level
of IntelliJ or NetBeans?) of the big Java ecosystem.

But even if you don't want to use Scala, you could be more productive with
Java than with Go. From a Java perspective Go has not much to offer, not even
fancy concurrency.

------
th3iedkid
am very happy the author is happy with go.

>>Deploying Go code to production is as simple as copying a single binary file
up to a server and running it. No reverse proxies, no dependencies to install
on the target server, no class paths. Just copy the binary and run.

This fairly depends size of system we are discussing.

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

languages such as Java too grew out from such weaknesses and are still growing

>>If I were a developer getting started today, I’d make a career bet on Go.

Fairly good but it depends on what market attracts you.For e.g. if you were to
target financial markets with big responsive systems , i doubt if they have
loads of Go lang hires vs the same on say Java hires.But if we were to target
a different market,it would change too!

------
stefanve
I think a very big difference between Cobol and Java/.NET is that it is being
used in far more places (mobile,desktop,enterprise) and that the runtime is
open for other languages (F#,Scala,Python, Ruby etc) because of this the main
languages are constantly evolving as well and lots of libs and platforms are
written in the main languages, maybe something like Scala will replace Java or
Java will become more like Scala but I guess it would not be so easy to
replace the the JVM or .NET as it is to replace a (almost) single domain
language

------
seanhandley
One thing to bear in mind is that "Go" isn't very easily googleable so that
graph could well be unreflective of genuine interest.

~~~
owlish
Most of the time, you can just Google "golang" instead.

------
miralabs
Im thinking what will happen is there will be a version of java (along with
the frameworks and technologies ) that will become Cobol and new version of
Java will move on and improve. I dont think it will be the next Cobol. When
cobol was around, not so many were using it and technology is limited.Today,
Java is just everywhere.

------
dragonwriter
> Is Java the Cobol of tomorrow and Go the Java of the future?

If so, does that make Go the COBOL of the day after tomorrow?

------
tdsamardzhiev
No, Go is the Go of today and Java is the Java of today. I do belive Go has
future, though.

------
tobias__
I imagine the interest/time graph is strongly influenced by users installing
the JRE

------
alisnic
%s/Go/Elixir

------
Grue3
Betteridge's law of headlines says no.

~~~
higherpurpose
Except the original title didn't use a question. The submitter did.

