Go 1.2
code.google.com
code.google.com
The lack of generics in Go takes away most of the fun from coding after a couple of month. Despite what is being said, interfaces do not lessen the pain.
With a better type system, taking ides from Haskell (ADT, generics done well, ability to implement interfaces for a type outside of its package etc) Go could be the perfect "dirty Haskell" for me, but now it is just a meh language with a half assed implementation.
That being said, it is still a much better choice then a lot of overcomplicated languages out there.
EDIT:
The biggest practical problem with not having generics is the fact you do not have access to list (slice in Go) manipulation functions. This means you have to implement them yourself, on the fly, for the given type when you need it. This does increase the time it takes to implement something, but also can introduce a lot of bugs as well - you can't rely on (almost guaranteedly) bug free implementations of existing functions.
Of course this runs much deeper than just the list type, but on day-to-day basis I feel this to be the biggest pain. But the rabbit hole is deep: we could get into how the multiple returns values are just a really inconvenient (not composable) workaround of not having a generic tuple type...
As a simple example, the fact that log.Logger isn't an interface means everyone creates a wrapper just for testing purposes. DI is also complicated enough that in some cases, it's just easier to forget about unit tests and stick with integration tests.
I'm actually finding Go to be one of the testable imperative languages I've used. This isn't everything I've developed for it, but this is one of the fundamental tricks: http://www.jerf.org/iri/post/2923
Also remember that global variables are still Bad. If you've got a global Logger, you've already lost. Fortunately, struct embedding seriously mitigates the pain of passing things around and using them. While this will probably break apart into multiple objects as I continue developing, I've taken to having this sort of structure:
type Services struct {
*logging.logger // actually our custom logging package
database.Database // locally defined interface
connections.Tracker // registers connections or whatever
}
Technically none of this is impossible in other imperative OO languages, but Go has just enough twists on things to make it qualitatively easier, mostly implicit satisfaction of interfaces, which has had consequences beyond what I've expected. Embedding has had surprisingly pleasant consequences too; complicated objects can be safely built up with rich interfaces that do not require you to hardwire them together, or give you excessive access to the internals of the bits.
As for DI, just connect your process components through constructors that take interface-typed parameters.
I would also prefer that the type system could catch null pointer exceptions, but most languages don't give this guarantee, so it's not that big of a deal.
Another thing people gripe about is that exceptions (panic) is almost never used, and that most functions return error codes. I've yet to decide what I think about this issue, but sometimes it does feel like Go went for "NO EXCEPTIONS!" and then figured out they needed exceptions anyway and added panic/recover as an afterthought.
What I do love about Go though is the implicit interfaces, := assignment, forcing if and for to be followed by {}, no inheritance, concurrency and the non-forgiving compiler.
For example, I'm writing a small program to update a database. If the DB connection can't be opened, the program can't do anything useful, so it can just exit with an error.
Any library should just use error.
It is a panic condition... I could have chosen my words better. That's what I meant by the program exiting.
Map takes a transforming function and a list, and transforms each element.
type MyString string
func NewMyString(s string) MyString{return MyString(s)}
a := []string{"A", "B", "C"}
If you want to create a []MyString from []string, now you have to loop over that and transform by hand, with generics you could do map(NewMyString, a).
But the things that bother me most about Go are actually different (I'm saying this being a big fan of Go and having written a few projects with it):
1. The GC is very simplistic and prevents building memory intensive services (at least not easily) without suffering long pauses.
2. The lack of any robust IDE. I'm mainly working with Sublime, and used to work with the IntelliJ plugin. Both are decent, but sublime has a half working gdb integration, and IntelliJ lacks one completely.
3. Community maturity. go-get is awesome, and there are tons of libraries for anything - but most are immature and/or not maintained. Usually you have a problem and find 2-3 projects that look promising that already solve it, but then one hasn't been updated for 2 years, the other looks awesome but is 2 months old and incomplete, etc etc. It will get there, I'm sure, but currently there is an inflation of toy projects, and no mechanism to find the prominent projects quickly (I think pypi's keyword based approach helps with this a bit, BTW).
There is more to a language than just the language itself, especially when you use it in a business setting.
But you made me curious now.
They employ Alexandrescu, a well known C++ figure, who I understand is quite fond of D now.
http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_o...
I wonder if you might like OCaml (which is my sort of "less strict haskell"). There's also rust of course, but that's explicitly not for production use.
One of its problems is that its concurrency support is lacking. But that doesn't seem to be a problem for other languages to become popular :).
OCaml had some pretty specific downsides beyond just the GIL (which is pretty absurd on its own). Typeclasses are really big, and the module system can't make up for them. OCaml also had absolutely terrible tooling and an abysmal standard library, although this has been improving pretty quickly in the last few years.
Ultimately, after having used both languages quite a bit, I just find OCaml quite a bit more awkward than Haskell. OCaml's advantages just don't make up for this, although I really love some features like polymorphic variants and modules that don't suck.
I'd still use OCaml for a few particular tasks, like web programming with the incredible js_of_ocaml, but Haskell is generally my default choice both for programming and trying to teach people.
http://www.podval.org/~sds/ocaml-sucks.html
Interesting, what would experienced OCaml user say about this. Maybe some issues are now fixed...
> That being said, it is still a much better choice then a lot of overcomplicated languages out there.
Devils advocate here, do you see a contradiciton between these two sentences?
I would argue that having a bad type system definitely can make a language overcomplicated, full of edge cases and dark spots.
In some ways, Haskell's type system is actually simpler than Go's: there's no sub-typing and hence no real casting. Haskell also tends to eschew special cases in favor of more general solutions; for example, Haskell does not need any magical notion of multiple return values built into the language because this is naturally subsumed by tuples. Similarly, Haskell has generics instead of baking a paltry set of data structures into the language.
Also, algebraic data types are actually very natural. Tagged unions (also known as variants or sum types), unlike normal union types, are dual to product types (structs and tuples). This means they are actually just opposite versions of the same underlying structure: very symmetric. And just like in physics, symmetry usually means you're onto something.
Haskell has an extremely simple and elegant core; just because it's difficult to learn for some people does not mean it's a particularly complex language. It's certainly simpler than Scala, for example! Certain extensions add quite a bit of complexity, but the most complex ones are not super-widely used so you can reasonably get away without ever dealing with them.
http://stackoverflow.com/questions/6121146/reading-ghc-core/...
Anyway, I like go because:
* of its fast builds.
* static compilation.
* speed, almost a replacement for C++ in what I do
* concurrency: goroutines, this is great compared to threads in other languages
* nice library -- json, http parsing, many other goodies, batteries included is good in my book
* gc -- nice to have a garbage collector
What I don't like as much:
* concurrency: goroutines are great, but once you've tasted Erlang's model, this one seems lacking. I like thinking in actors and mailboxes rather than in goroutines and channels. Actor+mailbox somehow matches my world view better rather than nameless goroutines.
* no supervision control of goroutines -- I haven't found a way to kill, or watch for death of a goroutine externally. This would make it easy to build a supervision tree and add some fault tolerance features to the language. channel ping plus timeout could mimic it but seems kind of a hack.
* gc stops the world sometimes.
* goroutines share the heap, I wish heap sharing was an option one had to enable and by default it would work like Erlang (or Dart Isolates). As concurrent systems (which supposedly Go is the prime target for) grow it is really fault tolerance that kills them. One goroutines, killing the whole system with thousands of concurrent requests is so C++-ish, I wish it was more Erlang-ish.
It's not as good as Erlang, not by a long shot, but it's still a bit of reassurance, and provides a useful default "restart" behavior out the box. (Naively-written restarts have some bad and easy-to-trigger pathological conditions. Well-written restarts still some bad cases too; crashing software can always crash in more pathological ways than you expected, but it's at least better.)
I'm also developing a library that gives you a "mailbox" like Erlang. I'm porting over a project in Erlang, and while I use native Go idioms where possible, Erlang code ends up with the Erlang semantics deeply embedded in it. (My thought is that a new project in Go should never use this library, but porting Erlang code may be eased by it.) That is still very much in progress; I'll only be starting cross-node clustering support here in the next couple of weeks, and without that there's not a lot of value to it. I'm still feeling my way through the right set of functionality and semantics for that, it's not ready for the public yet.
It lets you give your components names, and the inports of the components are somewhat analogous to Erlang inboxes as far as I can tell.
But then it improves on the Erlang actor/mailbox concept by keeping the "wiring" of the connections between boxes completely separated from their implementation, which lets you change the data flow much more easily (hook in a monitor, logging facility, and extra test mock or whatever ... it is crazily powerful when you start to think about it!).
GoFlow is of course not the only FBP implementation, but a Go implementation makes quite some sense I think.
If you wonder what the Erlang creator (Joe Armstrong) thinks about FBP, you can find his comments on it here: http://programming.oreilly.com/2013/10/transformative-progra... (He's considering implementing one in Erlang :) )
At compile, there's one version of a generic method (say List<T>.Add). Compilation isn't slowed down like in C++.
At runtime, a generic method is compiled (on demand) into unique versions for each T encountered if T is a ValueType (int, double, etc. including user defined ValueTypes). This avoids boxing, like in Java.
Also at runtime, for all T's that are reference types a single common version is used with implicit casting as in Java.
C#'s draw back is that there is a small cost incurred on the first use of a generic method, and then an additional cost for each new ValueType used (if any). In practice this doesn't ever seem to be an issue, but it's there.
See http://stackoverflow.com/q/5342345/80572 and http://www.artima.com/intv/generics.html (which is linked from the former).
C# on CLR is a VM approach, whereas Go compiles to native code. Concepts that are easy in the first (e.g. runtime code generation) often don't map particularly nicely to the second.
I suppose debugging could go sideways in theory, but it doesn't happen in practice on .NET and I doubt the go team couldn't figure out how to make it work.
It's worth noting that .NET never interprets bytecode, it always converts a method into machine code before execution. Go has already had dynamic code generation as part of it's implementation (I don't know if it's still around in 1.2), so it's hardly like it can't do the same thing .NET is.
For .NET proper, new machine code is generated at runtime. I believe (but do not know for sure, offhand) that it basically takes the IL definition of the generic method, slots the now known type into it, and JITs it to get the machine code it needs. I do know that there are couple bits of IL that are meant to make it possible to write the same code to deal with both reference and value types, which is probably related.
Ngen (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...) let's you transforms assemblies into machine code up front, while still being .NET proper. However, if it can't find a use of generics with concrete types found at runtime (ie. you generate a List<int> via reflection) you'll still load up and use the JIT (see some discussion here: http://stackoverflow.com/q/16647568/80572).
I don't use AOT or Ngen regularly, so the particulars may be a little off in my explanations. But that's the gist of it.
Early days, still a lot of work to do, but I think it’s promising.
One thing that I would actually accept for "go generics" is the go tool developing instead some ability for users to invoke the same sort of magic that cgo has, to run some code before the actual compile phase. (If this already exists, I haven't found it, but I'd love to hear about it.) Then instead of the language developing "generics", it can simply be an extension that people who care about use, and those who don't, don't, because as you observe, in the end this really is what "generics" are in most languages. That would also open the door to, for instance, some slightly more automagical database bindings that generate them from a schema or something, or anything else that involves generating types from metadata.
There's quite a few tools like that that I don't want to function at run time, and I'm perfectly happy to have code generation work with it rather than lard up the language with every feature under the sun.
You'll sacrifice reflection doing it that way. This also causes the same build time problems that templates cause in C++: you have to parse the generics over and over every time you want to use them. You also need to have some facility for collapsing duplicate template instantiations.
You really do need to have generics built into the language to do them properly. Preprocessors cause as many problems as they solve.
How? Everything produced by the preprocessor is available at runtime as much as anything else.
"you have to parse the generics over and over every time you want to use them."
I am not seeing how this affects Go, which does not do inclusion the way C++ does. You run the preprocessor once, it creates some files in the local Go package which you should not manually edit, and from that point on it is just as if you had created them by hand.
"You also need to have some facility for collapsing duplicate template instantiations."
This one might be true, but given the cost/benefit tradeoffs, I'll pay in some cases. It's not as if we're talking about a happy paradise in which not having generics solves all my problems; it visibly causes me to violate DRY in some of my code. DRY is the highest principle of software engineering.
Plus I'm not sure it's true. With what's being described here, you'll only be able to instantiate the generics for a given data type within the package that declares that data type, as it involves adding methods. The result may be that you in fact can't end up with duplicate instantiations; things outside the package can't add methods to data types inside a given package, and true duplicates are trivially detected at compile time. (This is in fact a limitation of the approach, but for this reason may still be a good one. I'm satisfied to solve 90% of the use case for generics if I can get it without dragging in the pathological stuff.)
You can't instantiate a generic with new types at runtime using the reflection facilities, like you can with other objects.
> With what's being described here, you'll only be able to instantiate the generics for a given data type within the package that declares that data type, as it involves adding methods.
That's so limited as to be almost useless. It prevents me writing a hash table library, publishing it, and then you linking to that library and using your Widget type as a key.
"Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value. What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types. But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. That's the detail that sticks with me. Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type's parent, whether A inherits from B or B from A. Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision. I believe that's a preposterous way to think about programming. What matters isn't the ancestor relations between things but what they can do for you."
> Here's a long quote by Rob Pike, which whether you agree with the points he makes or not, explains why Go does not have generics.
Does it? It seems more to explain why Go doesn't have C++-style classes.
In fact, this quote is almost like hearing the concept of metaprogramming being dismissed because C macros are a disaster.
> To be fair he was probably saying in his own way that he really liked what the STL does for him in C++
The C++ STL is hardly the ambassador of type theoretic solutions to problems of software complexity and safety.
> What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden.
Writing things once is not the problem. If you want to write a red-black tree of inegers, you don't want to write the whole thing again for some other totally ordered type. So you're left with casting your way out of the problem on top of a boxed implementation. Great, you've sacrificed DRY for safety and readability because a rich type system was too hard [1]. Note: almost wrote "proper type system".
> Perhaps I'm a philistine about types but I've never found that model particularly expressive.
Or perhaps Rob Pike just hasn't explored the relevant literature in enough depth. At one point he admitted that he didn't know that structural typing had already been invented previously! This isn't to criticize Rob, I find his talks fascinating, I think he's awesome, he's a friend of my boss, etc. But he's hardly the first hard-core hacker to be ignorant of the degree to which type theory has seen dramatic advances since the 1980s.
Just think of John Carmack, who after a very long and successful career using C and C++ is only now beginning to espouse the benefits of rich type systems and static analysis, going as far as to rewrite Wolfenstein 3D in Haskell.
> Type hierarchies are just taxonomy.
Here is the crux of the problem. Rob has silently switched from the ideal of "generic types" -- which 20 years of programming language research has taught us requires engaging with ideas like type classes, higher-kinded types, type covariance, and algebraic data types -- to the straw-man of "type hierarchies". Of course type hierarchies are crap. But that doesn't mean you have to return to the stone age.
Okay, well, structural typing isn't the stone age, but it's the beginning of the journey, not the end.
[1] to be fair, it is hard, Rust is still struggling to make the right balances, as Niko Matsakis's blog posts so entertainingly demonstrate.
hg pull
hg update release
You'll need to use:
hg pull
hg update release-branch.go1.2
The OP link goes to the commit showing this branch being finalised.
I have GOROOT in /usr/local/src/go and root owns that as it's put there in our dev builds by our bootstraps scripts.
I have GOPATH in /home/{user}/Dev/Go
One cannot go get as root from GOROOT for system install, and one cannot trivially go get in the user GOPATH either. The latter is due to vet and godoc needing permission against GOROOT.
If you sudo the go get within GOPATH, then that works from the GOROOT permissions point of view, but then (once you get past Mercurial freaking) the bits of GOPATH/pkg and GOPATH/src that relate to vet and godoc and owned by root... making any subsequent go get of say, the HTML parser, fail because it cannot write to the folder.
I ended up doing this as a user to go get vet and godoc within GOPATH:
echo "[trusted]
users = *
groups = *
" > ~/.hgrc
sudo sh -c "export GOPATH=$GOPATH && export GOROOT=$GOROOT && export PATH=$PATH:$GOROOT/bin && go get -u code.google.com/p/go.tools/cmd/godoc"
sudo sh -c "export GOPATH=$GOPATH && export GOROOT=$GOROOT && export PATH=$PATH:$GOROOT/bin && go get -u code.google.com/p/go.tools/cmd/vet"
USER=$(whoami)
GROUP=$(id -g -n $USER)
sudo chown -R $USER:$GROUP $GOPATH
Do the docs assume Go source installs are user specific?
Shouldn't this rather be: "It is impossible to use this new slice value to access the last element of the original array"
var array [10]int
slice = array[2:4:7]
“Updating: The increased minimum stack size may cause programs with many goroutines to use more memory. There is no workaround, but plans for future releases include new stack management technology that should address the problem better.”
This is a runtime/debug call to restrict the max size of stack. Somehow I feel like there should be one to set the min size too…
I'd really like to see some progress on generics / parametric types. I'm starting to get the impression that it will never happen.
From the FAQ: "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue."
I'm not versed in Go, but does that mean something similar to (Java-style) Object[] and explicit casting of each value you get out of the list?
http://play.golang.org/p/L5hprjhqN_
In this example, one function probes the underlying type by using t.(type), and the other one uses a type assertion by doing a val, ok := t.(int) - The type assertion will return the value of the integer and true if t happens to be an integer (a Go function can return multiple values)
If you pass an object as an "empty interface{}" you can test the underlying type.
edit: Note that you can only use a type assertion with an interface! So, this fails: http://play.golang.org/p/0BtSWfE3f2 but this doesn't: http://play.golang.org/p/tZB4Jivp3z
Interfaces in a nutshell:
Go checks at compile-time that any concrete variable passed where in interface is expected satisfies the methods of that interface.
Conversely, Go checks at compile-time that the program never attempts to invoke methods on an interface value that are not guaranteed by the interface.
In this example, there is a compile-time error (not a runtime error), because we attempt to call a non-guaranteed method on an interface value, even though the underlying value satisfies this interface: http://play.golang.org/p/EaQQpv-NAW
This provides type safety: if your program compiles, you know that you will never run into a runtime error by trying to invoke an undefined method.
When you do type assertions, you're using reflection (ie, http://golang.org/pkg/reflect/) to determine the underlying value at runtime.
However, remember that using type assertions essentially sidesteps the benefits of having interfaces. Interfaces allow you to invoke function calls with type safety on values of unknown type, as long as it is known that the underlying type provides the required set of methods.
So, the answer is that it is pretty much the same as in Java, since there you also use reflection to get the type of Object:
if (o instanceof String) {...}
The difference is that Java stores the type in the actual instance, while Go stores the type in the 'reference' (which is normally a type-pointer tuple). Unfortunately, Go's approach can lead to the situation where nil (null) is not nil, when two references have null as its pointer, but different types.
The other constant line from the Go implementers is something like "generics have proven troublesome in [unnamed] other languages, so we don't want them until we're sure we can get them right". This may be a reference to C++, in which compiling templates turns out to be a real pain. But at this point, the literature is full of better ways to do it.
The Go developers make a big deal about compilation speed. Wouldn't Go's goroutines have some interesting possibilities for parallelizing compilation?
Does this mean that every function call has to do a check and possibly an (atomic?) increment of some variable?
A Go module for VLC would be fun though. Not sure if we can do a .so in Go that is compatible with our way of opening modules.
Edit: My grammar decided to suck.