Hacker News Reader

It's not very like Java at all. The only OO-like feature it has is interfaces, which are more like Haskell's type classes combined with existential types than anything else. (The resemblance here is actually very close, implementation-wise: roughly, vtables at the per-instance level rather than per-class level).

The other semi-interesting things it has are (a) channels + parallel functions and (b) the return of error codes for error handling.

Java things it doesn't have start with reflection, bytecode (CPU independence), dynamic runtime code generation, inheritance hierarchies, generics, "everything is an object", array covariance, exceptions as an idiomatic error propagation scheme, scoping based on nested namespaces, no code outside of classes, nested types with scoping to match, inner classes with implicit outer class self pointer, only value parameter semantics, and only reference user-defined types.

In fact most of what makes Java distinct from the subset it shares with C is missing, except for a garbage collector.

It's not very like Java at all. The only OO-like feature it has is interfaces, which are more like Haskell's type classes combined with existential types than anything else.

That's a bit disingenuous, since Haskell typeclasses go hand in hand with parametric polymorphism, which Go doesn't offer.

Typeclasses plus existential types allow you to implement subtype polymorphism. But it is generally frowned upon in the Haskell community and certainly not widely used.

Disregarding implementation, if you drag in typeclasses + existential types, Java's interfaces are also comparable (yeah, they don't offer compile-time duck typing, but neither does Haskell).

Java classes have to be declared to implement an interface. Haskell types don't need to be declared to "implement" a typeclass, since the typeclass instance is declared separately. You don't need to modify the original definition in order to package up a value + functions into an existential; to me, that's the essential advantage of duck typing for larger projects, where you don't have the ability to freely modify any and all source included.

Java classes have to be declared to implement an interface. Haskell types don't need to be declared to "implement" a typeclass, since the typeclass instance is declared separately.

Let's be more specific: instances should be declared with the class or with the data type. Orphaned instances (that go with neither) are discouraged and with good reason - instances cannot be imported explicitly [1]. It is all to easy to have two conflicting instances if people start defining instances apart from the type class or data type. Don't do that! Luckily, -Wall will complain loudly about orphaned instances.

where you don't have the ability to freely modify any and all source included

Given the above, this is not really true in Haskell. Since orphaned instances are bad, people often wrap a data type using newtype and define the instances with that type. Of course, this is not so much different from creating a wrapper class in Java with another superclass or interface. Except that defining new types in Haskell comes with far less ceremony ;).

[1] http://www.haskell.org/haskellwiki/Orphan_instance

Duck typing is an exercise in ceremony reduction, ideally to the point of no ceremony at all. We can always add another layer of indirection to act as a proxy whatever language we choose. Java and similar OO languages make it harder, duck typing is the easiest it gets. Everything else is on a continuum.

FWIW, I was more interested in the implementation details of existential types, and how similar it is to Go (except that Go does it dynamically using reflection, last time I checked). You know more about Haskell and its idioms than I do, I just know about the features and make inferences from how they may be combined :)

I don't mean it's like Java in terms of particular language features, but in terms of "feel" and philosophy. It uses abstractions on the same level as Java (higher than C, lower than Clojure), designed as a blue-collar language, emphasizes readability (at the expense of verbosity), and generally avoids low-level bit-diddling as well as high-level meta-programming tricks.

Ahh yes, you must be an inferior programmer if you work in language X.

Pretty much any common language other than C/C++ could be (and probably has been) called a blue-collar language - C#, Java, Javascript, Python....

What? Being a blue-collar language is a virtue! C#, Java, Python, Javascript etc. are all pretty much blue-collar languages; Haskell, Scala, C++ (depends), Rust (probably; I don't know much about it) and Clojure (sadly), aren't.

But you're right: "white-collar" languages have the habit of never being too popular.

There were days when Python was white collar.

There are places where C++ is blue-collar. (Games, for one.)

Rust is meant to be white collar, seems to me.

If "blue collar" means "used in industry for real work", and "white collar" means "a research/niche language", Rust is designed to be blue collar. It's not designed to be a testbed for research beyond what was needed to get safety out of zero-cost abstractions.

Let me revise my previous comment. While many might categorize Python, Javascript and Ruby as blue-collar languages, they do encourage all sorts of metaprogramming tricks, while Java, C# and Go absolutely don't. I think this is a big philosophical distinction, because the second group favors readability and the ability to share code in a large team over language power, and this is what makes Go much closer to Java/C# in its philosophy than to Python et al.

the second group favors readability and the ability to share code in a large team over language power

Not to pick on you, but people say this all the time, as in it's probably the thing people say most often on this subject, and I wonder: do we have any evidence for it? That is, do we have any evidence that the mid-tier languages which eschew more powerful abstractions (Java and its peers) lead to either more readable or more shareable code? Or is it one of those things that everybody "knows" but ain't so?

Well, I can't claim that that's the case, only that those languages' designers think it is. There are some things we do know, if only anecdotally (maybe there's been some research on the subject – I don't know). We do know that C++ was a real boon when it first garnered wide appeal, but that very quickly large teams began to curtail the use of some of its more advanced features because of that reason. We also know that people have been writing much larger projects in Java (and possibly C#) than in any other language in history, certainly relative to the effort invested (there might have been larger C++ projects). Some of it just seems intuitive (though may not be the actual case). The problem is that it's hard to gather data because the languages adopting this view are the ones that are most popular, which helps them get selected for large projects to begin with. But we might have more data soon. I think JavaScript is the first "magic encouraged" language that will be used in multi MLOC projects. Ruby is more "magical" but doesn't seem to be favored by large teams working on large projects. So we might know more soon.

Personally, though, I think that's the wrong issue. Whatever extra productivity is gained by language magic, we're not talking orders of magnitude here. Usually it's mostly about developer enjoyment, lack of annoying boilerplate etc.. These are annoying issues, but not critical ones. I think the most crucial issue is state management, which can have an order-of-magnitude difference for some projects, as well as a significant effect on performance and scaling.

Most everything you're talking about is explicable by popularity effects. That's why more objective study would be interesting. Alas, I doubt it will happen: serious research on software engineering, as opposed to the thin broth we have now, would require at least an order of magnitude more funding, and no one's likely to provide that.

I'm not sure I like your distinction between developer enjoyment, lack of boilerplate, and state management. To me those things all have to do with good design.

Blue collar worker just usually means "one who is uneducated and unskilled". Putting that onto languages is sort of demeaning... it sounds like that's not really what you meant, though, and that's cool, just my misunderstanding of your meaning.

That's just how James Gosling described Java when he explained the philosophy behind it in 1997[1]. He wrote, "Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea." He most certainly didn't intend the term to be demeaning, but more to contrast it with research languages that include features that are untried and unproven. The term has since been used as shorthand for Java's (and languages like it) goals and philosophy.

[1]: http://dfjug.org/thefeelofjava.pdf

Uneducated I'll give you, though probably it should be qualified by something like formally educated, but blue collar certainly does not mean unskilled.

The paradigmatic blue collar job to my mind is not taking orders at McDonalds, it's welding.

I knew I should have qualified that more. You're right, McDonald's is not blue collar, but working in a manufacturing plant riveting part A to part B is. It also encompasses stuff like mechanics and welders that do require skill and even some education and certification.

But regardless, most of the time it's still used to mean something lesser.

Not sure if I'm reading your response incorrectly... but go has reflection. I'm not sure what you mean by scoping based on nested namespaces.... Go has similar scoping to pretty much every other modern language. Are you saying java has no code outside of classes? Because Go has that (and doesn't have classes).

Also... Go has OO features. You can make an object-like thing by tying data (a struct) with behavior (methods tied to the struct). It doesn't have inheritance which is not the same as not having OO features.

I think you think I'm criticising Go. I'm not. Beyond that, I think you misunderstood my response.

Yeah, I figured I was misunderstanding you. It seems like you were giving a list, half of which was stuff Go didn't have and half of which java didn't have.... anyway, no big deal, just trying to clarify.

I use Lua for fast command-line programs. If that were to not be fast enough (and I'm not sure Go is faster than Lua but let's assume it was), I'd go with Rust which manages to be both lower-level and higher-level than Go at the same time.

There's no doubt Rust is more "important" than Go in the sense that it may have a much greater impact on the software community, but the two languages don't seem to be comparable at all, and they certainly don't compete. Rust is more complicated than Go (it should be, as its more ambitious), and aimed to replace C/C++. Go, as I said, is Java Lite (and like Java, a blue-collar language). Go is great when you want to write a smallish, self-contained Java program and want to spare yourself writing a startup script and requiring (or packaging) the JVM. (I don't know anything about Lua)

Wow, go is totally not Java-lite. Trying to program in it like it is will just cause headaches. The only conceivable way that I can think of that it could be called that is because it is compiled and has a garbage collector. Otherwise... they are very different languages.

Go is what you'd get if python and C had a bastard love child that turned out different from either, but still retained some of the beauty of each of its parents.

And Nimrod would be their legitimate favorite son.

> Go, as I said, is Java Lite

Or Python+.

Interesting all the comparisons to Java, with me coming from an environment where Java is never used, never considered, largely never thought about. If Java is mentioned at all, it's usually something like "my kid took a programming class in college, and they used Java, why would they use something like that?". I suppose Cobol was like that: widely used, very widely used, but not used at all in many circles.

Probably more accurately Python--; it cuts out a lot of features from Python, a great deal of which you weren't using, some others of which there are other ways to do, and ends up with a simpler and also much faster language, in which you will sometimes miss a Python feature, but in my experience not as often as you might think. But definitely non-zero.

(By "not using", I mean for instance that in Python, like Javascript, at any moment, you may set a new method on a particular instance, and the Python runtime must deal with that, such as by spending a lot of time looking up references that never actually change in a real program. This is a really expensive feature that you are paying for all the time, yet rarely using. A great deal of the JIT speedup you can get in such languages is working out how to skip those lookups optimistically until someone actually changes them.)

I miss Python's named parameters with default values. They are surprisingly hard to replicate in Go. Also list comprehensions.

Named parameters can be sort of gotten by passing a struct as the parameter, then you can do

type fooParams struct { Name string Age int Address string }

foo( fooParams{ Name = "Bob", Age = 24 } )

Defaults are a lot harder to do in a way that doesn't just suck. You can make a DefaultFooParam that has all the defaults... but it's not pretty.

List comprehensions never seemed like a big deal to me. It's 3-4 lines for a loop, which is probably easier to read than the list comprehension anyway.

> List comprehensions never seemed like a big deal to me. It's 3-4 lines for a loop, which is probably easier to read than the list comprehension anyway.

that's totally a nope.

    def qsort(L):
        if len(L) <= 1: return L
        return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

I just saw this several days late, but have to comment.... is that really the example you're giving of a list comprehension that's easy to read? Because... yeah no. If I saw this in a code review, the first thing I'd say is "this code is illegible, please reformat to make it easier to read"

This is classic "I'm trying too hard to make my code look clever rather than make it readable and easy to understand".

Unlike Cobol there are few circles where Java, or at least the JVM, isn't used. The ones that come to mind are .Net shops, hardware/embedded shops, very specialized applications (scientific, etc.), console game developers, or – and this is probably the largest one – small(ish) web startups: your Ruby/Python/Javascript crowd before they need to scale. Many of those in the last group would still have some Java/JVM.

> [...] there are few circles where Java, or at least the JVM, isn't used

I was making the very opposite point. I think Java programmers tend to underestimate the circles where it is not used. In particular, it seems that those who would not describe themselves as professional programmers but who nevertheless need to program tend to not use Java. And it's not all Python/Perl/Basic/Tcl/Bash; C++ (and C) are also widely used.

The people being excited by a language have nothing to do with what the language is like.

I see Go as a C-like language with some of the annoyances cut out and a garbage collector added. You don't have pointer arithmetic, but you still have pointers.

When you look at it that way, the lack of generics is not so annoying.

The best part of Go is the fact that it forces error checking.

> The best part of Go is the fact that it forces error checking.

Except that it doesn't. Otherwise you would be forced to check the return type of fmt.Printf() and gang.

>> > The best part of Go is the fact that it forces error checking.

> Except that it doesn't.

Depending on the value of "forces" used. Maybe "forces" in the sense of "only viable option for someone not programming foolishly."

Ok. So idiomatic go returns multiple values with an intention to return an error type. I guess fmt.Printf() is an exception.

For the most part, it does as well as C does.

> For the most part, it does as well as C does.

Which isn't saying much really :) There is absolutely no way to force you to handle errors in Go.

> Its only advantages, as I saw them, were a much reduced startup time

Even that can be solved when using one of the many native compilers available for Java.

As the OpenJDK does not have one, people tend to forget other vendors have them.

Can you recommend some good native compilers? Excelsior[1] is the only one that I've read good things about, but I haven't tried it.

[1] http://www.excelsior-usa.com/

I know a few from conferences, but never used them on projects myself.

Besides Excelsior, there are Aonix PERC, IBM J9, Codename One, JamaicaVM, RoboVM.

There are probably a few others.

Mark Reinhold mentioned on his "post Java 8" talk at Java One, that having an AOT compiler as part of the standard JDK is part of the wishlist.

Avian (http://oss.readytalk.com/avian/) also has an AOT compilation option.

How does having a "native" compiler reduce the startup overhead of the JVM? That doesn't make any sense.

It may reduce compile times, but ultimately the reason startup sucks is because the JVM is huge and has to load everything and the kitchen sink in order to function for even the smallest programs.

Because when you compile to native code ahead of time:

1 - There is no JVM

2 - All the code that is not used is not part of the binary, if you do a static build

2.1 - There are native compilers for Java where you can give exclusion lists to allow certain code to be kept even in static builds to allow reflection use

OK, we are not talking about the same thing. I was thinking along the lines of a compiler written in a native (non-jvm) language ala jikes but you are referring to a compiler that compiles to a native executable ala gcj.

I've experimented with gcj in the past. It still suffered from excessive overhead, still had it's own runtime requirements (although obviously not the same as the JVM) and had a lot of serious compatibility issues. Not something I would have based a serious production deployment off of personally. Maybe the state of the art has changed since then.

gcj was a toy compiler, a 2nd class citizen on the supported gcc languages, left to rotten.

It was never at the same level as commercial Java native compilers.

I also once had this idea. Because Go is mostly the only matured language which can describe processes and pipes in a program with solid flow control. But still, it doesn't feel nice to interact with shell…