

An Introduction to the Go Language - Baustin
http://blog.smartbear.com/programming/an-introduction-to-the-go-language-boldly-going-where-no-man-has-ever-gone-before/

======
chrismorgan
> In fact, Go is probably the only language that can claim to have a fully
> working Web server as part of its standard library.

 _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.

~~~
coldtea
> _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.

~~~
gizmo686
Isn't Node a JavaScript framework for webservers?

~~~
coldtea
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.

------
gnur
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.

~~~
dons
> no unexpected side effects

No one ever expects the side effects

------
lelf
_Boldly Going Where No Man Has Ever Gone Before_

Eh.. where?

~~~
happy_dino
I agree. These absurd claims are increasingly disturbing.

Seems like a lot of Go fans have lost touch with reality.

~~~
jff
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.

~~~
happy_dino
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.

------
iand
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?

~~~
pjmlp
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.

~~~
coldtea
> _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!

------
david927
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.

~~~
pekk
Why is Go "distressing"? If you don't like it, you don't have to use it?

~~~
throwit1979
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)

~~~
jerf
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.)

~~~
throwit1979
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.

~~~
jerf
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.

------
human_error
> 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.

~~~
tptacek
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".

~~~
gnuvince
> 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...

~~~
tptacek
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.

------
UbuntuJon
Funny that the link to Java page on Wikipedia is for the Indonesian Island :)

~~~
Baustin
Ahhh damn!

I mean... you've found the Easter Egg, congratulations!

[Fixed the link]

------
kmicklas
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/)

~~~
jff
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.

