Why I Program in Go
tech.t9i.in
tech.t9i.in
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.
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/.
[1] https://bitbucket.org/jlahoda/jackpot30/wiki/Home
[2] http://netbeans.org/kb/docs/java/editor-inspect-transform.ht...
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.
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.
It is all about friction; either language/toolset will get the job done, but which will I find more enjoyable?
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.
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.
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...
Go makes it easy to get right. It doesn't make you get it right.
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 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.
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.
"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)
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.
(Java + Clojure) > Go && (Java + Scala) > Go
Edit: Fix spelling of "Clojure".
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".
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?
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...
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/
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 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.
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).
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.
Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the size of a full 42u rack).
I miss those days.
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 :-)
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.
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.
If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.
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.
Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.
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 ;)
I don't understand this: You claim you've used Haskell? Haskell beats Go's concurrency out of the water.
Not to mention conciseness...
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.
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.
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?)
> 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.
In all seriousness, C++ is extremely difficult for automated tools to work with, including C++ compilers.
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.
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.
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.
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).
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.
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 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.
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.
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"
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.
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.
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
go get github.com/nf/todo
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.
And have absolutely no version management or any way to indicate API changes (except for making a new repository for every API-breaking change).
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.
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.
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.
These micro-benchmarks match what I have seen in the real world:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
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)
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)
And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
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...
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.
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%).
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.
Edit: also, for package discovery, godoc.org. But golang+anything usually works.
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.
go ogle <packagename>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.
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.
http://pineapple.io/resources/tagged/go-language?type=tutori...
I'd have to agree with him there.
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.
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.
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.
Juba surprised that you rate the PHP docs so highly, particularly the user comments. Typically those comments contain terrible advice!
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.
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.
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.
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.
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.
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.
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.
Also Go does compile on ARM.
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.
Seeing more total languages used in industry would be pretty cool.
> 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.
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.
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.
Having `gofmt` drastically increases the probability that any particular Go program has the same style/formatting that you're used to.
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.
go myMethod()EDIT: and dissent downvoted by google staff?