Why I Program in Go(tech.t9i.in)
tech.t9i.in
Why I Program in Go
http://tech.t9i.in/2013/01/why-program-in-go/
20 comments
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps.
So I'll try to impart some understanding of why I would switch to Go from Java or C++.
First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So when compared to java and C++ in those dimensions it holds up just fine but that might not be enough to sway someone over to the Go camp.
It's about what else Go has:
* Go is a batteries included language. The stdlib has almost everything you need to get started much like python does.
* Go is fast for development. I mean really fast. I mean like using Lisp in a REPL fast (almost). I really can't express how fast it's development speed is adequately just trust me its really really fast. This is not just about how fast it compiles although that's part of it. (I've literally been able to write, compile, and run a go "script" faster than an equivalent python script.)
* Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
* Go is concise. There is no wasted typing. It's easy to read and it's easy to write. Every feature of the language is orthoganal. And it tells you quickly when you've done it wrong.
* Go does OO right. Code reuse through composition not inheritance. Polymorphism through interfaces not inheritance. I never have to worry about it with Go. C++ or java? yeah I've got some inheritance related war stories there.
All of these things exist in other languages but Go is the only language where they all exist together. This is reason enough to switch to Go but there's more.
Go's future is bright. I don't say this because it has celebrity tech people behind it. I say this because the foundation they are laying demonstrates the core team knows what they are doing. Here's some examples.
* Go comes with all the tools you need to programmatically understand Go code. Parser, Type checking, Static analysis is all available via the stdlib. As a result GoCode which adds IDE functionality to the EDITOR of your choice came on the scene very quickly. Java doesn't have this. C++ doesn't have this. Go made it possible to create an IDE as a service with minimal effort. Besides Gocode you also have gofmt. Never worry about code formatting again. gofmt will reformat it for you and it will never break your code. It's 100% safe. I am aware of no other language excepting lisp with this functionality.
Lastly I want to address your "a lot less powerful" comment. I think it's false. In now way is Go less powerful than Java. It's fast enough to be in the same league as java. It has a lower memory footprint than java. It compiles faster than java. And the language itself is if anything more powerful and expressive than java. It has closures, It has interfaces that are just as typesafe and yet easier to use than java.
In fact I'll sum it up in one word: Go is relaxing.
So I'll try to impart some understanding of why I would switch to Go from Java or C++.
First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So when compared to java and C++ in those dimensions it holds up just fine but that might not be enough to sway someone over to the Go camp.
It's about what else Go has:
* Go is a batteries included language. The stdlib has almost everything you need to get started much like python does.
* Go is fast for development. I mean really fast. I mean like using Lisp in a REPL fast (almost). I really can't express how fast it's development speed is adequately just trust me its really really fast. This is not just about how fast it compiles although that's part of it. (I've literally been able to write, compile, and run a go "script" faster than an equivalent python script.)
* Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
* Go is concise. There is no wasted typing. It's easy to read and it's easy to write. Every feature of the language is orthoganal. And it tells you quickly when you've done it wrong.
* Go does OO right. Code reuse through composition not inheritance. Polymorphism through interfaces not inheritance. I never have to worry about it with Go. C++ or java? yeah I've got some inheritance related war stories there.
All of these things exist in other languages but Go is the only language where they all exist together. This is reason enough to switch to Go but there's more.
Go's future is bright. I don't say this because it has celebrity tech people behind it. I say this because the foundation they are laying demonstrates the core team knows what they are doing. Here's some examples.
* Go comes with all the tools you need to programmatically understand Go code. Parser, Type checking, Static analysis is all available via the stdlib. As a result GoCode which adds IDE functionality to the EDITOR of your choice came on the scene very quickly. Java doesn't have this. C++ doesn't have this. Go made it possible to create an IDE as a service with minimal effort. Besides Gocode you also have gofmt. Never worry about code formatting again. gofmt will reformat it for you and it will never break your code. It's 100% safe. I am aware of no other language excepting lisp with this functionality.
Lastly I want to address your "a lot less powerful" comment. I think it's false. In now way is Go less powerful than Java. It's fast enough to be in the same league as java. It has a lower memory footprint than java. It compiles faster than java. And the language itself is if anything more powerful and expressive than java. It has closures, It has interfaces that are just as typesafe and yet easier to use than java.
In fact I'll sum it up in one word: Go is relaxing.
Oh, I don't doubt many things can be done much better in other languages than Java, only why stop at Go? Clojure pretty much hits every single one of your requirements, it's more modern and expressive than Go, gets concurrency better, and it's about as slower than Go as Go is slower than Java -- and getting faster. Also, you don't have to give up the monitoring and instrumentation the JVM gives you, as well as the vast Java ecosystem.
I'm not saying Go isn't better than Java -- I'm sure it is. My main point is this: if I want to relax, there are more relaxing languages than Go; if I really need JVM-like performance, I'd rather go with Java and not relax as much; and if I need both -- there's Clojure, Scala, Kotlin (soon).
This leaves one point: RAM footprint, which I'll concede. But stacking that against the JVM's monitoring and large ecosystem, I'll take the JVM any day. So, Go is nice. Really nice. But not nearly nice enough to even consider abandoning the JVM (unless you're memory-constrained, in which case the JVM was never an option).
Also:
> Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.
> Go comes with all the tools you need to programmatically understand Go code... Java doesn't have this.
It does since Java 6: http://docs.oracle.com/javase/6/docs/jdk/api/javac/tree/inde...
I'm not saying Go isn't better than Java -- I'm sure it is. My main point is this: if I want to relax, there are more relaxing languages than Go; if I really need JVM-like performance, I'd rather go with Java and not relax as much; and if I need both -- there's Clojure, Scala, Kotlin (soon).
This leaves one point: RAM footprint, which I'll concede. But stacking that against the JVM's monitoring and large ecosystem, I'll take the JVM any day. So, Go is nice. Really nice. But not nearly nice enough to even consider abandoning the JVM (unless you're memory-constrained, in which case the JVM was never an option).
Also:
> Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.
> Go comes with all the tools you need to programmatically understand Go code... Java doesn't have this.
It does since Java 6: http://docs.oracle.com/javase/6/docs/jdk/api/javac/tree/inde...
> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.
This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.
This to me makes Clojure less relaxing. In fact Clojure is not relaxing it's challenging which can be enjoyable but I wouldn't say it's what I want to do everyday for my job. Go I could easily see myself doing it everyday.
As I said Go has a lot of good qualities all in one package. Clojure has some of those qualities but not all of them.
The pointer to the compiler api is interesting. I hadn't seen it before. I don't see any way to serialize a source tree in there but that might be just for lack of searching. I wonder why things like gofmt and company don't exist in the java toolchain already. I mean outside of third party IDE's.
This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.
This to me makes Clojure less relaxing. In fact Clojure is not relaxing it's challenging which can be enjoyable but I wouldn't say it's what I want to do everyday for my job. Go I could easily see myself doing it everyday.
As I said Go has a lot of good qualities all in one package. Clojure has some of those qualities but not all of them.
The pointer to the compiler api is interesting. I hadn't seen it before. I don't see any way to serialize a source tree in there but that might be just for lack of searching. I wonder why things like gofmt and company don't exist in the java toolchain already. I mean outside of third party IDE's.
>> * I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.*
I don't want to join into a language war, but I wanted to point out two things with this statement:
1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
2- Rich Hickey worked on massive telephone systems and created Clojure, at least in (large) part, out of frustration of dealing with mutation.
So there's a long line of research backed by "real world" experience showing mutation not holding up well for concurrency. Erlang is another example.
Regardless, I do agree that immutability may not be what it is hyped up to be, especially if you are looking for the mythical silver bullet, but it most certainly isn't over-hyped if you compare it to mutation, and the ideas are still quite young and being tested. Give it 20 years and I suspect there will be another paradigm shift at some point.
I don't want to join into a language war, but I wanted to point out two things with this statement:
1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
2- Rich Hickey worked on massive telephone systems and created Clojure, at least in (large) part, out of frustration of dealing with mutation.
So there's a long line of research backed by "real world" experience showing mutation not holding up well for concurrency. Erlang is another example.
Regardless, I do agree that immutability may not be what it is hyped up to be, especially if you are looking for the mythical silver bullet, but it most certainly isn't over-hyped if you compare it to mutation, and the ideas are still quite young and being tested. Give it 20 years and I suspect there will be another paradigm shift at some point.
My point is that Go gives you the option of immutability. Not immutability or something in between. I frequently send messages using non reference types which incurs a copy but means that I don't have to worry about who owns this code. It's easy since Go has pointer and non pointer types. Java has reference types and you have to design the object to be immutable by hiding fields behind methods and using annotations. Clojure goes to the other extreme. Go sits in the middle. Which is relaxing.
Java has a keyword 'final' for immutable objects.
Go can't do immutable updates efficiently (yet) because it doesn't have a persistent data structure implementation for vectors, maps, sets, etc.
> 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years.
Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact that most of the concurrent code today runs on mutable structures shows that it can be done.
Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years.
Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact that most of the concurrent code today runs on mutable structures shows that it can be done.
Immutability has worked out really well for a lot of real-world systems built with Erlang.
The main (and close to only) user of Erlang was Ericsson, and here is what the Wikipedia has to say about it [1]:
"Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson"
Not exactly a strong endorsement for Erlang.
[1] http://en.wikipedia.org/wiki/Erlang_(programming_language)
"Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson"
Not exactly a strong endorsement for Erlang.
[1] http://en.wikipedia.org/wiki/Erlang_(programming_language)
"The ban caused Armstrong and others to leave Ericsson.[6] The implementation was open sourced at the end of the year (1998).[3] The ban at Ericsson was eventually lifted, and Armstrong was re-hired by Ericsson in 2004.[6]"
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.
Alright, I'm sure some people find Go's particular combination of features appealing. For me, a language has got to be so unbelievably awesome to consider leaving the JVM, and seeing that some of the most awesome languages target the JVM, that language better do something that would truly impress a veteran like me. There's only one non-JVM language that I'll use for some very specific applications, that I think is all that: Erlang.
I'm not sure if it's just a mindset thing or the stuff I've used it for, but I've never felt the immutability got in the way, it's one of the things I miss most when using other language.
> most Go objects are mutable and can still be passed as messages.
Go makes it easy to get right. It doesn't make you get it right.
Go makes it easy to get right. It doesn't make you get it right.
You claim (as I understand):
Edit: Fix spelling of "Clojure".
(Java + Clojure) > Go && (Java + Scala) > Go
Edit: Fix spelling of "Clojure".
My claim is that Go's advantages are far, far too small to outweigh not running on the JVM. (also, I think Clojure > Go -- no need for Java in the equation -- but that's not my main point)
You see the JVM as an asset. Many consider it a liability.
And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure.
These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other.
Might as well say, "MIT type with love for the JVM? Choose Clojure. New Jersey type with love for native code? Choose Go".
And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure.
These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other.
Might as well say, "MIT type with love for the JVM? Choose Clojure. New Jersey type with love for native code? Choose Go".
I realize I've started a pretty ridiculous language war; that was not my intent. But I still cannot understand why anyone would want to use a language that is mostly meant for non-constrained environments, does not provide some major productivity advantages over JVM languages while being slower than JVM languages. I would totally consider using use Go if it targeted the JVM.
You say some people consider the JVM a liability. Can you please explain why? As far as I can see, the JVM has two disadvantages: a high RAM footprint and a slow startup time. But on server-class hardware (and I believe that's probably the main environment for Go), it's hard to beat the JVM's performance, and nothing even comes close in providing similar monitoring. So -- and I'm asking this completely seriously -- why would anyone consider the JVM a liability in such an environment?
You say some people consider the JVM a liability. Can you please explain why? As far as I can see, the JVM has two disadvantages: a high RAM footprint and a slow startup time. But on server-class hardware (and I believe that's probably the main environment for Go), it's hard to beat the JVM's performance, and nothing even comes close in providing similar monitoring. So -- and I'm asking this completely seriously -- why would anyone consider the JVM a liability in such an environment?
I don't understand either. Let history decide, we use Clojure & Java for server-side stuff it saves us countless hours/problems.
[deleted]
I have another problem with the JVM and it's oracle.
>I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages.
Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage.
For example there is not one mature and complete web framework in Go. Several for all of Java/Scala/Clojure. There is no good RBDMS support in Go. As good as it gets for the JVM languages. Etc...
Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage.
For example there is not one mature and complete web framework in Go. Several for all of Java/Scala/Clojure. There is no good RBDMS support in Go. As good as it gets for the JVM languages. Etc...
Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.
That is a bit disingenuous. There is an SQL interface driver in the stdlib here[1]. There are several[2] implementations available which build apon it.
There are several[3] (scroll down to the relevant section) web frameworks too.
I personally tend to prefer using the gorilla toolkit[4], in combination with the stdlib http and templating stuff. It should be noted that my current usages for Go include an API service, command line tools, and a proxy. Certainly not much html generation going on there by any means.
[1]: http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/
There are several[3] (scroll down to the relevant section) web frameworks too.
I personally tend to prefer using the gorilla toolkit[4], in combination with the stdlib http and templating stuff. It should be noted that my current usages for Go include an API service, command line tools, and a proxy. Certainly not much html generation going on there by any means.
[1]: http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/
It depends what you want to build I guess. Go has a much smaller surface or things to learn if you know POSIX already. It's fast startup times makes it also a good contender for command-line tools.
+1 for alternative languages like Clojure and Scala.
I recently (more or less) shut down my consulting business to do other things and since I no longer need (so much) to fit in with customer's tool chains, I decided on Clojure as a great general purpose language that is also a lot of fun to develop with. I could make the same comment about Scala or JRuby if I had chosen either of those fine languages.
Really, the JVM ecosystem rocks.
I recently (more or less) shut down my consulting business to do other things and since I no longer need (so much) to fit in with customer's tool chains, I decided on Clojure as a great general purpose language that is also a lot of fun to develop with. I could make the same comment about Scala or JRuby if I had chosen either of those fine languages.
Really, the JVM ecosystem rocks.
I have a hard time believing anything can beat or even match the garbage collection performance of the JVM. Not that there is something special about the JVM, just that there have been _so_ many smart people working on the problem for so long now. And for good performance doing server tasks (ie, not computational tasks) exceptional GC is a must. Can a GO program handle a workload that creates tens/hundreds of thousands of objects per second for weeks or months without leaking memory? That's why I use Java. If I don't need that kind of performance, I use Ruby. I'm still just not sure where GO would fit into my workflow, though it looks really promising. Especially the concurrency model that you currently have to awkwardly bolt on to Java with something like Akka or JetLang.
I have to raise the eyebrow to that. I have had more GC problems with Java than any other language. Geniuses fuck up too, and when they do it's pronounced "OutOfMemoryError: PermGen space."
That error is specific for Sun/Oracle's JVM.
Remember Go doesn't have objects, it only has structs which are most likely (and should be, but I haven't verified) much lighter weight than the objects you might be used to in Java.
As far as the creating tens/hundreds of thousands of structs per second for weeks or months without leaking memory, I'll get back to you on that once my code has been active that long ;)
As far as the creating tens/hundreds of thousands of structs per second for weeks or months without leaking memory, I'll get back to you on that once my code has been active that long ;)
If you have something really intensive running GO, I genuinely would love to hear how it's going after some uptime. Thank you.
Go has optional stack allocation, which means the GC doesn't need to handle short lived objects.
You need to be commended for defending Go.
I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries...
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.
Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".
I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.
OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)
It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.
I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries...
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.
Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".
I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.
OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)
It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.
This is what systems administrators with grey beards thought in the 1990s. A moment's thought about what an attacker who can run a compiler can do instead of running a compiler should be enough to inform you about how silly the idea is in practice.
This is what systems administrators with grey beards thought in the 1990s. A moment's thought about what an attacker who can run a compiler can do instead of running a compiler should be enough to inform you about how silly the idea is in practice.
It may have slowed down the occasional attacker who had no access to a HP-PA RISC cross compiler for his platform. But in todays world there is no reason.
Well back in the 90s we kept the machines lean more because disk space was fucking expensive.
I'm not saying that minimal builds are silly, just that the idea of keeping compilers off systems as a security feature is.
> Funny thing about Go is that as a compiled language, folks often need
> to send the source-code to the deployment servers to compile on them too.
It is generally much easier to deploy a versioned statically compiled binary, compared to rolling out code to production in some languages (ruby, python, etc).
I don't know that I was defending Go so much as describing why someone would want to use it. It's fine for someone to say they really like the jvm. I like it to. Clojure and Scala are fun languages. The JVM has a lot of really cool technology behind it.
But when someone says they don't understand why someone else would want to do things differently I just naturally want to help them understand :-)
But when someone says they don't understand why someone else would want to do things differently I just naturally want to help them understand :-)
From my experience if you're running Linux on your local machine and Linux on your server then you can distribute a Go binary to your server and it will run fine. Even if they are different distros.
If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.
If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.
> Go error handling is not to be taken lightly
The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion.
Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions of lines of code, the software community is not going back to error codes.
The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion.
Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions of lines of code, the software community is not going back to error codes.
Go doesn't rely on return codes. Go has multiple return, and has error objects.
Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.
Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.
> Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too.
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.
> Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too.
Not in my experience. Nearly everyone I know who deploys Go code does it by shipping a binary. One of the benefits of static linking.
Not in my experience. Nearly everyone I know who deploys Go code does it by shipping a binary. One of the benefits of static linking.
Go is far more innovative than Dart. Dart is, roughly, "We want to have a Java-clone in the browser". Go actually makes an effort at cleaning up C while adding a structural OO model and building in concurrency.
I'm sorry, but calling Dart a Java-clone is a ridiculous assertion. Care to back it up?
+1. For me a killer feature is that I easily create executables for lin/mac/win on my machine and don't have any dependencies at all (JVM for example).
Oh, absolutely! Small executables would be a good fit for Go (provided you don't need a GUI, since AFAIK Go doesn't have a UI toolkit). Only, in that case, isn't a whole new language ecosystem a bit of an overkill to avoid some of the inconveniences you'll have using C/C++?
Sorry, I've yet to be shown a large enough class of problems where Go would give a significant enough an advantage to abandon rich and well-established ecosystems.
Look, there's no doubt Go is nice, and, as such, some people would use it for some tasks, just because it's there. But if I run a company building large software, why would I switch to an entirely new ecosystem that's incompatible with just about everything unless there is something spectacular that Go can do that no other solution can? Or, at the very least, something extremely hard that Go does very easily. Erlang, which is also incompatible with just about everything (though it might even be more compatible with C than Go is) does some spectacular things. If Go's killer feature is small console programs that don't require dependencies, then, well, it will see very little serious adoption.
Sorry, I've yet to be shown a large enough class of problems where Go would give a significant enough an advantage to abandon rich and well-established ecosystems.
Look, there's no doubt Go is nice, and, as such, some people would use it for some tasks, just because it's there. But if I run a company building large software, why would I switch to an entirely new ecosystem that's incompatible with just about everything unless there is something spectacular that Go can do that no other solution can? Or, at the very least, something extremely hard that Go does very easily. Erlang, which is also incompatible with just about everything (though it might even be more compatible with C than Go is) does some spectacular things. If Go's killer feature is small console programs that don't require dependencies, then, well, it will see very little serious adoption.
> Only, in that case, isn't a whole new language ecosystem a bit of an overkill to avoid some of the inconveniences you'll have using C/C++?
Sure. I've started from scratch and Go seemed to me like the perfect match (not that there aren't any other choices, but it came right into my front door and I said: why not?)
Sure. I've started from scratch and Go seemed to me like the perfect match (not that there aren't any other choices, but it came right into my front door and I said: why not?)
There are native compilers for Java as well, although not for free.
> Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.
I don't understand this: You claim you've used Haskell? Haskell beats Go's concurrency out of the water.
Not to mention conciseness...
I don't understand this: You claim you've used Haskell? Haskell beats Go's concurrency out of the water.
Not to mention conciseness...
And space leakiness...
None of my Haskell programs have any space leaks.
While go makes a lot of correctness bugs really easy to accidentally make, Haskell does make a certain class of leak easier to maker. I'd personally take a correct program that leaks in some scenario over an incorrect one that does the wrong thing.
While go makes a lot of correctness bugs really easy to accidentally make, Haskell does make a certain class of leak easier to maker. I'd personally take a correct program that leaks in some scenario over an incorrect one that does the wrong thing.
Just one point :
> C++ doesn't have this [Tools for writing IDEs quickly]
Well indeed it does, libclang does exactly that, and quite well. As a result, you have plugins for Vim, Sublime Text and others providing autocompletion and in editor compiltation and error reporting.
> C++ doesn't have this [Tools for writing IDEs quickly]
Well indeed it does, libclang does exactly that, and quite well. As a result, you have plugins for Vim, Sublime Text and others providing autocompletion and in editor compiltation and error reporting.
And it only took 25 years since the language was born for the those tools to become available!
In all seriousness, C++ is extremely difficult for automated tools to work with, including C++ compilers.
In all seriousness, C++ is extremely difficult for automated tools to work with, including C++ compilers.
How did you write a go script faster than a python script? That sounds intriguing.
The time it takes to 'go run' a go program is about the same as the time it takes to run a python program. If you are able to write Go code faster than Python code (that is the important "if". I can, some cannot. It's a personal thing.), then Go will be faster than python.
edit script in vim.
use :!go run %
It will compile and run the script so fast you will swear it was an interpreted language except it runs way faster than an interpreted language.
use :!go run %
It will compile and run the script so fast you will swear it was an interpreted language except it runs way faster than an interpreted language.
You have to write it first for the Go example (:w | !go run %). For Python and most interpreted languages you can simply do :w !python.
Go programs don't just use less memory, the language makes it possible to control memory allocations.
With the JVM-based languages I'm familiar with, it is difficult to control the memory allocation characteristics of you program, and typically the further the language deviates from the JVM's model (eg, Clojure and Scala) the more garbage must be generated (usually in doing= things like runtime type reflection).
All these allocations put pressure on the garbage collector and, fortunately, the JVM provides a few sophisticated garbage collectors. But even so, I am aware of some high profile companies whose JVM-based servers spend upwards of 80% of their CPU time in the garbage collector. It's just crazy.
On the other hand, the Go language and - critically - its libraries were designed to give the programmer control over the allocation patterns of the program. This creates less work for the GC, and leads to leaner services with predictable performance characteristics.
Go has other advantages over the JVM as a platform, but this is the critical one IMO.
With the JVM-based languages I'm familiar with, it is difficult to control the memory allocation characteristics of you program, and typically the further the language deviates from the JVM's model (eg, Clojure and Scala) the more garbage must be generated (usually in doing= things like runtime type reflection).
All these allocations put pressure on the garbage collector and, fortunately, the JVM provides a few sophisticated garbage collectors. But even so, I am aware of some high profile companies whose JVM-based servers spend upwards of 80% of their CPU time in the garbage collector. It's just crazy.
On the other hand, the Go language and - critically - its libraries were designed to give the programmer control over the allocation patterns of the program. This creates less work for the GC, and leads to leaner services with predictable performance characteristics.
Go has other advantages over the JVM as a platform, but this is the critical one IMO.
I don't see anything special in Go for commanding the GC, can you point me to these APIs?
Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.
To be fair, Java does escape analysis for this too. This isn't a difference between Java and Go.
Both the JVM and the CLR do this. This is not a Go technology.
In fact, in certain cases the JVM can detect type information and remove the allocation entirely by hoisting integer fields and the like into registers.
In fact, in certain cases the JVM can detect type information and remove the allocation entirely by hoisting integer fields and the like into registers.
It's not about escape analysis.
The programmer explicitly specifies when to use pointers. Whenever pointers are not used, the object is stored in-place (for example, on the stack, in the array or slice, or in the struct).
The programmer explicitly specifies when to use pointers. Whenever pointers are not used, the object is stored in-place (for example, on the stack, in the array or slice, or in the struct).
It's not about commanding the GC. It's about avoiding unnecessary allocations.
OK, can you be specific how this is done? What is the technical reason here?
For instance, in Go everything is passed by value. If you want to pass a reference, you must pass a reference type (like a pointer). This means that you can pass around structs without having to put them on the heap. In JVM-land, nearly everything is passed by reference, and the data must go on the heap.
Relatedly, in Go if you allocate an array of n values of type T, the size of that array in memory is n * sizeof(T), and the items are laid out sequentially in memory. There are no other bookkeeping data structures and no indirection.
Here's a story about one project's struggle with data structures and Java: http://marc.info/?l=git&m=124111702609723
Relevant quote:
Relatedly, in Go if you allocate an array of n values of type T, the size of that array in memory is n * sizeof(T), and the items are laid out sequentially in memory. There are no other bookkeeping data structures and no indirection.
Here's a story about one project's struggle with data structures and Java: http://marc.info/?l=git&m=124111702609723
Relevant quote:
JGit struggles with not having an efficient way to represent a SHA-1.
C can just say "unsigned char[20]" and have it inline into the
container's memory allocation. A byte[20] in Java will cost an
*additional* 16 bytes of memory, and be slower to access because
the bytes themselves are in a different area of memory from the
container object. We try to work around it by converting from a
byte[20] to 5 ints, but that costs us machine instructions.
The JVM does not support this, but the CLR does.
The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. And if high-profile companies have servers that spend 80% of the time in GC -- well, they must have really neglected their code. That's a result of poor software maintenance, and I doubt any language could help them.
> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
Really? I remember reading all kinds of problems when trying to run go on 32-bit machines, like: http://news.ycombinator.com/item?id=3805302
The 32-bit GC issue is an unfortunate shortcoming of the GC implementation, which will be resolved in Go 1.1 early this year. The issue was merely an artifact of dead simple conservative GC implementation.
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
You are correct, but the none of those problems happened on 64 bit machines which I find to be more prevalent these days.
Still, this story seems much more crazy than any other gc issue I have ever heard of with the jvm.
Sorry, but I am not sure I understand which pitfall you refer to here? Can you elaborate?
No... It's because Java totally sucks when objects go from Eden to Survivor and then needs to be GC'ed or from Eden to Survivor to Tenured and then needs to be GC'ed.
That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal is to be as close to the metal as possible, by allocating gigantic primitive arrays... Quite the contrary of your beloved GC dogma, where you think that creating objects as no impact and that slow GCs are necessarily the programmer's fault).
I realize from your various post that you did really drink the Java cool-aid and that no matter what's going to be said you'll always come touting Java as the best language out there.
I know Java well enough to criticize it.
I also have the impression that Go is used inside Google on some impressive tasks so I wouldn't be to quick to dismiss it.
That's the very reason why some trading companies who still insist on using Java do use methods where as few objects as possible are ever created and went on to invent things like the LMAX disruptor "pattern" (more like an anti-pattern, where the goal is to be as close to the metal as possible, by allocating gigantic primitive arrays... Quite the contrary of your beloved GC dogma, where you think that creating objects as no impact and that slow GCs are necessarily the programmer's fault).
I realize from your various post that you did really drink the Java cool-aid and that no matter what's going to be said you'll always come touting Java as the best language out there.
I know Java well enough to criticize it.
I also have the impression that Go is used inside Google on some impressive tasks so I wouldn't be to quick to dismiss it.
I'm not dismissing Go, and I'm not praising Java, and I've even admitted on this very thread that Go is better than Java, so there's really no need in trying to convince me of anything. All I'm saying is that Go isn't good enough -- if I really want fast development and expressivity, there are languages more expressive than Go (more so than Go is to Java), and if I really need top-notch performance, then Java is OK and comes with some absolutely useful advantages that Go doesn't offer. I see excellent use cases for Python, for Ruby, for Clojure, for Java and for C/C++. I just don't see compelling use cases for Go. I'm not dismissing it. It's really nice. I just think it's underwhelming.
And, BTW, if you think Go has some magic GC secrets that will make all (or even some) of the JVM GC problems go away -- I believe you're mistaken.
And, BTW, if you think Go has some magic GC secrets that will make all (or even some) of the JVM GC problems go away -- I believe you're mistaken.
It doesn't have secrets to make them go away, it focuses on helping people create less garbage.
I'm not sure what "impressive tasks" you mean, but I don't think that's true. I heard of people using Go, true, but the perf-heavy backends are all in C++.
If they are spending that kind of time in GC, they are doing something insane. They should send email to hotspot-gc-use and get it solved.
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/
For me, Go aside, I just don't want to deal with the JVM. Sure, VMs are great -- erlang has a nice one, iterations of the JVM are still nicer than they were circa 1998, etc. But, I've dealt with services web services in C/C++, PHP, Python, Go, Java, etc. 5-10 years ago, Java and it's assorted frameworks had it's place, but the intersection of Jetty, JBoss/Tomcat, Glassfish, and plain old Java apps muddied the waters about managing Java apps. If you use a framework, you will need to tweak memory settings to make sure things behave well.
I program to solve problems. I usually solve the problems in my head or on paper before doing any coding.There is usually a step afterwards during which I translate this solution into a given programming language. This step in Java is much harder than I would like.
The reason for this is that I feel I spend too much time doing taxonomy and managing complex relationships between different classes when programming in Java. This occurs in every programming language but I find Java is by far the most restrictive in this regard. I find go much more flexible, as much as python, and scheme even more so.
The end result is that I am more productive when programming in these languages and most importantly I feel that I am not doing as much busywork. This in turns makes programming more fun and rewarding.
The reason for this is that I feel I spend too much time doing taxonomy and managing complex relationships between different classes when programming in Java. This occurs in every programming language but I find Java is by far the most restrictive in this regard. I find go much more flexible, as much as python, and scheme even more so.
The end result is that I am more productive when programming in these languages and most importantly I feel that I am not doing as much busywork. This in turns makes programming more fun and rewarding.
For my day job I program in Java doing enterprise stuff, at home I enjoy dabbling in Go, D, Haskell and Clojure for personal projects.
Mainly because in my opinion it's a huge PITA to do command line stuff in Java and distributing class files/jars to other systems is a real pain especially when other instances have varying versions of the JVM running.
With Go I can just compile something on my machine and send the executable to another (running the same/similar OS) and I can be pretty sure it runs fine.
Java is great for large, long running applications like web apps and servers, but I don't think you can be as productive when knocking out one-off scripts/rough and ready prototypes.
Mainly because in my opinion it's a huge PITA to do command line stuff in Java and distributing class files/jars to other systems is a real pain especially when other instances have varying versions of the JVM running.
With Go I can just compile something on my machine and send the executable to another (running the same/similar OS) and I can be pretty sure it runs fine.
Java is great for large, long running applications like web apps and servers, but I don't think you can be as productive when knocking out one-off scripts/rough and ready prototypes.
Does Java do coroutines/green threads? No. At a deep architectural level, the segmented stack required to do green threads is what sets Go apart. And if it wasn't for this, Go could have just been another JVM language probably. I guess they felt this was important enough to justify building their own runtime.
>Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling?
You should really write a GO code to understand what the author means. Writing GO code has no frills. And I have seen nothing cooler than: http://gofmt.com/.
You should really write a GO code to understand what the author means. Writing GO code has no frills. And I have seen nothing cooler than: http://gofmt.com/.
Even if that's the case, Go just brings too little to the table. And if you think gofmt is cool, take a look at Project Jackpot [1], or its use in the NetBeans IDE [2].
[1] https://bitbucket.org/jlahoda/jackpot30/wiki/Home
[2] http://netbeans.org/kb/docs/java/editor-inspect-transform.ht...
[1] https://bitbucket.org/jlahoda/jackpot30/wiki/Home
[2] http://netbeans.org/kb/docs/java/editor-inspect-transform.ht...
You may as well argue that Brainfuck is just as good as scheme, since they are both Turing complete.
It is all about friction; either language/toolset will get the job done, but which will I find more enjoyable?
It is all about friction; either language/toolset will get the job done, but which will I find more enjoyable?
Those aren't in the stdlib. gofmt is. So is gofix, go vet, godoc and a host of other things. Batteries included means a lot.
> Those aren't in the stdlib. gofmt is.
Which also means that you can count on any Go code you find online to be formatted the same way too.
It's like PEP 8, except better, because it's a lot more widely enforced.
Which also means that you can count on any Go code you find online to be formatted the same way too.
It's like PEP 8, except better, because it's a lot more widely enforced.
Exactly. What you can reasonably expect from code in the wild makes a world of difference.
When I am working on personal projects that I have in C, I use `-Wall -Wextra -Werror -pedantic` (along with the strictest `-std=` that the particular project will allow), and it makes my development experience an order of magnitude more pleasant. However when I am working on C code that is primarily somebody else's, I rarely get the pleasure of expecting code neat enough to allow me to reasonably use those flags. This makes working in C a much less pleasant experience overall.
That Go goes further and is strict about style too is just brilliant.
When I am working on personal projects that I have in C, I use `-Wall -Wextra -Werror -pedantic` (along with the strictest `-std=` that the particular project will allow), and it makes my development experience an order of magnitude more pleasant. However when I am working on C code that is primarily somebody else's, I rarely get the pleasure of expecting code neat enough to allow me to reasonably use those flags. This makes working in C a much less pleasant experience overall.
That Go goes further and is strict about style too is just brilliant.
Have no fear, Go will not take your Java jobs away :)
"Java IDEs really get the job done"
That is utterly misleading. Java IDEs really get the Java job done. And, sadly, Java is a language of such an incredible verboseness and containing so many idiosynchrasies that it takes a lot of code to do things. And IDEs do certainly excel at this.
But you have to realize that a lot of the IDEs' functionalities when it comes to Java are really just work around Java's failures.
So, yes, I can fire IDEA and it shall allow me "easily" work around a 100 000 LOC codebase.
But if I can write the same program in 30 000 LOC of Go or 10 000 LOC of a Lisp dialect I think that there's still a jury out there trying to determine if Java IDEs are really that great.
So I don't doubt that IDEA / Eclipse is helping you in your Java + ORM + XML hell but there are other ways to develop applications. Mind you: it's a huge world out there and despite your beloved IDEs being so great there are still people not programming in Java.
Also the IDEs tend to suck quite a lot when we're talking about "non-Java JVM languages".
Btw I'm using IntelliJ since so long I don't remember if it was version 3 or 4 and I just bought version 12.
-- "Patterns means I have run out of language"
That is utterly misleading. Java IDEs really get the Java job done. And, sadly, Java is a language of such an incredible verboseness and containing so many idiosynchrasies that it takes a lot of code to do things. And IDEs do certainly excel at this.
But you have to realize that a lot of the IDEs' functionalities when it comes to Java are really just work around Java's failures.
So, yes, I can fire IDEA and it shall allow me "easily" work around a 100 000 LOC codebase.
But if I can write the same program in 30 000 LOC of Go or 10 000 LOC of a Lisp dialect I think that there's still a jury out there trying to determine if Java IDEs are really that great.
So I don't doubt that IDEA / Eclipse is helping you in your Java + ORM + XML hell but there are other ways to develop applications. Mind you: it's a huge world out there and despite your beloved IDEs being so great there are still people not programming in Java.
Also the IDEs tend to suck quite a lot when we're talking about "non-Java JVM languages".
Btw I'm using IntelliJ since so long I don't remember if it was version 3 or 4 and I just bought version 12.
-- "Patterns means I have run out of language"
Those are many of the same reasons I program in Go.
To add another:
* Go's build tools and the language's overall approach to building projects are fantastic.
For the vast majority of projects you don't need an external build manager like make. One of my least favorite bits of programming in C and C++, even when I was doing that on a daily basis years ago, was the huge morass of make/autoconf hell that would grow up around projects and would be very difficult to understand and reason about unless you were there for the entire project's development.
With Go open source projects (on git, svn, mercurial) much of the time you can just
To add another:
* Go's build tools and the language's overall approach to building projects are fantastic.
For the vast majority of projects you don't need an external build manager like make. One of my least favorite bits of programming in C and C++, even when I was doing that on a daily basis years ago, was the huge morass of make/autoconf hell that would grow up around projects and would be very difficult to understand and reason about unless you were there for the entire project's development.
With Go open source projects (on git, svn, mercurial) much of the time you can just
go get http://hosted-code-site/blah/(package)
cd (package)
go build
Actually, the "get" command implies "build" and "install", so it's just (a real example):
go get github.com/nf/todo
TIL.
Thanks, that's good to know. Another (related) wonderful thing about Go is how fast everything compiles, so fast that it never occurred to me that go get was building as part of the install.
Thanks, that's good to know. Another (related) wonderful thing about Go is how fast everything compiles, so fast that it never occurred to me that go get was building as part of the install.
With Go open source projects (on git, svn, mercurial) much of the time you can just
And have absolutely no version management or any way to indicate API changes (except for making a new repository for every API-breaking change).
And have absolutely no version management or any way to indicate API changes (except for making a new repository for every API-breaking change).
The ecosystem makes it more difficult to write bad software. Handle all of your errors, you can't put in things you don't use, it makes testing VERY easy, logging really easy, and if you have testing you have performance testing for free with it.
Not having version management is a real concern, but I solve that problem by forking the projects and updating manually as needed. Ubuntu and debian are soon going to be allowing you to install go packages with their package management systems if I'm not mistaken.
Not having version management is a real concern, but I solve that problem by forking the projects and updating manually as needed. Ubuntu and debian are soon going to be allowing you to install go packages with their package management systems if I'm not mistaken.
It's not practical to fork all projects if you have a lot of them. And Debian failed in packaging Python and Ruby libraries (IMHO). That's why I created http://gonuts.io
I have to agree that this is invaluable.
I just can't get that hyped about Go, but I will tell you (as a Rubyist, primarily) I've really been enjoying Rust. While they're not directly competing, my experience is similar to the author's PHP -> Go, which is why I comment. I have programmed significant projects in statically typed languages in the past, but this new batch of languages (Rust/Go/Scala/etc) are certainly neat.
As an ex-Ruby cum Node.js lover recently converted to Go...
Programming in Go, once it clicks, really does feel relaxing and productive. If you're a decent Node.js programmer, it's like stepping up to "Node Pro", in the sense that you work close to the metal with your web server so everything feels clean and easy to wrap your mind around.
But Go code is cleaner and tighter. The code formatting conventions contribute to that greatly, as well as the fact that you just don't have to pull in as much 3rd party code because so much functionality is already beautifully integrated.
There are a lot of positives about Go that reveal themselves over the first couple days of coding in it.
I do wish the documentation convention included not only a brief description each function, etc., but also a brief example.
By the way, I also evaluated Scala for a few days before settling on Go as my preference. I like Scala, but it quickly becomes a sprawling language as your explore it further, and frameworks like Play and Lift bring even more baggage along for the ride. The core language, on its own, was attractive, but overall, the experience just didn't have the compact, robust, completely under control, and nimble feeling that came with Go.
Oh ya, and the Go syntax felt ugly and awkward at first. That feeling quickly faded after a day of use, but it's worth mentioning because I bet it turns some people away from Go before they even get to the great parts.
Just my 3 cents worth.
Programming in Go, once it clicks, really does feel relaxing and productive. If you're a decent Node.js programmer, it's like stepping up to "Node Pro", in the sense that you work close to the metal with your web server so everything feels clean and easy to wrap your mind around.
But Go code is cleaner and tighter. The code formatting conventions contribute to that greatly, as well as the fact that you just don't have to pull in as much 3rd party code because so much functionality is already beautifully integrated.
There are a lot of positives about Go that reveal themselves over the first couple days of coding in it.
I do wish the documentation convention included not only a brief description each function, etc., but also a brief example.
By the way, I also evaluated Scala for a few days before settling on Go as my preference. I like Scala, but it quickly becomes a sprawling language as your explore it further, and frameworks like Play and Lift bring even more baggage along for the ride. The core language, on its own, was attractive, but overall, the experience just didn't have the compact, robust, completely under control, and nimble feeling that came with Go.
Oh ya, and the Go syntax felt ugly and awkward at first. That feeling quickly faded after a day of use, but it's worth mentioning because I bet it turns some people away from Go before they even get to the great parts.
Just my 3 cents worth.
> I do wish the documentation convention included not only a brief description each function, etc., but also a brief example.
It is getting there. If you run godoc locally with tip, you will find many more examples than there were previously.
See http://golang.org/pkg/path/ for a current example. And the source for those examples can be found here: http://golang.org/src/pkg/path/example_test.go. Note that this technique will work for your own packages as well.
The technology is there, the implementation is still incomplete; but more progress has been made than is easily visible.
It is getting there. If you run godoc locally with tip, you will find many more examples than there were previously.
See http://golang.org/pkg/path/ for a current example. And the source for those examples can be found here: http://golang.org/src/pkg/path/example_test.go. Note that this technique will work for your own packages as well.
The technology is there, the implementation is still incomplete; but more progress has been made than is easily visible.
The golang website supports other versions; to see the docs for tip go to http://tip.golang.org/
I love Go for many of the same reasons as the author. Go's fantastic performance doesn’t' hurt either. :)
These micro-benchmarks match what I have seen in the real world:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
These micro-benchmarks match what I have seen in the real world:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
They sure do. Slower than Scala and requiring more code and lacking the awesome power of the JVM. Great choice, indeed.
Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action.
Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :)
P.S. If Go didn't exist I would still be using Java/C#/C/C++ for everything. (I still use Haskell/Prolog where needed)
Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :)
P.S. If Go didn't exist I would still be using Java/C#/C/C++ for everything. (I still use Haskell/Prolog where needed)
> Yeah- that is great as long as you don't care about using 30x times more memory....
> Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t....
There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).
There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).
Makes me wonder why people don't use Free Pascal more ... It shares many of Go's advantages described here (simple language, powerful libraries) and is frequently faster and uses less memory (8KB memory in 4 cases where Go uses 700-1200KB!) on the Benchmark Game programs. It's probably the C-like syntax that tips the scales every time ...
Nothing complicated -- Pascal has been out-of-fashion for many decades.
These measurements show Go programs using more memory than the corresponding Java programs, please explain how that fits with your "awesome bloat" remark.
k-nucleotide 260,908KB vs Java program 167,924KB
regex-dna 679,836KB vs Java program 621,712KB
binary-trees 565,076KB vs Java program 528,364KB
and not much difference for this
reverse-complement 249,304KB vs Java program 298,904KB
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
For tiny tiny programs that only allocate a few KB, the default JVM allocation swamps what the programs use -- that changes when programs need to allocate memory.
k-nucleotide 260,908KB vs Java program 167,924KB
regex-dna 679,836KB vs Java program 621,712KB
binary-trees 565,076KB vs Java program 528,364KB
and not much difference for this
reverse-complement 249,304KB vs Java program 298,904KB
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
For tiny tiny programs that only allocate a few KB, the default JVM allocation swamps what the programs use -- that changes when programs need to allocate memory.
Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool.
And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
When your commandline tool needs several seconds CPU to complete the task, JVM startup time is irrelevant.
The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds.
So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a larger workload take 32.1secs compared to 23.5secs for the Scala program.
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds.
So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a larger workload take 32.1secs compared to 23.5secs for the Scala program.
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
> When your commandline tool needs several seconds CPU to complete the task
And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect.
I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect.
I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
Now you are telling us -- it depends :-)
The memory consumption is probably mostly due to the JVM's GC implementation that can be very finely tuned (although large RAM footprint surely is a feature of the JVM). Some of the bloat is, true, baggage that's been accumulated through the years, but that's being taken care of in Java 9. And the rest of the "bloat" is there for a reason. Let me put it this way: if you have a program that absolutely requires JVM performance, it probably requires the "bloat" as well, as it gives you runtime instrumentation, advanced debugging hooks and other sorts of invaluable monitoring tools.
I agree about the great tools, I have used them.
But for being so simple Go gives you a lot of tools as well: http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/net/http/pprof/ http://blog.golang.org/2011/06/profiling-go-programs.html Go also has gdb support I used from my IDE (http://golang.org/doc/gdb)
But for being so simple Go gives you a lot of tools as well: http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/net/http/pprof/ http://blog.golang.org/2011/06/profiling-go-programs.html Go also has gdb support I used from my IDE (http://golang.org/doc/gdb)
I want to try out Go...but I have to make one initial observation...It can be somewhat hard to Google (ironically) for Go programming examples. I'm sure there's some tinkering you can do in your search query to get slightly better results, but "Go" is a difficult proper pronoun to facet a search around.
https://www.google.com/search?q=go+facial+recognition
https://www.google.com/search?q=python+facial+recognition
https://www.google.com/search?q=go+facial+recognition
https://www.google.com/search?q=python+facial+recognition
Golang is pretty popular to search with. Also an interesting thing to note is the main page (golang.org) has an awesome amount of information.
Couple that in with a few Google I/O videos on Youtube and you seriously have enough information that you almost don't have to Google for anything.
Couple that in with a few Google I/O videos on Youtube and you seriously have enough information that you almost don't have to Google for anything.
They seriously need to implement
go ogle <packagename>search for golang, most relevant resources will be found with this term.
Edit: also, for package discovery, godoc.org. But golang+anything usually works.
Edit: also, for package discovery, godoc.org. But golang+anything usually works.
I was wrong to doubt Google's foresight.
This was never a problem for me when I was using go. Just use golang in your search terms.
> Now, you might want to ... acquaint yourself with [dataflow variables and declarative concurrency] because [they are] the centre-piece of Go's language features.
Not so. Go has native support for neither dataflow variables nor declarative concurrency. Go does have native support for message-passing concurrency--but that's different.
Not so. Go has native support for neither dataflow variables nor declarative concurrency. Go does have native support for message-passing concurrency--but that's different.
You're right about that. However, I find it easier to understand Go's concurrency model by starting with dataflow and then adding one more requisite (channels), than starting with classic fork-and-join and then making a bigger jump to message passing concurrency.
"Earlier I mentioned about the JVM being a bad trade-off for phantom portability. In practice, non-trivial Java programs also require porting for different systems."
I have used Java since the beginning (and I have written several Java books). I have had very few portability problems. The JVM is a great ecosystem that supports several fine programming languages.
I have used Java since the beginning (and I have written several Java books). I have had very few portability problems. The JVM is a great ecosystem that supports several fine programming languages.
If anyone is interested in learning go, my site has a compiled list of tutorials and so on
http://pineapple.io/resources/tagged/go-language?type=tutori...
http://pineapple.io/resources/tagged/go-language?type=tutori...
I have been unable to find a good web server tutorial. Everything seems to be listen, process page, done, repeat. This doesn't seem to allow multiple connections at once, especially if the process page process takes a long time.
Go's net/http package is concurrent behind the scenes; each request is handled in a separate goroutine. You just write your HTTP handlers in the obvious way and the concurrency is taken care of by the runtime.
http://golang.org/doc/articles/wiki/
http://golang.org/doc/articles/wiki/
The recent five-part tutorial on Go that ran in Dr. Dobb's also has articles worth linking to: http://www.drdobbs.com/240008277
Added
Java is perhaps the most depressing language I've ever programmed in.
I'd have to agree with him there.
I'd have to agree with him there.
> Scalars (integers, characters, strings, floats, booleans), sequences (lists/arrays) and maps (key-value pairs) as built-ins are enough to support almost all data models.
There is some wisdom in Larry Wall's decision to make scalars, lists, and maps the main data structures in the Perl programming language and to give them the sigils $, @, %. The considerable wealth of Perl libraries available on CPAN today demonstrates that you can support essentially all data models using these three data types.
There is some wisdom in Larry Wall's decision to make scalars, lists, and maps the main data structures in the Perl programming language and to give them the sigils $, @, %. The considerable wealth of Perl libraries available on CPAN today demonstrates that you can support essentially all data models using these three data types.
Go nails code readability and documentation better than any other language I'm aware of.
For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/.
5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.org/src/pkg/container/list/list.go, and you're presented with very readable source code.
Now compare this with Java. I just Google'd Java List. First link is this: http://docs.oracle.com/javase/6/docs/api/java/util/List.html
Documentation looks OK, but wait, this is the interface. I want to see docs for a concrete implementation. I'm tempted to click on the AbstractList link, but oh wait, that's just another non-concrete class that other List classes probably inherit from. Let's see, let's go to the ArrayList ... this looks good. http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList...
Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ...
Let's try Scala. Google "Scala List". Click on first link. http://www.scala-lang.org/api/current/index.html#scala.colle...
What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"
Oh sweet, this thing has all kinds of methods, i.e. ++, ++:, +:, /:, :+, ::, :::, :\
Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.
Looking back to the Go documentation, I immediately "relax" as another commenter put it.
For some reason, I think Scala will end up being the next Java. It has so much momentum, runs on the JVM, has seamless interop with Java code. Has the Play Framework, AKKA, and thousands of other awesome libraries written for it. And if Scala powers Twitter, then I think this answers the scalability and concurrency question.
While I'm bullish on Scala, at the end of the day, I find Go's simplicity make it more beautiful than any other language.
For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/.
5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.org/src/pkg/container/list/list.go, and you're presented with very readable source code.
Now compare this with Java. I just Google'd Java List. First link is this: http://docs.oracle.com/javase/6/docs/api/java/util/List.html
Documentation looks OK, but wait, this is the interface. I want to see docs for a concrete implementation. I'm tempted to click on the AbstractList link, but oh wait, that's just another non-concrete class that other List classes probably inherit from. Let's see, let's go to the ArrayList ... this looks good. http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList...
Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ...
Let's try Scala. Google "Scala List". Click on first link. http://www.scala-lang.org/api/current/index.html#scala.colle...
What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"
Oh sweet, this thing has all kinds of methods, i.e. ++, ++:, +:, /:, :+, ::, :::, :\
Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.
Looking back to the Go documentation, I immediately "relax" as another commenter put it.
For some reason, I think Scala will end up being the next Java. It has so much momentum, runs on the JVM, has seamless interop with Java code. Has the Play Framework, AKKA, and thousands of other awesome libraries written for it. And if Scala powers Twitter, then I think this answers the scalability and concurrency question.
While I'm bullish on Scala, at the end of the day, I find Go's simplicity make it more beautiful than any other language.
>Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ...
If you were using Java the way people do in the real world, from your IDE, you'd already be looking at the source code.
>What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"
It's an abstract class (generic, and covariant in that generic parameter) that implements some interfaces. It's not hard.
>Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.
Take it one word at a time, it's pretty easy. Value - a value. Member - a member of the class. Shadowed - perhaps a scala-specific term, but it means it's in some parent class but hidden because it's also defined in this class. Implicit may be a new and scary concept, but it's pretty core to scala; if you use the language you get familiar with it pretty quickly.
If you were using Java the way people do in the real world, from your IDE, you'd already be looking at the source code.
>What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"
It's an abstract class (generic, and covariant in that generic parameter) that implements some interfaces. It's not hard.
>Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.
Take it one word at a time, it's pretty easy. Value - a value. Member - a member of the class. Shadowed - perhaps a scala-specific term, but it means it's in some parent class but hidden because it's also defined in this class. Implicit may be a new and scary concept, but it's pretty core to scala; if you use the language you get familiar with it pretty quickly.
Right, you know exactly where everything is when it's your own messy room, but if an outsider wanders in, he can't tell the bed from the curtains.
I grant that there is sometimes a necessary tradeoff between power/abstraction and readability, but readability is still extremely important, and you can't just handwave away confusing language constructs and documentation with "it's obvious after you code in the language for a couple years". Simplicity and intuitiveness are powerful features in themselves.
I grant that there is sometimes a necessary tradeoff between power/abstraction and readability, but readability is still extremely important, and you can't just handwave away confusing language constructs and documentation with "it's obvious after you code in the language for a couple years". Simplicity and intuitiveness are powerful features in themselves.
I don't think we're not talking a couple of years, more like weeks or days.
How many actually new concepts are there? "sealed" (very simple, but ok it doesn't exist in other languages), "+A" for covariance (genuinely new, but you can ignore it until you want to use it). "with" for multiple inheritance I guess is new, but it works the same as "extends" inheritance (you might have questions about how it handles diamonds, but there aren't any here). Values and members should be familiar, as should the concept of shadowing if not the name (but there's not really a standard term for it).
Implicits are genuinely new, and genuinely complicate the code; I think of them the same way I think of lisp macros (they're too powerful, they're too easy to make the code incomprehensible with - but they enable things that we can't live without, and that we haven't found a safe way of allowing yet). But even then, the concept is very simple and easy to understand.
A big block of text with lots of unfamiliar words in is intimidating, but I don't think it's truly confusing or unreadable if you just take your time and actually try and read it.
How many actually new concepts are there? "sealed" (very simple, but ok it doesn't exist in other languages), "+A" for covariance (genuinely new, but you can ignore it until you want to use it). "with" for multiple inheritance I guess is new, but it works the same as "extends" inheritance (you might have questions about how it handles diamonds, but there aren't any here). Values and members should be familiar, as should the concept of shadowing if not the name (but there's not really a standard term for it).
Implicits are genuinely new, and genuinely complicate the code; I think of them the same way I think of lisp macros (they're too powerful, they're too easy to make the code incomprehensible with - but they enable things that we can't live without, and that we haven't found a safe way of allowing yet). But even then, the concept is very simple and easy to understand.
A big block of text with lots of unfamiliar words in is intimidating, but I don't think it's truly confusing or unreadable if you just take your time and actually try and read it.
> Go nails code [cut] documentation better than any other language I'm aware of.
That's because you haven't seen PHP's documentation.
Look at your Go's list example.
It doesn't even show how to create a list and fill it with items.
It doesn't have users' comments.
It doesn't explain much about the data structure. Can it be a circular doubly link list, for instance?
Is there a method to empty the list, or quickly insert more than one element?
Instead it has strangely named sections (like "type Element") that aren't obvious to somebody new to the language.
Sorry, but this documentation is shit.
That's because you haven't seen PHP's documentation.
Look at your Go's list example.
It doesn't even show how to create a list and fill it with items.
It doesn't have users' comments.
It doesn't explain much about the data structure. Can it be a circular doubly link list, for instance?
Is there a method to empty the list, or quickly insert more than one element?
Instead it has strangely named sections (like "type Element") that aren't obvious to somebody new to the language.
Sorry, but this documentation is shit.
That's a bit harsh. Library docs are for users of the language. I grant that the list package could use more docs (I personally find it a bad example) but for someone who knows Go, all the important stuff is there.
Juba surprised that you rate the PHP docs so highly, particularly the user comments. Typically those comments contain terrible advice!
Juba surprised that you rate the PHP docs so highly, particularly the user comments. Typically those comments contain terrible advice!
Users' comments are important to figure out unusual behaviors, bugs, edge cases, to clarify documentation in general, and to add code examples. Of course, some of them will be incorrect and bad advice, that's why I think PHP docs should add up/down voting on each post.
More than anything, it creates the sense of community. You always know there are people reading and writing stuff about a specific method, and, most of the time, it's helpful.
Considering how bad and inconsistent PHP is, their documentation is amazing.
More than anything, it creates the sense of community. You always know there are people reading and writing stuff about a specific method, and, most of the time, it's helpful.
Considering how bad and inconsistent PHP is, their documentation is amazing.
Documentation is for documentation by the people who implement the language and know how it should be best used. User comments on official documentation are likely to have tons of different coding styles, so a new user would pick up a lot of bad habits.
If all of the docs are written by go developers/contributors who know that the code in examples should be consistent, then all those bad habits aren't ingrained in new users.
Something golang has that I don't know anyone else has is this:
http://talks.golang.org/2012/concurrency.slide#1
Also another thing about Go, is the source code for each of those packages is extremely easy to understand... it's truly self documenting... there's also the option of looking at the list_test.go file.
I will admit a method to empty the list as well as insert more than one element would be nice.
If all of the docs are written by go developers/contributors who know that the code in examples should be consistent, then all those bad habits aren't ingrained in new users.
Something golang has that I don't know anyone else has is this:
http://talks.golang.org/2012/concurrency.slide#1
Also another thing about Go, is the source code for each of those packages is extremely easy to understand... it's truly self documenting... there's also the option of looking at the list_test.go file.
I will admit a method to empty the list as well as insert more than one element would be nice.
"Sorry, but this documentation is shit."
Yes, they are short of useful examples but, then, so are the PHP docs. Worse than that I find most of the user comments on the PHP docs are noise: self-proclaimed PHP gurus trying to out-clever each other.
The Go Library docs have one major advantage: you can click on the supplied link to see the simple, understandable implementation.
I am C and lisp fan and think OOP as non-sense. I used python a bit but hate its performance. Can I still get something from Go that can not be provided by C and lisp?
Does go provide great flexibility by C and lisp?
BTW, I think emacs is the best IDE so I do not care any tools/IDEs at all.
If you're a C programmer then you will enjoy Go. Try it.
Go is a bit like C but it has GC so it depends on how much you value the fine degree of control of memory allocation that you get with C.
Personally I think Go has a lot cleaner syntax than C and the tools give a lot more "friendly" error messages when compiling your applications.
You do still get nullpointerexception runtime errors though but that's an inherent problem with the nil/null type.
Personally I think Go has a lot cleaner syntax than C and the tools give a lot more "friendly" error messages when compiling your applications.
You do still get nullpointerexception runtime errors though but that's an inherent problem with the nil/null type.
Thanks for replying. It seems GO is not for me at least now. What I want is an optional strong typed script language with highest performance. Lisp serves me well here.
I have only three real things to care about a language:
1. Performance and thus optional strong typed is required. Go can have optional strong typed system, so performance may be improved in future, but its GC seems a big warning for me. I want to have option to allocate/free memory myself. the GC is also an enforcement of some design principle, which is also a big minus regarding the next point.
2. Great flexibility, basically the language should not make any decisions for developers. I dislike C++ for its OOP approach to make way too many decisions for developer. I want no limitation from a language. I can self restrain to avoid all troubles from freedom, I can design OOP/GC myself if it is neccessary, but please not make decision for me. (C++ did not enforce OOP, but most of the extra part beyond C usually distorts a good design otherwise) Lisp and C are almost perfect here. Does GO allow any weird design people may think of? any enforcement of some supposed-to-be good principle?
3. A script, which can relieve me on all details. Occasionally, I may not care performance, and I want life easy. Python is prety good here. Lisp is good but lack of compiling on ARM machines is a big disadvantage.
I have only three real things to care about a language:
1. Performance and thus optional strong typed is required. Go can have optional strong typed system, so performance may be improved in future, but its GC seems a big warning for me. I want to have option to allocate/free memory myself. the GC is also an enforcement of some design principle, which is also a big minus regarding the next point.
2. Great flexibility, basically the language should not make any decisions for developers. I dislike C++ for its OOP approach to make way too many decisions for developer. I want no limitation from a language. I can self restrain to avoid all troubles from freedom, I can design OOP/GC myself if it is neccessary, but please not make decision for me. (C++ did not enforce OOP, but most of the extra part beyond C usually distorts a good design otherwise) Lisp and C are almost perfect here. Does GO allow any weird design people may think of? any enforcement of some supposed-to-be good principle?
3. A script, which can relieve me on all details. Occasionally, I may not care performance, and I want life easy. Python is prety good here. Lisp is good but lack of compiling on ARM machines is a big disadvantage.
You might get a bit of mileage out of 3., you can write go applications quite quickly and the optional typing makes it feel script-ish.
Also Go does compile on ARM.
Also Go does compile on ARM.
Thus far I feel that, if any language was ever going to replace C, it's probably Go. In a way I sympathize with Go. I like it for the compactness and simplicity. Those are two design decision which seem to be unique among modern languages and exactly the two things I like most about C.
I prefer to use Hypescript for all my kickass cloud deployments.
His second point is, to me, the most important for would-be language designers:
Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier.
This is a godsend. The best thing to have happened to our industry since a very long time.
But his first point is oversimplified:
The compiler not only checks for code that can theoretically result in a runnable program...
It's not exactly as if Go did solve the halting problem or we'd ALL be using Go. So I think a bit more in-depth explanation would have been welcome.
Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier.
This is a godsend. The best thing to have happened to our industry since a very long time.
But his first point is oversimplified:
The compiler not only checks for code that can theoretically result in a runnable program...
It's not exactly as if Go did solve the halting problem or we'd ALL be using Go. So I think a bit more in-depth explanation would have been welcome.
In a certain sense, languages like Agda do solve the halting program, but we're not all using them...
Seeing more total languages used in industry would be pretty cool.
Seeing more total languages used in industry would be pretty cool.
Slight correction
> The compiler not only checks for code that can theoretically result in a [logically correct], runnable program...
Some examples of this:
- If you try to assign to a variable that will never be read, this is a compile-time error.
- If you try to import a module that will never be used, this is a compile-time error.
- If your dependencies don't form a DAG, this is a compile-time error.
Incidentally, not only does this make runtime errors (or logical errors) much less common, it also makes Go code more readable and vastly contributes to its impressive compilation speed.
> The compiler not only checks for code that can theoretically result in a [logically correct], runnable program...
Some examples of this:
- If you try to assign to a variable that will never be read, this is a compile-time error.
- If you try to import a module that will never be used, this is a compile-time error.
- If your dependencies don't form a DAG, this is a compile-time error.
Incidentally, not only does this make runtime errors (or logical errors) much less common, it also makes Go code more readable and vastly contributes to its impressive compilation speed.
If the biggest gain for the language is a formatting utility then that language is not worth learning.
What is the "biggest" gain a language can have is a matter of taste. Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly.
That you do not value those things as highly is not particularly profound. It doesn't mean that he is wrong to be excited about that, nor that he is excited about the wrong language, nor even that there is no reason for you to be excited about that language. It only means that there is no reason for you to be excited about that language for that particular reason.
That you do not value those things as highly is not particularly profound. It doesn't mean that he is wrong to be excited about that, nor that he is excited about the wrong language, nor even that there is no reason for you to be excited about that language. It only means that there is no reason for you to be excited about that language for that particular reason.
> Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly.
Not really. Someone who values those things highly would have written the code as such, instead of relying on a utility to reformat the code.
Not really. Someone who values those things highly would have written the code as such, instead of relying on a utility to reformat the code.
Are you being purposefully obtuse? Do we really all just use and read our own code and not the code of others?
Having `gofmt` drastically increases the probability that any particular Go program has the same style/formatting that you're used to.
Having `gofmt` drastically increases the probability that any particular Go program has the same style/formatting that you're used to.
The formatting utility is really just a side effect of the decisions to Go team made regarding syntax and semantics in the language. There's also a tool to automatically update your code if the language changes (this was important during the days of rapid churn, where your programs would break every week).
They made some very opinionated choices and have largely stuck by them. You can't have an unused variable, it just won't compile. What a pain, right? Well, if there's one thing I've learned from compiling open source code, it's that you CANNOT trust programmers to clean up their code before releasing it--just play "count the unused variable warnings" next time you compile pretty much any Linux program.
They made some very opinionated choices and have largely stuck by them. You can't have an unused variable, it just won't compile. What a pain, right? Well, if there's one thing I've learned from compiling open source code, it's that you CANNOT trust programmers to clean up their code before releasing it--just play "count the unused variable warnings" next time you compile pretty much any Linux program.
The biggest gain is coroutines which are easy to add to your application. No imports, no convoluted thread initialisation just
go myMethod()It feels like Go is the new Fortran.
We don't care you why program in Go.
I care
exactly. Wonder how many of these are upvoted by Google staff.
EDIT: and dissent downvoted by google staff?
EDIT: and dissent downvoted by google staff?
Whenever Go is compared to Java, the arguments in its favor seem kind of fuzzy. After all, one of the motivations behind Go was a C-like language with far better compilation time than C++. And Java already fits the bill. So, yeah, Go is leaner and more modern -- but certainly not by an order of magnitude, like other JVM languages. Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling? Because Java IDEs really get the job done), frameworks etc. But those things are simply the result of years of changing fashions. Newer Java "frameworks" are just as lean-and-mean as Go.
There are so many new and exciting languages around, but Go seems to carry the least "oomph" of the lot. It's basically Java. A little nicer; a little slower; a lot less powerful.