9 ms·

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

50 points by jlhamilton 12y ago

adrianlmm 12y ago
I beg to differ, not that Go doesn't have its place, but I think they can't even be compared.
puppetmaster3 12y ago
Or D.
carsongross 12y ago
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 12y ago
  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).
  - LaSombra 12y ago
    What about Groovy?
    - deleted 12y ago
      [deleted]
    - kreddor 12y ago
      Good question. All I know is that it's used for Gradle and Grails. Some people I know view it more as a scripting language...
      - vorg 12y ago
        Groovy doesn't have much significant use anymore. Someone's gaming the stats to make it look more popular, though. At https://bintray.com/groovy/maven/groovy/view/statistics https://bintray.com/groovy/maven/groovy/view/statistics you'll see 190k downloads in the last 30 days, click on country and you'll see 162k of them from a proxy server in China, and only 8300 direct from the US.
  - carsongross 12y ago
    Oh, no worries, I fixed that for you: http://gosu-lang.github.io/ http://gosu-lang.github.io/ ;)
    - mark_l_watson 12y ago
      Wow, that is cool. How is the runtime performance?
      - carsongross 12y ago
        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.
    - gagege 12y ago
      That looks amazingly similar to Haxe, which is not tied to the JVM but can compile to optimized Java. http://haxe.org http://haxe.org
  - mike_hearn 12y ago
    I'm looking a lot at Kotlin. It's not mature yet: JetBrains will start using it this summer for their own projects and I expect it to firm up a lot then. The nice thing about Kotlin is almost perfect compatibility with Java, and an auto-translator that doesn't suck. So you can take an existing Java codebase and auto translate class by class, maintaining compilability the whole time. Also the standard library is mostly a set of extensions to the JDK so your existing library knowledge ports across, except you keep finding useful goodies sprinkled all over the place. Feature-wise Kotlin has things that I feel would help me write fewer bugs: it has null-safety encoded into the type system, smart casts, extension methods, some good functional programming support, powerful properties and so on. There are features it lacks too, but I hope JetBrains will continue to push it forward for many years.
    - pjmlp 12y ago
      They already use it. There was a Kotlin talk where they mentioned some plugins are now being written in it.
mda 12y ago
I don't think Go is a replacement for Java.
deleted 12y ago
[deleted]
LaSombra 12y ago
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.
cliveowen 12y ago
If anything Go is the successor of C, Java has nothing to do with Go.
- pohl 12y ago
  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 12y ago
    > 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.
chimeracoder 12y ago
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 12y ago
  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 12y ago
    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.
wyager 12y ago
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.
- chimeracoder 12y ago
  > 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.
smrtinsert 12y ago
Does anyone know any good platforms for mobile cobol development?
mark_l_watson 12y ago
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.
Tloewald 12y ago
So... Go is the next COBOL?
- coldcode 12y ago
  I'm still waiting on a merger of the two - GOBOL.
deleted 12y ago
[deleted]
noelwelsh 12y ago
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 12y ago
  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.
  - pessimizer 12y ago
    Readability is in the eye of the reader.
manishsharan 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
mseepgood 12y ago
Do never ever use Google trends to compare programming languages. The names of programming languages have different meanings in different contexts.
dyeje 12y ago
"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 12y ago
  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 12y ago
    Ah, thank you. That definitely makes more sense.
- graetzer 12y ago
  I think it fits in this context. JavaScript alone has no standard library or execution environment. Unlike the other languages listed there.
blahbl4hblahtoo 12y ago
Troll much?
iadapter 12y ago
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/#comment-1366371487 http://blog.paralleluniverse.co/2014/05/01/modern-java/#comm...
0xdeadbeefbabe 12y ago
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/
brl 12y ago
> 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?
slashnull 12y ago
Go is the new cobol

50 points by jlhamilton 12y ago

adrianlmm 12y ago

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

puppetmaster3 12y ago

Or D.

carsongross 12y ago

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 12y ago
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).
- LaSombra 12y ago
  What about Groovy?
  - deleted 12y ago
    [deleted]
  - kreddor 12y ago
    Good question. All I know is that it's used for Gradle and Grails. Some people I know view it more as a scripting language...
    - vorg 12y ago
      Groovy doesn't have much significant use anymore. Someone's gaming the stats to make it look more popular, though. At https://bintray.com/groovy/maven/groovy/view/statistics https://bintray.com/groovy/maven/groovy/view/statistics you'll see 190k downloads in the last 30 days, click on country and you'll see 162k of them from a proxy server in China, and only 8300 direct from the US.
- carsongross 12y ago
  Oh, no worries, I fixed that for you: http://gosu-lang.github.io/ http://gosu-lang.github.io/ ;)
  - mark_l_watson 12y ago
    Wow, that is cool. How is the runtime performance?
    - carsongross 12y ago
      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.
  - gagege 12y ago
    That looks amazingly similar to Haxe, which is not tied to the JVM but can compile to optimized Java. http://haxe.org http://haxe.org
- mike_hearn 12y ago
  I'm looking a lot at Kotlin. It's not mature yet: JetBrains will start using it this summer for their own projects and I expect it to firm up a lot then. The nice thing about Kotlin is almost perfect compatibility with Java, and an auto-translator that doesn't suck. So you can take an existing Java codebase and auto translate class by class, maintaining compilability the whole time. Also the standard library is mostly a set of extensions to the JDK so your existing library knowledge ports across, except you keep finding useful goodies sprinkled all over the place. Feature-wise Kotlin has things that I feel would help me write fewer bugs: it has null-safety encoded into the type system, smart casts, extension methods, some good functional programming support, powerful properties and so on. There are features it lacks too, but I hope JetBrains will continue to push it forward for many years.
  - pjmlp 12y ago
    They already use it. There was a Kotlin talk where they mentioned some plugins are now being written in it.

mda 12y ago

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

deleted 12y ago

[deleted]

LaSombra 12y ago

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.

cliveowen 12y ago

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

pohl 12y ago
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 12y ago
  > 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.

chimeracoder 12y ago

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 12y ago
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 12y ago
  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.

wyager 12y ago

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.

chimeracoder 12y ago
> 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.

smrtinsert 12y ago

Does anyone know any good platforms for mobile cobol development?

mark_l_watson 12y ago

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.

Tloewald 12y ago

So... Go is the next COBOL?

coldcode 12y ago
I'm still waiting on a merger of the two - GOBOL.

deleted 12y ago

[deleted]

noelwelsh 12y ago

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 12y ago
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.
- pessimizer 12y ago
  Readability is in the eye of the reader.

manishsharan 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

mseepgood 12y ago

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

dyeje 12y ago

"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 12y ago
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 12y ago
  Ah, thank you. That definitely makes more sense.
graetzer 12y ago
I think it fits in this context. JavaScript alone has no standard library or execution environment. Unlike the other languages listed there.

blahbl4hblahtoo 12y ago

Troll much?

iadapter 12y ago

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/#comment-1366371487 http://blog.paralleluniverse.co/2014/05/01/modern-java/#comm...

0xdeadbeefbabe 12y ago

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/

brl 12y ago

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

slashnull 12y ago

Go is the new cobol