Go 1 Release Candidate 1
groups.google.com
groups.google.com
Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.
This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.
1. Do not use #include (especially in combination with C++ template instantiation)
2. Do not use a heavily optimizing compiler backend
The first point is fixed in every other modern language as well, so it is only an advantage over C/C++. Go will become somewhat slower, because people want free lunch, so at some point i expect LLVM or GCC will be used as the official backend. Does anybody use TinyCC for his C programs?
I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.
Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.
The gc suite doesn't produce code as tight as gcc, but almost no code in the world is CPU bound, everything is I/O bound.
Please check package syscall, specifically src/pkg/syscall/dll_windows.go. You will see for yourself, how it is implemented.
Optimization takes a massive proportion of compile time these days. This is something the Google Go designers didn't understand because they had been programming for decades using a mostly unoptimizing compiler (for plan 9).
Go is designed to handle dependencies between objects in such a way so that it scales O(n).
The Solaris/OpenSolaris/illumos build builds with two compilers at the same time. The Sun/Oracle proprietary compiler that generates better code, and GCC. GCC generated binaries are not usually used, instead GCC is used a shadow compiler to catch potentially not portable statements.
You will find that if you disable GCC and build with only one compiler, build time decreases by 2%, not 50% as you might have expected.
Any language with modules is equally fast, only languages the use the C #includes mechanism are slow, because each #include needs to be imported and processed each time it is seen.
Turbo Pascal, Modula and Ada compilers were already running circles around C compilers back in the day.
Btw, The Plan 9 C compilers, which are also included with the Go distribution, also compile C as fast as the Go compiler compiles Go. Both compilers were written by Ken Thompson.
There are compilers faster than the Go compilers in terms of lines compiled per second. Even Python parses code faster than the Go compiler, however, Go builds large, real life projects, faster because it is the only implementation that scales linearly with the number of components, other scale O(n^2)
Turbo Pascal, Modula, and Ada, which you bring into discussion may have had fast compilers, but the build process was still O(n^2), not O(n).
Using URLs to identify external libraries also isn't something I'm very fond of. Both because you'd have more boilerplate to type when using them, and suddenly the library is fixed to a certain internet location and VCS.
Meh, I can go on ranting about other things I dislike about Go, but it wouldn't solve anything. I'll just keep monitoring the developments from the sideline and see how things evolve over time.
- No generics.
- No exceptions.
- No inheritance.
- Nullable pointers.
- No decimal types (yet they put in complex!)
- No IDE.
- No support for GUI applications on Microsoft Windows.
- Go ignores years of academic research on language design.
Please ignore the people who are happily productive with the language :).
- Forcing one brace style - Forcing naming conventions to a certain extent - To use the Go tool you are required to have your directories set up in a specific way - All types are not equal: No support for using user defined types as map keys, maps are generic, but user defined types are not - Two initialization functions, new and make. One returns a pointer, the other a struct. Seeing as go makes no distinction between the stack and the heap, is there need for two.
Convention over configuration is great and all, but it really felt as if it was being used as an excuse to force me to use someone else's style. Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. Go made me feel slightly violated; forcing my directory layout was the last straw, and the lack of any configuration in a place where it would not be complex to add it seamed stupid.
- I find that having a common style about source files from different origins (we're in the open source era) and common naming conventions are great for the readability. I can decipher foreign code much easier if I don't have to set my mind about the bracing style. And seriously, would you prefer to have "private" and "public" all in the place instead of this simple convention ?
- I found it a little painful too, at first, to have to mix source and binary in my projects with the advent of the go tool but the removal of redundant makefiles and its simplicity of use, especially when you deal with a lot of projects and packages from diverse origins is so great that it's hard to protest against that.
- Are you sure you're up to date about map keys ? http://tip.golang.org/ref/spec#Map_types
Go's CapitalEverythingNaming convention is quite annoying but the mere fact that it'll be used everywhere makes me happy.
This has been discussed numerous times on the mailing list. The answer, for good reasons, is too bad. As you note in your conclusion, consistency is prioritized above configuration.
There's reasons for this, they were meticulously debated and chose by the designers to help people out. If you have a pure Go project, you can install it anywhere Go is available in a single command. No autotools, no makefiles, no build-essentials, nothing. Just a single `go get` command.
If you ever work on a decent sized project in Go, you will quickly come to appreciate the enforced consistency across the project.
>To use the Go tool you are required to have your directories set up in a specific way
Not with the binary distribution. And "have a source directory on GoPath" is too restrictive... set `GOPATH=~` and for 90%+ of users, their existing dir structure is perfectly fine.
>No support for using user defined types as map keys
This is no longer true IIRC.
>Two initialization functions, new and make. One returns a pointer, the other a struct.
I don't understand why this is a negative?
You can use any indentation depth in Go too. But in Python you can't get rid of indentation because its lexer expects it, just like you can't get rid of the "forced" brace style in Go, because its lexer expects it.
Go does have exceptions under a different name called "panic". It's named differently to communicate why they were added to the language (read docs for details) and their expected use-case.
Go does have a variation of inheritance called embedding. Using embedding you inherit all methods and fields of the former type but that does not provide is-subclass relation between types. In order to have abstract-class-like behavior one would use interfaces.
---
At the moment Go is mostly useful for creating lean network services. "net" package from standard library is really good. Goroutines are scheduled with the respect to system calls so all your code is effectively async without any jumps and hoops (no callbacks!).
There are few packages in other areas (gui) but that's not the fault of the language. You're welcome to write new ones or wrap existing C libraries (and that's really easy in Go).
Go also has generics, they just are not available to lowly peons writing new Go types.
As for D, I simply need to give it another go, pardon the choice of words.
(I will avoid any attempt at humor in future posts on this site.)
They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.)
None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics.
Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet.
Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
http://research.swtch.com/generic
http://commandcenter.blogspot.com/2011/12/esmereldas-imagina...
I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go.
† Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.
Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
But it does buy us a lot from a code complexity standpoint. C++ templates and Java's generics have a horrific effect on readability and comprehensibility, two of Go's primary goals. Generics are hard. If/when we do them, we'll get them right.
While forgetting Go has blessed in-runtime generic types because it turns out you really need generics.
Two Go features in particular help to mitigate the lack of generics:
1. The built-in array/slice and map containers are effectively generic since they can act as containers for any type.
2. Interfaces (http://weekly.golang.org/ref/spec#Interface_types) define a set of common methods that can be implemented by multiple concrete types. See e.g. the ubiquitous io.Reader interface (http://weekly.golang.org/pkg/io/#Reader), and the SQL database driver package (http://weekly.golang.org/pkg/database/sql/driver/) that defines a collection of interfaces that define an interface to any SQL database. FWIW I've written a concrete PostgreSQL driver: https://github.com/jbarham/gopgsqldriver.
Go 1 was a stabilization of what we already had, not an occasion to introduce new features.
If Go gets generics it will have a profound effect on the language and its libraries. better to introduce them in Go 2 once we know what they are and have a wealth of experience with them.
Normally you introduce stuff having "profund effect"s on the whole ecosystem _before_ you release something as "stable".
Maybe the Go devs want to repeat the Java generics story ...
As has been mentioned elsewhere, part of the problem with Java's generics story was that they needed to maintain backward compatibility at all costs. The same won't be true for Go 2, which may include support for generics.
Go 1 is a solid product - language, standard library, and tools - and one we will support for years to come. There will be a time for experimenting with generics but that time isn't now. Why is everyone in such a rush?
Generics aren't a unique trait of Java --quite the opposite: the language existed for a decade without them, and even now doesn't have a nice implementation of them.
The goal of C-like languages isn't to duplicate Java features. Go (and others) have their own set of goals. In this case generics doesn't advance the goals.
Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.