Live data from Hacker News

Java is the COBOL of my generation and Go is its successor

influxdb.org

11–20 of 96 posts

Re: Java is the COBOL of my generation and Go is its successor

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

Re: Java is the COBOL of my generation and Go is its successor

#12
post #6

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.

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

Oh, no worries, I fixed that for you:

http://gosu-lang.github.io/

;)

Re: Java is the COBOL of my generation and Go is its successor

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

Re: Java is the COBOL of my generation and Go is its successor

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

Re: Java is the COBOL of my generation and Go is its successor

#16
post #6

Earlier quoted context omitted.

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

Oh, no worries, I fixed that for you: http://gosu-lang.github.io/ ;)

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

Re: Java is the COBOL of my generation and Go is its successor

#18

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

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.

Re: Java is the COBOL of my generation and Go is its successor

#19

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 pow…

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"

Re: Java is the COBOL of my generation and Go is its successor

#20
post #13

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 y…

> A mediocre language with lots of corporate support

It's very disingenuous to compare the level of corporate support that Sun provided Java and the level of corporate "support" (involvement) that Google provides Go.

The Go project began at Google to solve the sorts of challenges that Google was having (architecting and managing large servers), and several of the original members of the Go team work at Google, but the Go team has gone out of their way to ensure that Google (the corporation) doesn't control Go development.

Post reply on HN