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

91–96 of 96 posts

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

#91

Post by wyager »

jmoiron wrote: post #68
wyager wrote: post #41

Earlier quoted context omitted.

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

Go does not have a type hierarchy, so there is no top type. 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.

>Go does not have a type hierarchy, so there is no top type.

Go does have a type heirarchy. It's just not very extensible. There is top (interface{}) and then there are all other types (which are subtypes of interface{}).

If Go didn't have a type heirarchy, you wouldn't be able to up- and down-cast (up-casts are performed via implicit coercion to interface{} and down-casts are explicit).

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

You also lose any semblance of type safety, which is kind of awful.

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

#92

Post by jmoiron »

wyager wrote: post #91
jmoiron wrote: post #68

Earlier quoted context omitted.

Go does not have a type hierarchy, so there is no top type. 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.

>Go does not have a type hierarchy, so there is no top type. Go does have a type heirarchy. It's just not very extensible. There is top (interface{}) and then there are all other types (which are subtypes of interface{}). If Go didn't have a type heirarchy, you wouldn't be able to up- and down-cast (up-casts are performed via implicit coercion to interface{} and down-casts are explicit). >You can easily use interface…

There is no type hierarchy and there are no subtypes. Interfaces do not describe type relationships. The conversion required between `[]int` and `[]interface{}` further demonstrates the significance of this distinction.

As for losing type safety when writing generic containers, this is true, and another reason why people don't do this.

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

#93

Post by chwahoo »

wonderzombie wrote: post #76
eudox wrote: post #35

Earlier quoted context omitted.

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

I don't think his point is as broad as you're claiming. He's saying that golang application code is complex due to (for example) lack of generics because the language lacks that complexity.

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

#94

Post by pcwalton »

mseepgood wrote: post #77
azth wrote: post #75

Earlier quoted context omitted.

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.

Is Servo not a real project?

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

#95

Post by pcwalton »

pjmlp wrote: post #84
azth wrote: post #71

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? I may be wrong, but isn't Rust's static lifetime analysis to avoid GC something novel?

Similar approaches do/did exist. ATS uses theorem-proving, http://www.ats-lang.org/ . ParaSail uses regions, https://forge.open-do.org/plugins/moinmoin/parasail/ BitC used the type system, http://www.bitc-lang.org

None of these have the borrow check. From what I've heard the borrow check is impossible to encode generically in ATS (though maybe that has changed).

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

#96

Post by pcwalton »

gress wrote: post #89
plorkyeran wrote: post #86

Earlier quoted context omitted.

ARC doesn't involve any sort of nontrivial lifetime analysis. The compiler simply inserts calls to retain and release at all of the same places where explicit calls to them (hopefully) were with manual reference counting. The only vaguely novel part of any of it was successfully migrating a language from manual to automatic reference counting.

Actually that's not entirely true. Arc inserts the calls first, but then does an elimination phase that can identify lifetimes beyond method boundaries and remove unnecessary calls. It's not particularly complex, but the architecture is there for further enhancement of this phase as they build out the static analyzer.

That's nowhere near what the borrow check does. The borrow check is based on reasoning about ownership and inherited mutability, neither of which apply to Objective-C.
Post reply on HN