Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

influxdb.org

Post reply on HN
Print view View original

71–80 of 96 posts

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

#71

Post by azth »

rubiquity wrote: post #36
noelwelsh wrote: post #23

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…

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…

> What language created in the last 5 years has a feature that wasn't originally discovered in the 80s or earlier?

I may be wrong, but isn't Rust's static lifetime analysis to avoid GC something novel?

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

#72

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

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

#73

Post by mseepgood »

azth wrote: post #70
mseepgood wrote: post #63

Earlier quoted context omitted.

> 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 necessarily. Maybe you want to return the number of bytes read until the error AND the error. 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.

It's not a problem, because you can simply use product types, so you don't have to extend the language with yet another concept. For the Maybe monad / Option types you'd need lots of additional cruft like parametric polymorphism and probably something like the 'do' notation to make monads bearable. Go would lose all its charm of simplicity. Go would be another Haskell or ML, and we all know that these languages have failed to become successful by ignoring the human aspect of programming. We'd end up with articles like this http://www.haskell.org/haskellwiki/Typeclassopedia , longer than the entire Go specification.

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

#74

Post by wyager »

mseepgood wrote: post #53
wyager wrote: 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…

> 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 > you can't extend important built-ins like range or make() This was a deliberate design decision.…

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

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

#75

Post by azth »

mseepgood wrote: post #73
azth wrote: post #70

Earlier quoted context omitted.

> Not necessarily. Maybe you want to return the number of bytes read until the error AND the error. 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.

It's not a problem, because you can simply use product types, so you don't have to extend the language with yet another concept. For the Maybe monad / Option types you'd need lots of additional cruft like parametric polymorphism and probably something like the 'do' notation to make monads bearable. Go would lose all its charm of simplicity. Go would be another Haskell or ML, and we all know that these languages have…

Haskell and ML are practically FP oriented. You might want to check out Rust for a language that is not purely FP oriented (it is multi-paradigm), yet attempts to take pragmatic choices from such languages. There seems to be a good community response to it.

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

#76

Post by wonderzombie »

eudox wrote: post #35
pauldix wrote: post #27

Earlier quoted context omitted.

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

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

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.

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

#77

Post by mseepgood »

azth wrote: post #75
mseepgood wrote: post #73

Earlier quoted context omitted.

It's not a problem, because you can simply use product types, so you don't have to extend the language with yet another concept. For the Maybe monad / Option types you'd need lots of additional cruft like parametric polymorphism and probably something like the 'do' notation to make monads bearable. Go would lose all its charm of simplicity. Go would be another Haskell or ML, and we all know that these languages have…

Haskell and ML are practically FP oriented. You might want to check out Rust for a language that is not purely FP oriented (it is multi-paradigm), yet attempts to take pragmatic choices from such languages. There seems to be a good community response to it.

The community response seems to be mostly from people who like to talk about programming language features all day without actually using it for real projects.

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

#78

Post by mseepgood »

wyager wrote: post #74
mseepgood wrote: post #53

Earlier quoted context omitted.

> 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 > you can't extend important built-ins like range or make() This was a deliberate design decision.…

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

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

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

#79

Post by noelwelsh »

pauldix wrote: post #27
noelwelsh wrote: post #23

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…

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

I am very wary of arguments about simplicity, as what people usually mean by "simplicity" is "stuff I already know". Indeed I believe this is a large part of the reason for the popularity of Go: it is basically a statically typed and performant Python / Ruby. You don't need to learn much new to use it if you already know these languages.

The problem with this is how are we to advance if we never adopt new ideas?

Furthermore, I believe that the core of functional languages are very simple. Do you understand logical ands and ors? Then you understand algebraic data types. Do you understand high school algebra? Then you understand generics and higher kinds. It's all very simple but just maybe not stuff you're used to.

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

#80

Post by gress »

azth wrote: post #71
rubiquity wrote: post #36

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

> What language created in the last 5 years has a feature that wasn't originally discovered in the 80s or earlier? I may be wrong, but isn't Rust's static lifetime analysis to avoid GC something novel?

Objective-C has it.
Post reply on HN