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.)
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".
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.
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.
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.
This is a false dichotomy. There's a pretty wide continuum between type systems at least expressive enough to represent a user-defined list of a generic type and "all sorts of crazy typing".
...and that brings us full-circle to the blog post: rounding the corners so that the developers don't cut themselves and avoiding ideas that require developers to get out of their comfort-zones is exactly what made Java so successful. It put OO within the reach of mortals who were unwilling or unable to absorb C++. Go, being simple and unadventurous could very well skyrocket into the Java/COBOL stratosphere.
I think what we're currently seeing with Go, Rust, Elixir and others is taking the features that are perceived as good as trying to combine them in different ways.
I may be wrong, but isn't Rust's static lifetime analysis to avoid GC something novel?
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.
I've done the C way of checking every function for errors. It's painful, and should be done only when the problem domain demands it, which is a small subset of problems. Googlers are living in their own universe.
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. When the Go team was asked about what they like about Go one answer was:
"It's very simple to understand, and the code that I read on the page is the code that is executed.
When I iterate over a slice, there's not some chance that there's an iterator implementation that fetches a file from a web server in Romania and serves me some JSON or something.
Instead, the language is very deliberately simple and contained so that it's very easy to reason about code that you're reading." https://www.youtube.com/watch?v=sln-gJaURzk
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.
[0] http://talks.golang.org/2014/go4gophers.slide
[1] http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
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 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.
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.
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.
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.
And now, get off my lawn !
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.
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.
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.
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"
The reason it sticks around is because lots of enterprises either have mission critical code that works well in it and still has the same requirements (leaving no reason to replace it) -- or because poorly documented and tightly coupled code-bases makes it impossible to smoothly transition to something new. Often a combination of the two.
Was anybody else thrown off by this? I thought it was weird to throw Node in there considering Go, Ruby, and Python are languages.
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.
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.
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.
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?
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/#comm...
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.
