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).
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 mostl…
Java is the COBOL of my generation and Go is its successor
61–70 of 96 posts
Re: Java is the COBOL of my generation and Go is its successor
#62Jesus, 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…
This is exactly why I don't want to jump on the Go bandwagon. You forgot to mention the Go ABI which isn't even compatible with C. That alone for me is reason enough not to use it as a systems programming language. I would choose D over Go any day of the week. It's longer to learn and master, sure, but it is also much more powerful and expressive.
Re: Java is the COBOL of my generation and Go is its successor
#63Sigh. 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…
Not necessarily. Maybe you want to return the number of bytes read until the error AND the error.
> 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?
You're conflating "it was once invented" with "it's a good thing without any trade-offs and should be put in every programming language".
Re: Java is the COBOL of my generation and Go is its successor
#64If 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 adoptio…
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.
Re: Java is the COBOL of my generation and Go is its successor
#65Earlier quoted context omitted.
What language created in the last 5 years has a feature that wasn't originally discovered in the 80s or earlier? It's all too easy to bash new languages for not having some hot new, never before seen feature, meanwhile there are almost no examples of new languages doing earth shattering things. I think what we're currently seeing with Go, Rust, Elixir and others is taking the features that are perceived as good as tr…
Quite true. Just that Go designers didn't include most of the things that became mainstream since then.
Re: Java is the COBOL of my generation and Go is its successor
#66Earlier quoted context omitted.
Quite true. Just that Go designers didn't include most of the things that became mainstream since then.
So they had enough time to observe these things in mainstream languages and recognize that a lot of them are not worth the hassle.
Re: Java is the COBOL of my generation and Go is its successor
#67Earlier quoted context omitted.
So they had enough time to observe these things in mainstream languages and recognize that a lot of them are not worth the hassle.
Actually I think that given that they gave birth to one of the most unsafe languages on the planet, and publicly ranted against OO and FP languages during their career, they have choosen to ignore them as a political decision.
Re: Java is the COBOL of my generation and Go is its successor
#68Earlier quoted context omitted.
I'm waiting for the talks from Gophercon to appear online, but one of them[0] talks about using Go interfaces to handle most generic type problems. Another interesting read is Rob Pike's argument about "less is more"[1]. The HN discussion on less-is-more from 2 years ago brought about some interesting discussion as well[2]. [0] http://talks.golang.org/2014/go4gophers.slide [1] http://commandcenter.blogspot.com/2012/0…
>using Go interfaces to handle most generic type problems Do you mean Go interface specifications, or the Go interface{} type? Because the latter is the top type. Using it is equivalent to casting things to Object in Java, which people did up until 2004 when they realized it was really stupid. You also can't use Go interface specifications to make generic data structures, which is the really important use case.
You can easily use interface{} to make generic data structures, but interfaces have a time/space/code-complexity cost which makes them not worth it most of the time.
Re: Java is the COBOL of my generation and Go is its successor
#69Earlier quoted context omitted.
Actually I think that given that they gave birth to one of the most unsafe languages on the planet, and publicly ranted against OO and FP languages during their career, they have choosen to ignore them as a political decision.
What makes it unsafe? The worst you can do is cause your program to panic (which you can recover).
Re: Java is the COBOL of my generation and Go is its successor
#70Sigh. 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…
> 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. Not necessarily. Maybe you want to return the number of bytes read until the error AND the error. > We've know how to do error handling without exceptions and without boiler plate since about 1991 (Wadler; monads). Generics since about 1985 (ML).…
Not mutually exclusive. The number of bytes read until the error occurred could be part of the error itself. Sum types are practically always better. The problem is that Go does not support them.