Articles on Go are getting a little boring. The majority are written by people who've spent an afternoon looking at Go and decide to rehash the same 5 bullet points. In the time it takes to read their "article" I could learn the same stuff, better, by reading the official Go tutorial.
Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...
The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.
In my case at least, this article spawned a little personal research that has me now giving Go a serious try. With all of the new-ish languages and databases popping up, it can be difficult to choose which ones to try for a new project, or seek solutions for a new problem.
There is something in the initial life of a new technology that determines if the adoption rate will result in success or failure, where failure is abandonment and an end to development. If this sort of interest keeps Go going, then maybe some repetition is a good thing.
You should look on the bright side. Every time one of these "Impressions of Golang" articles hits the front page, we get pages of bike-shedding in the comments.
I get the sense that many of us are just waiting for a few improvements (like generics and better GC/performance) before using Go for real work, but it seems mature enough for many uses already.
This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository"
-- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche.
There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.
I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small.
But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure).
Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM.
(P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go)
Actually, most of that enumeration consists of shallow clichés. For instance, take the description of Java:
Java: too verbose,
Having written a fair share of Go and Java code, I have to say that difference is not all that profound. The usual boilerplate that people come up with is the construction of a BufferedReader/Writer. But Go has its share of boilerplate as well (e.g. error handling). Java currently has the advantage that IDEs can quickly generate whatever boilerplate is necessary. Given that Go is easy to parse and has a simple module system, there'll probably fairly complete IDEs for Go as well.
too many FactoryFactories
That very much depends on what libraries or frameworks you use. I have written lots of ML and NLP code in Java the last half year or so. I can count the number of insane 'FactoryBuilderProxy'-like classes that I encountered on one hand. Wait a bit and the architecture astronauts will also be writing Go packages ;).
I was about to post the exact same comment, with the above quote from OP in my clipboard.
In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings.
I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing.
The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.
This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository"
-- is unfounded.
Not necessarily unfounded, you simply don't have access to data on it.
I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.
> This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded.
Why is it unfounded? The author clearly qualifies his claim with "my experience". That's my experience too. I wouldn't extrapolate it to all programmers and in all scenarios, but dynamic typing just has never worked that well for me in larger projects.
It could be because I'm not as diligent about writing unit tests or it could be because I'm not intelligent enough to reason about large amounts of code without static types. Regardless of whether it is, it's my experience and it certainly isn't "unfounded."
It's weird. You mention that the claim is unfounded, and then you have all this text that follows, but none of it seems related to supporting your point.
How is the claim that [X at large is difficult to maintain] unfounded?
I happen to agree. I am (was?) a Perl/JavaScript developer. I find both to be sorely lacking at a certain size. And by extension I assume Python and Ruby to be the exact same (under the shared umbrella of lacking static type safety).
I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't agree with me [yet! :)] about dynamic languages, though.
I will write a followup post later this week about the long-term maintenance problems associated with languages in the python/ruby/javascript family. I don't think they're "bad" (I was known to advocate for python in certain situations when I was at Google), but they're often inappropriate, and it is my sense that many developers haven't had the requisite large-dynamic-language-project trauma yet to understand that from firsthand experience. (The toughest part about those traumas is that they happen so late in a project's lifecycle that there's no quick way back to safety...)
So I will try to make that case in a future post. Thanks for your thoughts.
> There are magnitudes more libraries and resources available for Python/Ruby/JS/Java
Those languages have been out longer. I think Go will get there.
EDIT: cgo dramatically expands the libraries. I hear a lot of people say "Go doesn't have X", but if X is already implemented in C (assuming some conditions are met), then you need not reinvent the wheel. I've been using Go as a concurrent parent over C functions for my geospatial research... really nice fit when you need to do 100 gigs worth of XYZ coordinate transforms.
I think go does have a niche, and it is "python/ruby devs". Yes, its niche is a set of people, not a particular role. Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby, I see a lot of ruby and python devs upgrading to go.
I also think you are being unfair to D. D is basically just what go initially claimed to be: a new systems language. D is a fantastic replacement for C++, go doesn't really enter the world C++ lives in.
Dynamic typing has advantages and disadvantages. E.g. Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse whereas compile time type checking reduces the effort for testing (but for very simple cases only).
"Java: too verbose, too many FactoryFactories, painful to tune"
Paintful to tune... Maybe. But I don't understand why so many people say patterns like FactoryFactoryFactories are inherent to Java!
I can write Java code with NO factories at all. Writing shitty and unflexible code is really easy. When you understand why a factory is used in a particular piece of code, you start to appreciate it!
It's also very possible to write C++ or Python code with too many overengineered components.
Also, I like a language to be verbose, I don't think it is an issue. As long as the code is clear and easy to read... And it's often the case with Java programs. For my eyes, Java is way more readable than, let's say, Perl, Scala or Clojure. I couldn't care less about the number of lines required to achieve the same result!
I'm getting tired of this Java bashing... The only thing that really sucks about Java is Oracle!
In fact, since go does not have explicit constructors, it encourages the factory pattern all over the place. You'll find static factories everywhere in the go library.
Even Java bashers would concede that Java is a brilliant language, certainly for its time. And the JVM is the most impressive programming environment to this day.
But the language has become a little dated. Oh, you don't need to go as far as Scala to fix it (to me Scala feels like a deranged, haphazard combination of javascript and Haskell), but something like Kotlin could really be a "better Java" (it also happens to be a better Scala, but that's a different point).
I guess when you talk about a language, you usually also end up talking about the platform, libraries, community and the whole environment. It is hard to escape from this when talking about Java.
For those that are not in the Java land - the whole Java ecosystem is heading in an interesting direction.
Not just the platform (with all the other jvm languages), but the java language itself. Using Java 8 and some of the new features, suddenly standard Java code starts looking more and more modern. Add to this some interesting developments in the framework land, like NIO with Netty, Gradle combined with maven repositories for dependancy management, even new developments in entrenched stuff like Spring or JavaEE...
The community and the ecosystem is slowly evolving outside the whole enterprise monstrosities. It will be interesting to observe the platform in the next couple of years.
I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. More here:
There's still room out there for the C replacement language. Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.
> No type inference. Because obviously it’s 2013 and I want to write types everywhere.
The `:=` does a fair bit for the programmer in cutting back on writing types. For me, the most needed place for type inference would be for writing anonymous closures (like what Rust has). In most other places, I am quite content with writing the types, particularly at the top level.
> Like what’s the point of all the odd rules around := vs =
The former is short-hand for variable declaration with assignment and type deduction, while the latter is just regular assignment. The primary benefit here is type deduction, which partially relieves the lack of type inference.
> and what types you can and can’t assign and pass to functions
Huh?
> And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!)
The compiler absolutely cannot work them out for you. If you have a package `github.com/PeepA/wat` and a package `github.com/PeepB/wat`, how will the Go compiler know which `wat` package to import?
The Go compiler merely moans if an import (or its alias) hasn't been used in the source file that it was imported in. I like this feature, even if it is a mild bother while debugging.
> Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back.
It's two lines. [1]
> No breakthrough on error handling.
Breakthrough? I'm not sure what you were expecting, but I think the error handling is pretty sane and at least far better than error handling conventions established in C. It could be adjusted if sum types were added to the language, but that has its own trade offs.
If you desperately want exception-style error handling, then you can use panic/defer/recover, but it's frowned upon to overuse it.
> The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess.
I have the exact opposite opinion. Did you know that you probably shouldn't be setting `GOROOT`? [2] After Go is installed, you just need to set `GOPATH` and add `$GOPATH/bin` to your `PATH`. That's it.
> It’s not even enforced error checking, so bad programmers will still be able to write bad code.
That is true, but Go's compiler forces you to address errors returned by functions that also return another value. You either need to explicitly ignore it or use the variable the error is stored in. (Lest you get an "unused variable" compiler error.) This doesn't cover all cases---like completely ignoring the return value(s) of a function---but don't throw the baby out with the bath water!
Go was neither designed to replace nor compete with existing functional languages.
Even if it were demonstrably true that functional programming languages are a "better" (leaving this loosely-defined for now) choice than Go in 100% of the circumstances in which one would choose to use Go, your argument still wouldn't hold water, as it neglects other important characteristics of a programming language that are neither quantifiable nor useful in the context of comparing programming languages, such as perceived simplicity and the ability to hold the entire programming language in one's head.
What's the value in denouncing a programming language because it isn't designed with your favorite programming paradigm in mind? That's just dick.
Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do?
I kind of think Rob Pike knows about functional programming.
Go was written at Google to solve very specific problems Google had. Looming large was the need for a C family language that implemented concurrency, fast compiles, and so on. The C family requirement is quite simple: most google engineers are young and don't know functional programming, have experience with Google's existing C/C++ code base, and they will be using Go to replace and extend existing systems already in C/C++. A new functional paradigm, nice as it is, would just get in their way. I'm not enamored by many features of the language, but I'm really hard pressed to say that those features do not solve Google's problems.
Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken".)
Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.
>I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them.
Or "got it" and didn't find it any that good, for the types of problems they work on.
I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basically mean: a rich editor, stable code completion, jump-to-declaration etc; and tight debugger integration.
Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short:
1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever.
2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build.
3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own.
4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day.
The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :)
Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.
Imagine if the Go team listened all those that want Generics in Go. It would be more consistent and closer to perfect language.
As it is, it's a PITA 20% of the time.
(Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).
> C++: too much rope, hard to maintain, painful to introduce at a company with no prior C++ footprint, frightens junior devs who no longer absorb relevant memory management idioms in school
So, are we now in an era when there are lots of people in the job market who couldn't write a doubly-linked list to save their life?
When I was in my 20's, I noted that there were lots of programmers around who basically treated compilers as "magic" and hadn't the tiniest inkling about how they worked. Now that I'm in my 40's, I've noted "so what" attitudes in languages that require manual memory management. (iOS and Objective-C. ARC goes a long way, but it still doesn't take care of everything for you.)
Best sum up of the language i've ever seen (plus it seems completely coherent with what i've supposed so far about that language, both pros and cons).
About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?
Good pros and cons of Go language. There is some information around why Go and not say C++/Java/Ruby etc. The statement "I see Rails as the emperor with no clothes on" seems to be made in haste, since Rails is awesome for basic forms based apps.
I know a lot of friends of mine who have C/C++/PHP background struggle with rails at the start, primarily because of the magic of convention over configuration that happens (they aren't used to it). It takes a while to understand it. But once you understand it, it's a breeze.
Disclaimer: I am a Rails developer. My views are therefore biased.
I see it's become trendy to poke fun at Rails and the hurdles it puts on your way to "scale". Not only have many companies been able to do so using Rails, but it also completely overshadows the ease it provides to get started in the initial phase of a project.
That being said, Go really seems like an awesome language, I've dabbled some and I can't wait to get back to it.
I agree with the point about statically-linked binaries. However, I wish there were a compile-time facility for including the contents of a file as a read-only byte array in the binary. Then web application servers with HTML templates, and even images and other assets, could be truly self-contained.
[+] [-] jlarocco|12 years ago|reply
Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...
[+] [-] tptacek|12 years ago|reply
[+] [-] zeeboo|12 years ago|reply
[+] [-] bsg75|12 years ago|reply
There is something in the initial life of a new technology that determines if the adoption rate will result in success or failure, where failure is abandonment and an end to development. If this sort of interest keeps Go going, then maybe some repetition is a good thing.
[+] [-] cjdrake|12 years ago|reply
[+] [-] dvirsky|12 years ago|reply
1. It's interesting to see what people struggle with or like about it, having written a lot of Go. That gives me some perspective, I guess.
2. The comments usually have these little gems of tips and tricks, like one I found here.
That said, #1 is getting a bit old.
[+] [-] jongraehl|12 years ago|reply
I get the sense that many of us are just waiting for a few improvements (like generics and better GC/performance) before using Go for real work, but it seems mature enough for many uses already.
[+] [-] dvt|12 years ago|reply
-- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche.
There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.
[+] [-] pron|12 years ago|reply
But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure).
Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM.
(P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go)
[1] https://github.com/puniverse/quasar
[+] [-] microtonal|12 years ago|reply
Actually, most of that enumeration consists of shallow clichés. For instance, take the description of Java:
Java: too verbose,
Having written a fair share of Go and Java code, I have to say that difference is not all that profound. The usual boilerplate that people come up with is the construction of a BufferedReader/Writer. But Go has its share of boilerplate as well (e.g. error handling). Java currently has the advantage that IDEs can quickly generate whatever boilerplate is necessary. Given that Go is easy to parse and has a simple module system, there'll probably fairly complete IDEs for Go as well.
too many FactoryFactories
That very much depends on what libraries or frameworks you use. I have written lots of ML and NLP code in Java the last half year or so. I can count the number of insane 'FactoryBuilderProxy'-like classes that I encountered on one hand. Wait a bit and the architecture astronauts will also be writing Go packages ;).
[+] [-] davesims|12 years ago|reply
In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings.
I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing.
The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.
[+] [-] btilly|12 years ago|reply
-- is unfounded.
Not necessarily unfounded, you simply don't have access to data on it.
I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.
[+] [-] burntsushi|12 years ago|reply
Why is it unfounded? The author clearly qualifies his claim with "my experience". That's my experience too. I wouldn't extrapolate it to all programmers and in all scenarios, but dynamic typing just has never worked that well for me in larger projects.
It could be because I'm not as diligent about writing unit tests or it could be because I'm not intelligent enough to reason about large amounts of code without static types. Regardless of whether it is, it's my experience and it certainly isn't "unfounded."
[+] [-] ionforce|12 years ago|reply
How is the claim that [X at large is difficult to maintain] unfounded?
I happen to agree. I am (was?) a Perl/JavaScript developer. I find both to be sorely lacking at a certain size. And by extension I assume Python and Ruby to be the exact same (under the shared umbrella of lacking static type safety).
[+] [-] el_bhs|12 years ago|reply
I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't agree with me [yet! :)] about dynamic languages, though.
I will write a followup post later this week about the long-term maintenance problems associated with languages in the python/ruby/javascript family. I don't think they're "bad" (I was known to advocate for python in certain situations when I was at Google), but they're often inappropriate, and it is my sense that many developers haven't had the requisite large-dynamic-language-project trauma yet to understand that from firsthand experience. (The toughest part about those traumas is that they happen so late in a project's lifecycle that there's no quick way back to safety...)
So I will try to make that case in a future post. Thanks for your thoughts.
[+] [-] fixxer|12 years ago|reply
Those languages have been out longer. I think Go will get there.
EDIT: cgo dramatically expands the libraries. I hear a lot of people say "Go doesn't have X", but if X is already implemented in C (assuming some conditions are met), then you need not reinvent the wheel. I've been using Go as a concurrent parent over C functions for my geospatial research... really nice fit when you need to do 100 gigs worth of XYZ coordinate transforms.
[+] [-] asdasf|12 years ago|reply
I also think you are being unfair to D. D is basically just what go initially claimed to be: a new systems language. D is a fantastic replacement for C++, go doesn't really enter the world C++ lives in.
[+] [-] sprash|12 years ago|reply
[+] [-] electrotype|12 years ago|reply
Paintful to tune... Maybe. But I don't understand why so many people say patterns like FactoryFactoryFactories are inherent to Java!
I can write Java code with NO factories at all. Writing shitty and unflexible code is really easy. When you understand why a factory is used in a particular piece of code, you start to appreciate it!
It's also very possible to write C++ or Python code with too many overengineered components.
Also, I like a language to be verbose, I don't think it is an issue. As long as the code is clear and easy to read... And it's often the case with Java programs. For my eyes, Java is way more readable than, let's say, Perl, Scala or Clojure. I couldn't care less about the number of lines required to achieve the same result!
I'm getting tired of this Java bashing... The only thing that really sucks about Java is Oracle!
[+] [-] sarnowski|12 years ago|reply
http://golang.org/doc/effective_go.html#composite_literals
[+] [-] tomp|12 years ago|reply
[+] [-] pron|12 years ago|reply
But the language has become a little dated. Oh, you don't need to go as far as Scala to fix it (to me Scala feels like a deranged, haphazard combination of javascript and Haskell), but something like Kotlin could really be a "better Java" (it also happens to be a better Scala, but that's a different point).
[+] [-] Ygor|12 years ago|reply
For those that are not in the Java land - the whole Java ecosystem is heading in an interesting direction.
Not just the platform (with all the other jvm languages), but the java language itself. Using Java 8 and some of the new features, suddenly standard Java code starts looking more and more modern. Add to this some interesting developments in the framework land, like NIO with Netty, Gradle combined with maven repositories for dependancy management, even new developments in entrenched stuff like Spring or JavaEE...
The community and the ecosystem is slowly evolving outside the whole enterprise monstrosities. It will be interesting to observe the platform in the next couple of years.
[+] [-] rwmj|12 years ago|reply
https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-li...
There's still room out there for the C replacement language. Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.
[+] [-] burntsushi|12 years ago|reply
The `:=` does a fair bit for the programmer in cutting back on writing types. For me, the most needed place for type inference would be for writing anonymous closures (like what Rust has). In most other places, I am quite content with writing the types, particularly at the top level.
> Like what’s the point of all the odd rules around := vs =
The former is short-hand for variable declaration with assignment and type deduction, while the latter is just regular assignment. The primary benefit here is type deduction, which partially relieves the lack of type inference.
> and what types you can and can’t assign and pass to functions
Huh?
> And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!)
The compiler absolutely cannot work them out for you. If you have a package `github.com/PeepA/wat` and a package `github.com/PeepB/wat`, how will the Go compiler know which `wat` package to import?
The Go compiler merely moans if an import (or its alias) hasn't been used in the source file that it was imported in. I like this feature, even if it is a mild bother while debugging.
> Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back.
It's two lines. [1]
> No breakthrough on error handling.
Breakthrough? I'm not sure what you were expecting, but I think the error handling is pretty sane and at least far better than error handling conventions established in C. It could be adjusted if sum types were added to the language, but that has its own trade offs.
If you desperately want exception-style error handling, then you can use panic/defer/recover, but it's frowned upon to overuse it.
> The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess.
I have the exact opposite opinion. Did you know that you probably shouldn't be setting `GOROOT`? [2] After Go is installed, you just need to set `GOPATH` and add `$GOPATH/bin` to your `PATH`. That's it.
> It’s not even enforced error checking, so bad programmers will still be able to write bad code.
That is true, but Go's compiler forces you to address errors returned by functions that also return another value. You either need to explicitly ignore it or use the variable the error is stored in. (Lest you get an "unused variable" compiler error.) This doesn't cover all cases---like completely ignoring the return value(s) of a function---but don't throw the baby out with the bath water!
[1] - http://play.golang.org/p/ihEoJ0yL9I
[2] - http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroo...
[+] [-] acuozzo|12 years ago|reply
Even if it were demonstrably true that functional programming languages are a "better" (leaving this loosely-defined for now) choice than Go in 100% of the circumstances in which one would choose to use Go, your argument still wouldn't hold water, as it neglects other important characteristics of a programming language that are neither quantifiable nor useful in the context of comparing programming languages, such as perceived simplicity and the ability to hold the entire programming language in one's head.
What's the value in denouncing a programming language because it isn't designed with your favorite programming paradigm in mind? That's just dick.
Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do?
Really? Really?
[+] [-] RogerL|12 years ago|reply
Go was written at Google to solve very specific problems Google had. Looming large was the need for a C family language that implemented concurrency, fast compiles, and so on. The C family requirement is quite simple: most google engineers are young and don't know functional programming, have experience with Google's existing C/C++ code base, and they will be using Go to replace and extend existing systems already in C/C++. A new functional paradigm, nice as it is, would just get in their way. I'm not enamored by many features of the language, but I'm really hard pressed to say that those features do not solve Google's problems.
[+] [-] masklinn|12 years ago|reply
That's Rust: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
[+] [-] tptacek|12 years ago|reply
[+] [-] swdunlop|12 years ago|reply
Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.
[+] [-] coldtea|12 years ago|reply
Or "got it" and didn't find it any that good, for the types of problems they work on.
[+] [-] harrytuttle|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dvirsky|12 years ago|reply
Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short:
1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever.
2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build.
3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own.
4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day.
The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :)
Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.
[+] [-] coldtea|12 years ago|reply
As it is, it's a PITA 20% of the time.
(Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).
[+] [-] tptacek|12 years ago|reply
[+] [-] stcredzero|12 years ago|reply
So, are we now in an era when there are lots of people in the job market who couldn't write a doubly-linked list to save their life?
When I was in my 20's, I noted that there were lots of programmers around who basically treated compilers as "magic" and hadn't the tiniest inkling about how they worked. Now that I'm in my 40's, I've noted "so what" attitudes in languages that require manual memory management. (iOS and Objective-C. ARC goes a long way, but it still doesn't take care of everything for you.)
[+] [-] bsaul|12 years ago|reply
About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?
[+] [-] rdudekul|12 years ago|reply
[+] [-] slaxman|12 years ago|reply
Disclaimer: I am a Rails developer. My views are therefore biased.
[+] [-] VeejayRampay|12 years ago|reply
That being said, Go really seems like an awesome language, I've dabbled some and I can't wait to get back to it.
[+] [-] fbomb|12 years ago|reply
[+] [-] oakaz|12 years ago|reply
What you are looking for is actually a productive community with a good module manager. This what Golang is missing.
(Golang fans: don't get me wrong, I use and love Go.)
[+] [-] st3fan|12 years ago|reply
Dropping a .war file in a directory is hard? Or am I missing something about 'modern' Java apps?
[+] [-] mwcampbell|12 years ago|reply
[+] [-] codezero|12 years ago|reply
[+] [-] lectrick|12 years ago|reply
[+] [-] bayesianhorse|12 years ago|reply
[+] [-] rubiquity|12 years ago|reply
[+] [-] dakimov|12 years ago|reply
[deleted]