An Introduction to the Go Language
blog.smartbear.com
blog.smartbear.com
Seriously?
Python has SimpleHTTPServer to serve a directory plus the associated, less-well-known modules BaseHTTPServer (which SimpleHTTPServer is based on) and CGIHTTPServer, and wsgiref as the reference implementation of the WSGI interface, which makes it a fully-fledged web server.
And I find it impossible to believe that there would not be many more languages with a web server in their standard libraries.
All of which is beside the point. Those servers are (even in the documentation) not suggested to be used in production. And they are not.
Whereas Go's server serves thousands of requests per second in large deployments already.
The only other I know of is perhaps Node.
So, yes, seriously.
As such, I consider it as much a platform as it also is a version of the Javascript language for the backend.
Languages ARE platforms anyway -- we never care just about their core syntax and semantics but also for all the libs stuff they come with. So Python includes batteries, and Java includes the kitchen sync.
But you're also wrong in suggesting that Python's built-in webservers are equivalent to Golang's. What's the largest deployed Python application that uses those servers? My understanding is that every deployed Golang app uses net/http.
> Python has SimpleHTTPServer
And Ruby has WEBrick.
Erlang comes with one in the standard inets library.
Racket has one, too, in the standard distribution (it doesn't actually use, that I am aware of, the "standard library" name, and given the structure of the documentation one might argue that the web server is outside of the standard library, but I'm not sure that is a significant distinction.)
Web servers as part of the standard library or distribution are pretty common for languages these days.
Otherwise the articles more or less on point.
Languages do not have standard libraries. Platforms have standard libraries.
With php and python I always felt very clever for doing some things in amazing ways. With Go I never have that feeling, but when I look at the code I imagine that the developers of Go themselves were extremely clever, I can make concurrent programs with little extra effort. What's going on in the compiler, I don't know (and probably don't want to know), but it is one heck of a language for it.
Event-based programming without all the callbacks and event loops.
No one ever expects the side effects
Eh.. where?
Seems like a lot of Go fans have lost touch with reality.
And, no, not all communities are behaving like Go fans do.
They might be new features for all script kids seeing a strong typed compiled language for the first time, but for us old timers, it is a repeating deja-vu.
OK, Go is not Oberon/Modula, we got it already man!
Go makes you think that the new ideas are like the old ones. Go is the most distressing thing to hit computing since Java.
Java is the most distressing thing to happen to computing since MS-DOS. — Alan Kay
(I'm not sure if this is a real quote, but you can see it here: http://harmful.cat-v.org/software/java . There is a different unverified version here: http://c2.com/cgi/wiki?AlanKayQuotes )
- Lack of generics (this will be resolved in the future)
- nil exists
- interface{} is a *void style type safety loophole
These are all very minor issues, but the Go haters just love to harp on them. 99% of the time, I find they hold up ml-style languages as some sort of Holy Perfection. (lulz)
With most of the rest of the criticisms it's not necessarily clear how to fix Go (that is, it may be fixable but there's no one obvious solution that just works), but that's not the case for non-nullable types. They were always possible, have been for decades, and there's just no reason not to have them and use them as much as possible in the standard lib.
Also, I'm not a hater... unless your definition of "hater" is "doesn't like every last detail about Go", in which case, sure, under that degenerate definition I'm a "hater". You really shouldn't sling that term around in a preemptive attempt to marginalize your opponent like that, for a topic like programming languages. Save it for politics.
("Programming languages ARE politics." Well, they shouldn't be. Don't fall into that trap.)
I think the Go designers wanted the language to be approachable for people who habitually use null to indicate meaningful state. Multiple return values offer a way out, while still allowing newbies the option to abuse nil. (although, sum types would be nicer)
I think on balance, getting people from the 1970s to the 1980s who otherwise would not have gone there is a positive thing. Even if it's not the ideal thing.
It's not out of the question that Go will make your suggested fixes once it acquires enough mindshare.
C# even proves it can be profitably bolted on after the fact (contra pcwalton)... because that's how unobtrusive this change is. It's not like this is a complicated idea, unlike the other suggestions.
huh? Yeah, well. Newsflash: "nil" is nothing more than the zero-value for pointer types (and related other reference-semantics types).
Your point again? Should we rename nil with a new keyword "zero"? Fine by me.
Forced-nil pointers are a disaster.
Also, please re-read my last two paragraphs.
I don't know --- sounds like we would replace our current easy-to-grok, quick-to-fix "nil-pointer error" panics with obscure hard-to-debug non-panic-ing bugs because our code failed to check our now-in-every-struct custom "isInitialized bool" field?
Wouldn't you agree that the "special value nil", for pointers to complex struct types, is just as useful and essential as zero is for simple literal (non-struct) types, to represent that somewhat tricky but absolutely necessary concept of "non-existence"?
But they aren't. That's why they're the "billion dollar mistake": http://en.wikipedia.org/wiki/Tony_Hoare#Quotations If you think they're just easy quick problems, I find it doubtful you've ever worked in a significantly sized system.
Are you aware of the fact that there are plenty of languages that actually already have non-nullable values? Have you spent any time using them? Do you understand that such languages still support null values, but you have to call for them explicitly? Do you understand that we're calling for non-nullable values not out of some sort of abstract concept of correctness floating in space, but from concrete experience? I suspect you'll find that more experience correlates with a stronger belief in the need for non-nullable fields. It seems to me the people most vigorously defending the need for nulls have obviously never tried the alternative, as evidenced by their frequent belief that it's an all-or-nothing proposition, which is not true of any language, thus strongly implying a complete lack of experience. Also implied by you asking me whether nil should even exist, which is the wrong question, again implying you don't understand the alternative I'm advocating for here.
And again... it's soooo easy to add them, even to existing languages, and soooo easy to use them. It's not an overhaul, and it's an easy way to avoid the billion-dollar mistake. The cost/benefits are just so, so clearly in favor of defaulting to non-nullable values.
To me, one of the biggest issues is the lack of true exceptions. Exceptions that show the call stack (as in Java and .NET) take a lot of the mystery out of real-world troubleshooting an issue with a third-party library (for example). Panic or returning an error doesn't provide the same utility.
Go isn't going to break a lot of new ground (Hoare was talking about CSP back in the 70s), but that's fine. It's nice to have ML style languages as playgrounds for PL research, and languages like Go to help large teams be productive (the enforced style and simplicity of Go makes it relatively easy to find people who can contribute quickly to a project). Different languages have different goals, and that's great.
The last time I've looked at it there wasn't queue, deque, stack libraries in standard library. There wasn't even a UUID library. I'm not sure if it has these libraries in 1.1.
> In fact, Go is probably the only language that can claim to have a fully working Web server as part of its standard library.
Python has a built-in HTTP server (including a CGI one too).
> Go has built-in concurrency, which allows parallelism in an easier way than is possible in other languages.
How does Go make it easier than those unnamed languages? Go didn't even have race detection tool until 1.1.
Ruby and Python "have" stacks, queues, and (in Python's case) deques, but they're rarely used, because, like Golang, they have a flexible variable-length array ADT and a table ADT.
Golang has lists and rings, along with slices and maps, which capture "queue" and "stack" easily. More importantly, unlike Python and Ruby, Golang provides direct control over memory layout and a safe pointer abstraction; it's much better suited to building fussy data structure libraries than Ruby or Python.
I'm not sure I'd choose a language based on the richness of its UUID libraries.
It's funny to critique a language for "not even having" a tool that few other development environments have "until 1.1".
When all you have is a hammer...
I mean... you've found the Easter Egg, congratulations!
[Fixed the link]