Go 1.1 beta 1 Released
groups.google.com
groups.google.com
However, the direction the language took ended up being quite predictable and somewhat of a bore. The problem with Go is that it doesn't seem to fit any particular niche. Some other design decisions were questionable (no exception handling, for one).
I kind of like Go, but I haven't used it for years. There's no real reason to NOT write something in C (or, rarely, C++) or Java, or if I need some serious scaling, Erlang (or just use either something like libevent for C or Kilim for Java).
Go is very D-like. D, like Go, can't really find its niche. If Go or D were more idiomatic, perhaps they would be adopted in early programming classes (high schools and colleges -- like Python, for example), but even though goroutines, channels, and fast compilation are interesting concepts, they aren't really enough to detract from writing in the many other languages that do just about the same thing (and are a lot more popular).
The language, libraries, and ecosystem are miles ahead of where they were back in 2009.
Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks. Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc. If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go.
Use Go more! You'll see why people love it, and why we created it.
I evaluated Go last week (2013-03), but there is no meaningful Eclipse IDE support. goclipse doesn't work half as well as CDT, and not a patch on JDT.
I won't move away from eclipse workflows and project management, the context switch is more expensive than any language benefit.
I'll keep checking for comprehensive Go support in Eclipse, but until then it is a showstopper.
More common main page: http://code.google.com/p/liteide/ Downloads: http://code.google.com/p/golangide/downloads/list Code: https://github.com/visualfc/liteide
You're letting your tool own you rather than you owning your tool.
Autocomplete / suggest broken on Windows. There is something about a fix by running an external server. I gave this a go, sending a few hours piecing together forum comments, but couldn't get it to work 100%.
edit: oops, I misread your comment. At first, I thought you found an alternative. I'd be open to working with you to improve the experience. I do not use windows personally.
It is called gocode (https://github.com/nsf/gocode). Pretty much all Go environments require gocode - the directions for Eclipse (which I don't use anymore) are pretty clear too: http://code.google.com/p/goclipse/wiki/GocodeIntegration
At some stage the context switch becomes too high and you give up. As I said "meaningful Eclipse Support", and digging around to get gocode working harms this effort.
Erlang has a great concurrency model, but it's fairly clumsy for writing procedural code of any complexity, which makes it harder to pick up too.
The libraries maybe (and the runtime). The language, as per semantics and syntax, is more or less the same.
>Why not use C? Because C has no sensible packaging system, is unsafe, requires manual memory management, and offers a degree of control that is unnecessary for most tasks.
But is absolutely essential for most tasks C is used. For all the others, why not use a higher level language like Python?
>Why not use Java? Because it is verbose and picky and basically forces you to use an IDE to get anything done, etc etc.
Some people are not "forced": they choose to use an IDE, and wouldn't have it any other way. It is like telling some Smalltalk guy: "Smalltalk forces you to use the smalltalk image editor/environment" -- so what? He is perfectly fine with it. Heck, lots of people even like using dynamic languages with an IDE (and more would, if there was better type inference and assistance).
>If there were nothing wrong with these languages (they're the main ones we use at Google) we wouldn't have developed Go.
Well, the main reasons for Go, as stated in the official pages (the Golang FAQ), are not very convincing or exciting: No header files, faster compilation, parallelism, garbage collection, lighter type usage.
What C programs are you thinking of? Thinking of significant C programs that I have used (bash, apache, gcc, and many more), I can only think of a few that wouldn't be easier to write and maintain were they written in Go, without suffering a meaningful performance penalty. Funnily enough, a lot of the uptake of Go has been from former users of Python, Ruby, and other dynamic languages; they attracted to Go's simplicity, safety, and speed.
But really there's a lot more to Go the faulty dichotomy of "dynamic vs static" (or Python vs C, whatever). This is worh reading: http://talks.golang.org/2012/splash.article
>lots of people even like using dynamic languages with an IDE
Agreed, and I have nothing against IDEs. I have just found that I can't comfortably write Java code by hand. There's way too much boilerplate. In my experience an IDE is essential writing Java code efficiently, and I don't think that's a good thing.
>not very convincing or exciting
Depends on your definition of exciting. Since I've been writing Go code I've been more excited about programming than ever before.
As much as I love high-level programming, many of the most interesting and important problems are ones where a "small" constant factor is the difference between great and mediocre.
On most algorithmic benchmarks Go is 2-3 or more times slower than C/C++.
And parsing something like a large C++ codebase with a GC language like Go would result in tons of memory used (and slowness).
Heck, even Go compiling Go programs gets OOM'ed sometimes in Linux.
For a project a couple of years ago, I needed to use OpenCV and the Go bindings were quite immature. I just switched to C++ (for that project) and never really returned.
But now that I think about it, whenever people that are interested in being introduced to coding (it happens a lot on campus) ask me "what language should I learn?" I've never answered Go. I'm not sure if most people would.
Certainly not C or C++, if you're discounting Go. I'd also discount Java and C#, since they're syntactically quite similar to Go. Certainly not erlang.
So... python? ruby? While I like those languages, I feel that the lack of a compiler is a pretty big hindrance to new programmers. Statically typed languages can catch many errors that produce some truly strange error messages in dynamic languages.
However, Go seems to be very good at what Python/Ruby/Node.js/Perl are good at. It provides a simple, clean language with more guarantees and better runtime (mainly the cheap goroutines). I see Go taking some of their role for web development, simple tools (Go programs produce a single binary - very easy to distribute).
Apart from Google (who uses it for Youtube), Go hasn't really been used in large projects. Maybe 1.1 will change that. I might give it another shot, too!
I don't know how large each of these projects is, but a growing number of companies are using it for serious projects:
Iron.io: How We Went from 30 Servers to 2 with Go http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...
Behind the Scenes: Big Data at Torbit http://torbit.com/blog/2013/02/19/big-data-at-torbit/
pool.ntp.org DNS server in Go http://news.ntppool.org/2012/10/new-dns-server.html
Juju at Canonical http://www.reddit.com/r/programming/comments/18atce/juju_can...
Go at bitly http://word.bitly.com/post/29550171827/go-go-gadget
CloudFlare blows hole in laws of Web physics with Go and Railgun http://arstechnica.com/information-technology/2013/02/cloudf...
dl.google.com now served by Go https://groups.google.com/forum/?fromgroups=#!topic/golang-n...
Go At Conformal https://www.cyphertite.com/blog.php?/archives/7-Go-at-Confor...
Go at Novartis https://plus.google.com/114945221884326152379/posts/d1SVaqkR...
Go at the BBC http://www.quora.com/Go-programming-language/Is-Google-Go-re...
Go at SoundCloud http://backstage.soundcloud.com/2012/07/go-at-soundcloud/
Go at CloudFlare http://blog.cloudflare.com/go-at-cloudflare
Go at Heroku http://blog.golang.org/2011/04/go-at-heroku.html
Building StatHat with Go http://blog.golang.org/2011/12/building-stathat-with-go.html
These are problems I have seen with larger java projects with unused imports, unused variables, library dependencies, long compile times, etc. I think that Go's niche is for extremely large projects, but it remains to be seen if it will work.
Your suspicions are well-founded! http://talks.golang.org/2012/splash.article
I think it's very D-unlike. It's very small and simple.
Want high performance and full control? Use C (or C++). Want your code to be easy to maintain by an average Joe? Use Java or C#. Want your code to be concise? Use Clojure. Want extreme typesafety? Use Haskell. Need to use both OOP and FP? Use Scala. What question to ask so the obvious answer would be "Use Go?"
I basically see it as a midpoint between C and python, that offers most advantages of both.
From C: Low memory use, fast execution, type safety/ compiled.
From python: Easy/fast to learn/read/write, no slow compile, GC, memory safety, good standard libraries
It also does concurrency better than python (/anything else?). What would you say better fits these criteria? Certainly not the JVM languages (memory) or Haskell (accessibility).
I was immediately dismissive of Go when I first heard of it a few years ago. I only started looking at it again a couple months ago when I ran across the 'splash' article. [1] The attention to detail with regards to the language, the standard library and the tooling really impressed me.
Yes, in many ways Go is low level. It doesn't break much new ground from a programming language design perspective. It doesn't provide a lot of features, but what it does have is well integrated. At every turn, language features were added or left out based on the larger software engineering perspective, rather than what can produce the most succinct or elegant code.
What question to ask so the obvious answer would
be "Use Go?"
The only things that Go has over Modula-2 are interfaces, single declaration modules and GC.
Single declaration modules and GC were part of Modula-2 successor, Oberon in 1986, while Active Oberon in 2001 added Tasks and Interfaces to the Oberon language family.
All of these languages were used to built operating systems used for real work at Zurich's Technical University.
Because that's exactly one of the niches of Java -- enterprise programming by average Joes. It was even a stated design goal of the language back in the day.
In languages with exceptions, potentially any function call you make could throw, and you don't know, because it could be 6 levels deep in the call stack. (Even Java's checked exceptions don't help, since someone down the line inevitably just rights "throws exception" and the screws everyone up the stack).
Go is really fast to pick up, it's pleasant to write code in, and yes... it's boring. I think that's it's biggest feature. It gets out of your way so you can produce a product. Why does the language need to be interesting? Isn't it more important that it can build interesting things quickly and reliably? Go does that.
It also means that you don't know how much of your code executed. Have you written that file to disk yet? Maybe you need to clean it up now? Is that socket still open? or maybe you didn't get that far in the code?
In code that cares about handling errors, you end up with a lot of try/catches around individual functions that you know can throw... this is no different than go's if err != nil code.
try {
v = ThisCanThrow()
} catch (Exception ex) {
// handle this specific failure
}
v, err := ThisCanError()
if err != nil {
// handle this specific failure
}
Believe me, I understand where you're coming from. I've been using exceptions for 13 years in production code. I initially skipped Go pretty much solely because of the lack of exceptions. But I am really glad I gave it a second chance, because, damn, it is good.
Because of multiple returns, the normal flow of execution isn't indented. I find that this makes it easier to skim Go code in practice.
Your explanation does seem to make the case for this type of error seem somewhat sensible, maybe I'll give Go another try. Are methods which return errors and the types of errors returned clearly documented/visible?
func Demo (s string) (string, error){...}
Go does exception handling with panic, recover and its reflection syntax.
Even then discouraging panics is very different from not having them.
I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear. It seem Go could have used : and indentation as in python instead of { }.
Another puzzling choice of Go is slicing which differ from Python's and D's. In Go slicing is limited by the capacity and not by the number of items it contains. Returning 0 as default value looks to me like an open door to silent bugs.
The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.
From what I saw, I would say that Go is a better C and D is a better C++ where better means also closer. As a consequence Go seams simpler than D to learn and use. Thus I expect we will see much more Go programmers than D programmers in the future. Simplicity has been proven many times to be trump.
This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article
"Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."
That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".
My qualm with Go here is that it does not enforce a consistent style. (note: I use Go quite frequently). Trailing semicolons, parentheses, curly braces should either be valid or invalid. There are instances in the languages where either is fine.
I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies.
The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values.
As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.
for p = initial; p.next != nil; p = p.next;
doSomething(p);
I'm not really a fan of python indentation as I've had to clean up a couple of messes before.
Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).
In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.
However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.
file, err := os.Open(filename)
if err != nil {
// handle the error however you see fit
}
defer file.Close()
// continue working, knowing that file.Close() will be called when the surrounding function returns
The semi-colons are still there, but in most cases they can be inserted automatically when the program is being compiled.
1) Fast build times
2) Goroutines. If you've tried using any async library in Python or are waiting for Tulip to come into mainline Python around v3.4 - stop wasting your time. Goroutines along with channels just works (TM) and is unbelievably easy to use. No callbacks, no threadpools, no having to CTRL-C your way out of a bug. It's a pleasure to work with.
I'm looking for something for Go like PyGame is for Python. I like to get surfaces rendered on my screen in pretty much no time as I like to learn a language by doing simple graphical demos and experiment from there.
There are few SDL bindings for Go but none of them worked. One of them did work to some extent after a lot of tweaking without the help of many examples. I quit learning after I realized I'd have to learn more how the graphics bindings were written than how to program in Go.
OpenGL bindings are at https://github.com/go-gl
For 2D graphics there's promising project at https://github.com/skelterjohn/go.wde which provides interface that you can use together with http://golang.org/pkg/image/draw
(Issue worth noting is that none of the platforms specific parts in go.wde yet have hardware acceleration so it's not yet ready for game development etc. It's quite possible that that'll change in the future though :) )
And for ascii graphics we have https://github.com/nsf/termbox-go
There are bunch of other libraries as well but these are the ones that I'm more or less constantly using. go.wde is probably closest to what you were looking for but also the one that still requires hardware acceleration before it can properly be used as fast canvas for experimenting with games etc.
Note: None of these count as "standard library", all of them are third party projects by gophers around the world.
There are Go-bindings for SDL but I haven't tried is myself so I can't vouch for it. I have done some tests using the Go open-gl and glfw bindings though, and I encountered no problems when using them.
As for game frameworks, there's sadly nothing mature like pygame available, but I have seen a couple of such projects in development. One I came across recently and which also seems to be worked on in a regular fashion would be the GarageEngine,
https://github.com/vova616/GarageEngine
There are a couple of example videos on youtube:
http://www.youtube.com/watch?v=iMMbf6SRb9Q http://www.youtube.com/watch?v=BMRlY9dFVLg
Like you I would love to have a game framework for Go in the style of pygame/flashpunk/flixel/löve etc, but I feel hopeful that this will arrive in due time as Go picks up users.
Anyway, there are rumors that you can use OpenGL from Go, but I've never tried it.
and if you really want graphics, why not use Processing, OpenFrameworks, Cinder, or one of the languages supported by Unity? Go tends to really shine for writing servers. Of course, you could always use Go to write a game server for a multiplayer PyGame game.
On the other hand a more solid native 2d drawing library like java2d would be more welcome.
Weekend project #34532
Deleted comment
that is not even remotely what that is.
A sufficiently advanced graphics library will do considerable amounts of non trivial interaction with system dependent and even hardware dependent libraries. The parent cited SDL. Which sits atop other libraries. Which imposes certain runtime constraints.
I'd already said Go lacks any kind of standard graphics library and never tried to argue otherwise. But the standard packages that are included with Go's SDK are cross platform. I can (and frequently do) write Go applications using just the standard libraries that I then run on different platforms (both in terms of OS and CPU architecture) without any code changes what-so-ever.
Anyhow, even that being my point, I don't agree with it myself. Thinking properly about it, Go's base packages are little more equivalent to ANSI C than JRE; Go isn't managed and thus base packages are really just a set of standard libraries rather than a runtime environment.
Not hitting a DB. Benchmarked with 'ab -n 10000 -c 30 http://localhost:9000/some_action.
See also: https://github.com/davecheney/autobench BenchmarkHTTPClientServer 373216, 52646 -85.89%
bench old_ns/op new_ns/op delta
"BenchmarkHTTPClientServer 373216, 52646 -85.89%" I opened the thread first thing after waking up this morning, commented before having cup of coffee and resulted in misreading the whole point of that comment.
I'll try to drink more coffee from now on. Sorry knotty66.
Deleted comment
I don't see a tip in the hg repo for go1.1beta1. Anyone know what the right revision is? I'd rather install the known beta source than whatever's at the tip.
But as only fixes will be submitted between now and the 1.1 release, it's definitely better to use tip.
The only thing I'd strongly recommend is Gorilla Mux: http://www.gorillatoolkit.org/pkg/mux
And you can get an idea of how people build websites using Mux and Go by looking on github: https://github.com/jimmykuu/gopher
If you're very new to Go, then reading that last link repo you probably want to read these files in this order: https://github.com/jimmykuu/gopher/blob/master/src/server/ma... https://github.com/jimmykuu/gopher/blob/master/src/gopher/se... https://github.com/jimmykuu/gopher/blob/master/src/gopher/ur... and then to take a look at the files in this folder for the handlers and html/template calling: https://github.com/jimmykuu/gopher/tree/master/src/gopher
go get code.google.com/p/go.net/websocket
go get code.google.com/p/go.net/html
Gorilla toolkit is also very neat, but it's a handy tool-box for web work, rather than a kitchen-sink framework.
source: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...
I know of Collin VanDyck's web service showdown (http://boundary.com/blog/2012/09/17/comparing-go-and-java-pa...) which showed that Java had lower latency and higher throughput for highly concurrent tasks based on a very simple code base, but net/http performance in Go 1.0 wasn't a high priority. It seems that it has since been bumped up the priority list and a lot of work has been going on (https://groups.google.com/d/topic/golang-nuts/zeLMYnjO_JA/di...).
The thing is, Go isn't just for writing web apps. If you have a look at some of the real world use cases for Go (there's a list in another comment here somewhere) you'll notice that these aren't just web apps.
Every bit of Go code I've written (web app, mp3 database generator, encryption library) has been blisteringly fast, and it seems Go 1.1 will bring substantial performance improvements again.
Oh, and I didn't down-vote you, I don't yet have that privilege.
Also, don't forget at the time of this posting that page is showing Go 1.0.3 not 1.1 beta.
binarytrees#3 18.576s (go1.1beta1 17.298)
binarytrees#1 114.303s (go1.1beta1 121.446s)
binarytrees#5 123.890s (go1.1beta1 138.230s)
chameneosredux#5 4.984s (go1.1beta1 4.482s)
fannkuchredux#1 98.413s (go1.1beta1 73.698s)
fasta#1 10.620s (go1.1beta1 6.937s)
fastaredux#2 2.164s (go1.1beta1 1.964s)
knucleotide#1 308.240s (go1.1beta1 213.563s)
knucleotide#5 75.117s (go1.1beta1 77.791s)
mandelbrot#6 75.166s (go1.1beta1 46.689s)
meteor#1 0.159s (go1.1beta1 0.136s)
nbody#1 32.135s (go1.1beta1 22.867s)
pidigits#4 4.016s (go1.1beta1 3.329s)
regexdna#1 161.505s (go1.1beta1 157.733s)
revcomp#3 1.573s (go1.1beta1 1.455s)
revcomp#1 1.188s (go1.1beta1 0.997s)
revcomp#2 1.495s (go1.1beta1 1.311s)
spectralnorm#3 22.727s (go1.1beta1 15.706s)
threadring#5 9.893s (go1.1beta1 12.919s)
Yeah, it's pretty much the other way now.
Go maps very closely to how I think about programming. It has more useful features than other languages, like channels, slices, and range. Yet despite this it is a beautifully simple language. It has fewer keywords than C and you can express the same operations with less code.
2. There are over 300 non-google contributors already
So the Go team says. But Google is still using Java, C++ and Python as it's main languages. And Go wasn't especially planned by Google execs to use for "solving their problems" -- it is a grassroots project by some Google guys to solve those problems. Which is something different than a mandated to use language.
>2. There are over 300 non-google contributors already
The level of contribution matters a lot. If Google staffers do all the core language, runtime, compiler, tooling etc, and the rest just do little stuff here and there in the libs, add documentation, etc, then it's not like this matters much.
Thats the best way that problems get solved. Go needs to win in the marketplace (even in Google's own internal marketplace) on its own merits. That's the best kind of win.
Corporate mandates end in committees with no sense of design or minimalism. I've seen enough of that to not want any more.
Go may not have begun as an executive mandate, but we now have high level executive support. More than a year ago Go was made Google's 4th "canonical language", which is an mandate that requires infrastructure teams to support the language. Some large teams are migrating to use Go exclusively, and the rate at which Go code is being written at Google is increasing dramatically.
> If Google staffers do all the core language, runtime, compiler, tooling etc, and the rest just do little stuff here and there in the libs, add documentation, etc, then it's not like this matters much.
Except that is not the case. We have many contributors who do core stuff. In fact, some of our hardest problems have been cracked by these guys. I love our community!
How do you know that is the case? I don't know the Google executive plans but it seems like to get Robert Griesemer, Rob Pike and Ken Thompson together to create a language might have/need some executive level involvement.
"Began as a 20% project" http://talks.golang.org/2012/go1.slide#5
I have no reason to assume that they are lying.
Because they have described it themselves (the Go guys). From the language FAQ:
"Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated work. By January 2008, Ken had started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler."
>I don't know the Google executive plans but it seems like to get Robert Griesemer, Rob Pike and Ken Thompson together to create a language might have/need some executive level involvement.
The agreement to let them work on it by some exec, is different than Google deciding "we need a new language, you guys go build one that fixes our pain points, and we will migrate stuff to that".
V8 or Dart for example are cases of this. Google decided the need to have those created, spend money on marketing and getting top people to work on them, built full-on documentation, marketing material, benchmarks, tools and sites for them, etc. It's the same kind of focus MS had for .NET and SUN had for Java.
Whereas Go is more like how Google had a team work on Unladen Swallow, or Apple had MacRuby, etc, mostly peripheral stuff, like a 20% project that grew up.
Once you're beyond just plain CRUD to the point where the language you're using matters more than how fast you can get going with defaults, then you might like Go more (or less) than Ruby/Python.
However, as you can see, it's not too difficult to write a basic CRUD app with authentication, even if you're starting completely from scratch (which you don't have to; I did it more as a learning exercise).
I disagree with jbooth; I find Go's templating language to be incredibly mature, and I also find it much easier to develop with gorilla than something like Flask, if for no other reason than the static compilation and incredibly thorough code analysis/other checking done at compile-time (unused lvalues, etc.)
Here are some of mine, that I turned into Go code: (restricted to "week long hacking" or less)
A simple blog application.
A command that when run, sends the output of other commands to your email.
An image viewer.
A simpler interface to `xrandr`.
A parser for the new TOML configuration format.
If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen.
The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again.
That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
The points brought up in the comment section below the article were not answered at all.
Russ Cox: “I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes [...]”
First comment: “How about C# implementation? It lets you use primitive types.”
Second comment: “The massive gaping hole in your list of approaches is .NET: reified generics, but in a reference-type oriented language. [...]”
Third comment: “http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx talks about the .Net Generic implementation in a bit more detail.”
Russ Cox: ⁎crickets⁎
"If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating."
So .NET has chosen number 2 with duplicate elimination:
"This slows compilation. It generates a lot of code, much of it redundant, and needs a good linker to eliminate duplicate copies. The individual specializations may be efficient but the program as a whole can suffer due to poor use of the instruction cache."
"With NGen, there can't be anything "lazy" about how generics are instantiated. Instead, NGen must create representations of every generics instance it could encounter. The CLR won't be around to JIT anything. So, after all the discussion of avoiding code bloat and taking advantage of CLR's run-time optimizations, NGen takes all those values and turns them on their collective heads."
Bartok compiler for Singularity uses another approach of code generation.
http://en.wikipedia.org/wiki/Bartok_%28compiler%29
http://singularity.codeplex.com/SourceControl/changeset/view...
Windows Phone 8 only runs native code. .NET IL gets compiled down to native code when uploaded to the Windows App Store, by making use of an optimizing IL to native compiler.
http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...
http://channel9.msdn.com/Events/Build/2012/3-005
Mono also compiles to native code on iOS and other systems as well
http://docs.xamarin.com/guides/ios/advanced_topics/compilati...
The IL2CPU compiler used in the Cosmos project, which is still not fully implemented
http://www.codeproject.com/Articles/220071/Csharp-Open-Sourc... http://cosmos.codeplex.com/SourceControl/changeset/view/1011... http://cosmos.codeplex.com/SourceControl/changeset/view/1011...
Going back to the runtime code generation (JIT), there is also SPUR being used at Microsoft Research
http://research.microsoft.com/en-us/projects/spur/
Don't mix languages with their implementations.
You're putting yourself into an authority position where you write him off as incompetent:
"Do your homework! What you say is wrong and awkward!"
That's an attack at him personally, and completely unnecessary. Simply providing the facts showing that he's wrong would have sufficed. You haven't done that, btw.
If you want other types with generic functionality (e.g. caches) that perform well (interface{} does not), then you have to use external code generators.
Deleted comment