Go (lang): one year ago today
blog.golang.org
blog.golang.org
It may not be as beautiful as CoffeeScript (which we also use), as rich as Python, as safe as Rust, as concurrent as Erlang, or even as hackable as Ruby, but it certainly offers an unparalleled set of features which is hard to find in just one language — decent standard library, decent syntax, decent performance, super easy concurrency, a helpful and reasonably sized developer community, a relative level of stability, automatic memory management with good enough control over memory use, usable interoperability with C, native client support and even a standard testing framework.
Thank you and happy birthday to all the fellow Go developers out here on HN.
As a question: do you see parts of your startup expanding past the area of Go? Would a mixture of other languages help?
But, having said all that, the biggest surprise has been how Go has become the dominant language within our code base. We initially started using Go to just handle the networking layer. But it soon became apparent that Go was perfectly viable as a general purpose language. And today the majority of our code is written in Go.
So, whilst we'll continue to leverage other languages for what they are good at, I can confidently say that Go will be at the heart of our technology stack for the forseeable future. And with the various "good enough" statements, I was trying to say that although Go is not the best language ever for specific features (e.g. syntax, standard library, etc.), it definitely offers the best all round set. And the situation only gets better every day. So I'll definitely say that Go is more than good enough.
I hope other language designers take note of Go and put more emphasis on simplicity in the future.
I would also be very interested to know which companies are using Go, and for what.
Google is hiring people to design languages and tools that know absolutely nothing about modern language design techniques, or what modern software engineering tools look like.
If you're paying any attention at all to Go, you're not learning anything. In fact, it's possible you're damaging your brain. It's projects like these that make Google look really bad and unattractive to programming language researchers, especially as compared to Adobe, IBM, Sun, and Microsoft.
From here: http://lambda-the-ultimate.org/node/3896
I don't think LtU approval is necessary to have done something good. We need more tools that help programmers solve problems of concurrency without losing their feet.
Tools that aren't entirely groundbreaking are very useful here, because you can take a guy who knows only c++ and have him write a bit of go. I can't as easily get him to use twisted or erlang or even node.js.
That's a joke right?
The academic community is - almost by definition - focused on doing "new stuff". That means, for example that they have a significant focus on getting type systems correct, but often consider things like integration with existing 3rd party libraries uninteresting.
You'd never see a language like Perl, PHP, or even Javascript come from the academic community because they don't break any new ground.
And you certainly will never see language like C come from academia.
Nor an operating system like (the original) Unix.
Unix was basically a simpler, easier to use version of MIT Multics, designed for the smaller and cheaper PDP-7. Most of the innovative ideas in Unix had first implemented in Multics.
So while neither C nor Unix where truly innovative, even for their time, they won out because they took well known concepts and actually made them work in a practical sense.
No, you'd never see these languages from the academic community because they're horribly designed. They design betrays someone who has learned nearly nothing from existing languages as they all make mistakes that were encountered and solved decades ago.
But... the whole point with the popular scripting languages is that they are easy to pick up -- just because they are heavily influenced by old languages!
(Besides, it is one thing to copy features from existing languages -- doesn't imply there is nothing interesting in the new languages. [Edit: Not all, at least. :-)] )
Edit: Here is an example of the last case:
A few years ago, I heard a talk about Moose, a replacement for OO in Perl (by Yuval Kogman/"nothingmuch"). There were two main points (1) Moose is stable, (2) it is modern. "And with modern, I mean the latest research papers".
They show signs of knowing about older languages but not understanding them. For example perl has dynamic variables (this is a huge win and for me the only good thing I have to say about the whole language)... but they're default. We had already fought this out in Lisp and found out that while they're an incredible concept and should be in any language that favors mutating variables, dynamic variables should not be the default.
Python using crappy one line lambdas instead of real closures. Why? Because Guido seems to not get functional programming. Ruby copies Smalltalk but Katz says Smalltalk "goes to far". What? A lot of the problems that trip people up in Ruby aren't a problem in Smalltalk. The biggest difference between the two is that Ruby isn't image based, but Smalltalk doesn't have to be either.
For me the biggest problem with the scripting languages is that they don't have any need to exist. They usually copy features from existing languages that already did a better job. If the manpower they got had been focused on the source languages the communities could have gotten a lot farther.
>There were two main points (1) Moose is stable, (2) it is modern. "And with modern, I mean the latest research papers".
The papers he was talking about were likely the Traits papers. Traits were done first in Smalltalk and aren't needed in Lisp because CLOS has proper multiple inheritance. Moose does look ok though.
All I've read (and own experience), says that scripting languages are much faster to develop with?
Do you have anything contradicting that?
Edit: Grammar
Much faster to develop with than what is the question. Much faster to develop with than C++? Or Java? Sure, but that's not a very impressive benchmark is it?
A pity Lisp or some other existing neat envirnoments didn't fill that niche. It might have something to do with their community, I guess.
Well, your throwing me an anecdote and asking me to contradict it so I guess I can do so with an anecdote as well?
"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing. It only speaks to the packaging of said language.
I think we can find a great example in PHP. I think we'd be hard pressed to find someone that would suggest PHP is a well designed language [1], yet it uprooted perl and took over the web. Why? Because it was less effort to go from zero to working web application than anything else. If the creator of PHP had, instead, created his platform on Lisp (and excluded the poisonous Lisp IRC community), who knows, he might have had even more success because Lisp is better designed, actually existed, etc. [2].
[1] But this is the Internet after all, so I'm sure you could find some one who would say that.
[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all. Surely it would have been at least comparable effort to fork some Lisp project and create "PHP" from that.
Sorry for assuming you were aware of this.
Consider code size, which is easy to measure -- and examples are over the net. Compare e.g. C/Java with the usual suspects (Ruby, Perl, Python, PHP, etc). For many applications, the scripting code is half the size.
A given programmer tend to produce a certain number of lines per day. Ergo, shorter coding time.
Coding time with an edit/compile/test cycle might be offset by modern IDEs (I have no data on this).
>>"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing.
Coding size costs money; both to write and to support. Money is one of the big motivators today...
>>[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all
I don't know much about PHP, but it is well known that the first version was written as Perl scripts.
(I don't know, does Lisp really have such problems with its community? Write anything bad about Python and you'll get flamed to a crisp, Ruby has a lots of childish rah-rah etc.)
Lines of code is also a bad metric. You have to also count characters, etc. There was a study that did just this for C++, Java and Smalltalk. Java was 3 times more concise than C++ and Smalltalk 3 times more concise than Java.
[1] Interfaces would be the closest Java was to inventing something but Smalltalk had these informally (and some environments would let you work with them directly).
I don't disagree. But many/most of those design decisions were made to ease learning path, etc.
I should know by now that it is hard to argue "worse is better" to a CL guy. :-)
(C++ is quite a bit more flexible than Java; what feature took so much more characters? afaik -- with modern libraries, you can be very productive in C++. It isn't used so much because of the pain, I guess...)
Moreover, I care not one whit that Google looks "really bad and unattractive to programming language researchers"; because I'm not one.
I do think OCaml is an interesting point.
Until BitC author claims that it is used for real applications. Has anyone outside of the Go team mentioned any use of Go in real applications? Please correct me if I am wrong, but at the moment Go, BitC and Rust are all experimental systems programing languages.
(I know, he would probably disagree with Pike, Thompson et al., too, but on different principles.)
It was successful in that I found it very easy to express what I wanted and make a concurrent app to do it. It didn't actually find a bug (I'm not entirely sure there was one, but the code that fell out of it is reusable for my next one).
When go first came out, I wrote a memcached server in it: http://dustin.github.com/2009/11/12/gomemcached.html -- the language was a little rougher when I started the project (defer didn't work properly until last march), but I still feel pretty good about it.
Well, that's it. If I can't have a brace-war tearing the dev group apart for months and kill productivity, I want nothing to do with that language. What's next, significant white space?
Go's public/private difference is capitalization of method names. That's hard to scan. Then you get chains that look.Like().A().Mess().
What the Go team seemed to do was take syntax from other languages they were familiar with, ugly syntax non-dynamic languages. They didn't focus on it, Pike said it wasn't important, semantics are important. So when you don't design syntax first, you get a syntax that's on the opposite end from Ruby.
Arguments func([] byte T* blah), who knows what goes where. That needs work.
The c-> and <-c is unintuitive, the syntax is so itsy bitsy it's easy to miss the difference. They should have keywords for that.
And in general the syntax is itsy bitsy, they feel that shorter words means quicker to read, but it's an overreaction to never ending lines commonly found in Java and C++.
I love capitalised public method names. It means I can immediately tell whether a method is public or private, in any context, e.g. on code pasted on HN.
look.Like().A().Mess() looks awful. Don't do it. Or do, it's up to you/ your company's style guide. You could easily avoid chained methods entirely.
Go is at the opposite end from Ruby. It's a systems language... The fact that they look different is no surprise.
func([] byte T* blah) - that's not Go.
send and receive are perfectly intuitive to me. Watch! You put it in the channel<-. You get it out of the <-channel. There is no "->".
"in general the syntax is itsy bitsy" - I can only suggest you try it for a bit longer until you get used to it.
Rob Pike made an interesting argument about dynamic vs compiled languages. Said that the division between easy of use and performance, dynamic interpreted vs static compiled was not caused by technical problems, just dumb luck. People that made up dynamic languages weren't interested in performance, didn't design around it.
Maybe now they're perpetuating the same division in syntax. System language syntax is weird, machine looking, dynamic language syntax reads more like English. Doesn't have to be that way, but it would be the system guy's preference. So I was thinking if the dynamic language camp used to Python's syntax took up Go, maybe it would be changed for their taste.
The channel <- syntax is crazy. In and out depends on which side of the operator channel is in. I'm sure they thought it was cute, but "into" "out" keywords are easier to keep track of than which side the channel var name is on.
I don't understand your objections to the channel syntax; the order of the letters you type matters, obviously. Again, it's a personal preference, and I'm quite used to C's pre/postfix operators.
I prefer languages that you don't have to get used to. They're obvious, like a good user interface is obvious. Anyone can read their code, even if they don't work in the language. Go could be a language like that, there are no technical roadblocks for doing that, just a matter of the audience's taste.
Is there such a thing?
Considering the year elapsed, that's about as likely as them killing the project and admitting that Go is a turd which only gets airwave because it's a project by two extremely famous googlers. The syntax is crap, the type system is garbage, they spend their time reinventing utterly terrible wheels and they've thrown out basically all ideas of safety they could get on fire.
I appreciate their maintenance of an end delimiter to blocks that is vertically aligned with the start of the block, although they could have gotten a bigger win imo by going with the ALGOL/Ruby style 'end' rather than the C style curly brace (and in doing so freed up curly braces to unambiguously be used for something else).
Arguments on significant whitespace aside, I think that this is one thing that Python got right. (For reference, Python's rules are that ending a line with a backslash will continue a statement, and the same effect will occur automatically if you have a parenthesis, curly, or bracket open.)
I might also be convinced that it would be a good idea to have statement continuation happen if the last token on a line was a binary operator, for the benefit of code like:
if self.foo() and
self.bar() and
self.baz():
do stuff
Erlang is based originally on Prolog, a logic programming language that was briefly hot in the 80's. Surely you've seen other languages based on Prolog, right? No? Why not? Because Prolog sucks ass for building entire applications. But that hasn't deterred Erlang from stealing it's dynamite syntax. [source: http://damienkatz.net/2008/03/what_sucks_abou.html What Sucks About Erlang]
In reality, syntax just fades away after ~5 minutes of real world usage. As Steve Jobs would say, it's not that big of a deal.
You know all the problems with the ambiguous ; , . stuff that Katz gripes about in that post? Prolog terminates every clause with a period, and all related rules just occur in sequence. Prolog has a read function, much like read in Lisp - "read the next complete (s-expression|Prolog clause) from stdin". The original Erlang compiler needed to read all of the alternative clauses for a function in one go* , so they strung them together with "," and ";", which are Prolog's and and or operators. (They could have fixed this when they started self-hosting, but probably had other priorities.) In practice, it isn't a problem (and Erlang has many perks to make up for those minor syntactic irritations!), but that can't be blamed on Prolog. It's sort of like if you used Lisp's (read) to load more expressions, but since your compiler needed you to read a whole module at once as an implementation detail, you used [ and { pairs instead of parens. Yuck!
In Prolog, that sort of code looks like this:
parent(terach, abraham).
parent(abraham, isaac).
parent(isaac, jacob).
parent(jacob, benjamin).
* I'm reading between the lines here, so if Robert Virding swoops in and tells me I'm wrong, Hello Robert! :)
If anything, the reason that Prolog isn't good for entire applications is that it's fundamentally a rules/database query language. It's awkward for stateful / procedural code, but if you treat it like (say) a much more sophisticated SQLite, it will be good to you.
I'm still foggy on Erlang, however, and less motivated every time I refer to documentation (but hey, I'm getting paid for it so it kind of evens out).
http://i.imgur.com/8ERaf.png
X axis is days (approx) since 11/12/09
Y is % of chars as compared with the busiest day (11/12/09)
> We’re also exploring some further additions to the type system to make generic programming easier.
http://www.cse.unsw.edu.au/~dons/irc/
Compare also:
http://gmane.org/plot-rate.php?group=gmane.comp.lang.go.gene...
http://gmane.org/plot-rate.php?group=gmane.comp.python.gener...
http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell...