An Introduction to the Go Language(blog.smartbear.com)
blog.smartbear.com
An Introduction to the Go Language
http://blog.smartbear.com/programming/an-introduction-to-the-go-language-boldly-going-where-no-man-has-ever-gone-before/
8 comments
>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.
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.
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.
[deleted]
Isn't Node a JavaScript framework for webservers?
Well, it's mostly THE way to use Javascript (or ECMAScript if you wish), the language, on the command line.
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.
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.
No, it's a platform (raw server).
The author of this blog post is wrong to so designate Golang, which obviously isn't the first development environment to be bundled with a production-caliber web server.
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.
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.
> > 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 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.
> 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.
You're right of course, but it bears mentioning that the way the Python web server is implemented, it cannot handle any significant load. It's not a "real" web server in the sense that it'd generally be a bad idea to try to use it for real work.
And Node most of of Node's standard lib is for its web server.
Otherwise the articles more or less on point.
Otherwise the articles more or less on point.
Go is one of the least exciting languages introduced in recent years but is still one of the more popular languages.
I think that it really is a selling point how boring go is, there are no quirks, no unexpected side effects, no amazing flexibility and when something compiles, it very often does exactly what you wanted it to do.
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.
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 unexpected side effects
No one ever expects the side effects
No one ever expects the side effects
Your comment reminds me of Google search, which is also quite simple in front (the UI/usage) and very complex under the hood.
[deleted]
Boldly Going Where No Man Has Ever Gone Before
Eh.. where?
Eh.. where?
I agree. These absurd claims are increasingly disturbing.
Seems like a lot of Go fans have lost touch with reality.
Seems like a lot of Go fans have lost touch with reality.
It's a (rather poor) take on the name "Go". Boldly GOing. But by all means, ascribe it to some mental failing of Go programmers, any more so than say Scala programmers.
At least I'm acting better than people who think they need to stalk my comment history before replying.
And, no, not all communities are behaving like Go fans do.
And, no, not all communities are behaving like Go fans do.
[deleted]
It was just a play on words... not meant to be taken literally or seriously.
Bizarre that the HN audience are self selecting articles like these with their upvotes. How many more introductory blog posts on Go do we need?
Specially if they tend to ignore most Go features were already available in the Pascal/Modula/Oberon language family.
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.
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.
>Specially if they tend to ignore most Go features were already available in the Pascal/Modula/Oberon language family.
OK, Go is not Oberon/Modula, we got it already man!
OK, Go is not Oberon/Modula, we got it already man!
Articles with titles containing 'Go' seem to get upvotes simply for including the magic word.
Indeed. Go is awesome, but this article is not. If you seek to learn more about Go, try http://tour.golang.org/#1
This article may not be as interactive as the tour, but I do think it's still a good introduction to the language, written by a Google employee.
To paraphrase Alan Kay:
Go makes you think that the new ideas are like the old ones. Go is the most distressing thing to hit computing since Java.
Go makes you think that the new ideas are like the old ones. Go is the most distressing thing to hit computing since Java.
Why is Go "distressing"? If you don't like it, you don't have to use it?
For anyone that doesn't know the original quote:
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 )
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 )
My understanding is that Go haters take issue with three things:
- 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)
- 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)
It's not that nil exists... it that it exists everywhere (on the types that support it), with no way of restricting it. It's actually the one criticism I find the most frustrating because, unlike generics and unlike interface{} (which is sort of a repeat of the generic complaint, that's an effect), it's so easy to fix that during the initial design, and it would not have profoundly affected the rest of the language. In fact it could still be bolted on after the fact, it's that easy and low-impact. That not all types support nil in Go is itself an interesting point; zero types are better than nil, so why didn't we propagate the idea that is already in Go through the language consistently, and not let anything be nil unless we explicitly request it in the type?
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.)
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.)
Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wrong", but the languages in use (e.g. Java) force them into situations where, for example, returning null to mean "this entity wasn't found" is substantially more productive than catching and processing EntityNotFoundException.
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.
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.
Go look at C#, or any other language that has this concept. The point is not that there would be no nil, anywhere, ever, the point is that you would have to ask for it, and by default, you get a type that can't contain nil.
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.
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.
Removing nil from Go is not possible without breaking backwards compatibility. The Go core team considers nil a feature anyhow.
> zero types are better than nil
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.
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.
I'd rather have a pointer initialized to a new zero-type value, or require you to initialize it as a pointer to an existing thing.
Forced-nil pointers are a disaster.
Also, please re-read my last two paragraphs.
Forced-nil pointers are a disaster.
Also, please re-read my last two paragraphs.
So you'd rather have the Go runtime allocate the full structs (with all fields zeroed but still consuming the same memory) exactly everywhere they aren't even needed?
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"?
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"?
"current easy-to-grok, quick-to-fix 'nil-pointer error'"
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.
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.
Those three flaws are brought up repeatedly because they are a sad regression from the current state of the art in programming language construction. It could've been a much nicer language with very little effort, but its designers chose not to do so.
I like Go. I really want it to succeed as a language. However, it does have some unfortunate warts.
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.
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.
There's a certain elegance (that some ML-Style languages have) that Go forgoes in favor of simplicity. That's often not a bad tradeoff. Simplicity is a nobel goal, and is one of the big reasons for using Go.
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.
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.
[deleted]
> Go has a rich standard library which covers a lot of areas.
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.
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.
Python's built-in HTTP server isn't well-suited for production apps. Golang's HTTP server is the production standard. That's not an apples-apples comparison.
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".
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".
> 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.
When all you have is a hammer...
When all you have is a hammer...
The reality is that Python lists usually work as serviceable queues and stacks. Criticizing a language for not having a standard queue or stack is a little weird.
The really sad thing about Go is that it actually is mostly better than its (non-obscure) competitors. I am disappointed in Google because they could have done so much better. All the problems in Go are basically "solved" problems. They just chose to take the "New Jersey" approach. This article summarizes the situation pretty well:
http://monoc.mo.funpic.de/go-rant/
http://monoc.mo.funpic.de/go-rant/
Do you know the origin of the name, "New Jersey approach"? It was these guys. These guys invented the New Jersey approach. Go is the result of 40 years of OS and programming language work primarily done at Bell Labs in Murray Hill.
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.