
Go 1 Release Candidate 1 - jbarham
https://groups.google.com/forum/#!msg/golang-nuts/mHyYDSynkPk/9uB-FY9KXngJ
======
jbarham
One thing I especially appreciate about Go that's a huge win over other
statically compiled languages is how phenomenally fast the compiler is. E.g.,
I just re-built the current RC release on my 2.67 GHz i5, and the whole build,
_including the C bootstrap environment_ and 300k+ LOC in the standard library,
took under 30 seconds.

Recompiling my projects of a couple of thousand lines is instantaneous. It
really makes you re-think the classic edit-compile-edit cycle since the
compile time is negligible.

~~~
beza1e1
I wonder why people are so impressed by the compile times. Why it is fast, is
obvious:

1\. Do not use #include (especially in combination with C++ template
instantiation)

2\. Do not use a heavily optimizing compiler backend

The first point is fixed in every other modern language as well, so it is only
an advantage over C/C++. Go will become somewhat slower, because people want
free lunch, so at some point i expect LLVM or GCC will be used as the official
backend. Does anybody use TinyCC for his C programs?

~~~
4ad
You are mistaken about #2, optimization pass is not very relevant in total
build time, even for compilers that spend a relatively long time in the
optimization pass. Go build times are fast because 1) the grammar is not
ambiguous to yacc yielding an O(n) parser that doesn't require maintaining a
symbol table, 2) Dependency resolution is handled in an unique way, objects
pull their dependencies so if A depends on B, C depends on A, and D depends on
C and B, D doesn't need to look for B, since C contains A, B, and C. This
doesn't seem like much, but it is, build times scale linearly with the number
of objects instead of O(n^2).

The gc suite doesn't produce code as tight as gcc, but almost no code in the
world is CPU bound, everything is I/O bound.

~~~
kibwen
Could you link to a resource that describes Go's dependency resolution scheme?
Specifically, I'm curious if this means that all libraries are dynamically
linked, and if so, if this inhibits Go's ability to inline function calls
between libraries.

~~~
vetinari
Dynamically linked libraries are actually a little problem in Go. Library is
opened via dlopen()/LoadLibrary() and symbols needed are looked up by the Go
code, not by system dynamic linker.

~~~
4ad
That's not true at all. In the few cases where dynamic linking is involved, it
works just as you'd expect it to be.

~~~
vetinari
Go does not use native dynamic linker.

Please check package syscall, specifically src/pkg/syscall/dll_windows.go. You
will see for yourself, how it is implemented.

------
btipling
The language is pretty much amazing. There is so much that is right with it.
The tools are very helpful. The makefile free build tool it ships with, 'go',
is great. Things are really well documented. The source code is easy to read.
I have been working on making a control panel with Go for our APIs. It has
been pretty straight forward and painless to pick up on go.

~~~
yorhel
Actually, the 'go' tool is one of the things I rather dislike in Go so far.
It's good to have to tool that does everything for you, but I'd like to at
least be able to structure my directories in the way I want. For mixed-
language projects you won't get rid of Makefiles either way, and they're
really not that bad with the right include files or Makefile generation tools.

Using URLs to identify external libraries also isn't something I'm very fond
of. Both because you'd have more boilerplate to type when using them, and
suddenly the library is fixed to a certain internet location and VCS.

Meh, I can go on ranting about other things I dislike about Go, but it
wouldn't solve anything. I'll just keep monitoring the developments from the
sideline and see how things evolve over time.

~~~
4ad
The URLs are not really fixed, there's a feature which I am not sure if it's
documented yet that allows for an indirection between a shorter import path
and the real import path, so you could change the VCS or the real location.

------
BarkMore
According to various sources on the Interwebs, Go sucks for one or more of the
following reasons:

\- No generics.

\- No exceptions.

\- No inheritance.

\- Nullable pointers.

\- No decimal types (yet they put in complex!)

\- No IDE.

\- No support for GUI applications on Microsoft Windows.

\- Go ignores years of academic research on language design.

Please ignore the people who are happily productive with the language :).

~~~
lclarkmichalek
Funny, none of those reasons are why I now avoid go. For me what killed it
was:

\- Forcing one brace style \- Forcing naming conventions to a certain extent
\- To use the Go tool you are required to have your directories set up in a
specific way \- All types are not equal: No support for using user defined
types as map keys, maps are generic, but user defined types are not \- Two
initialization functions, new and make. One returns a pointer, the other a
struct. Seeing as go makes no distinction between the stack and the heap, is
there need for two.

Convention over configuration is great and all, but it really felt as if it
was being used as an excuse to force me to use someone else's style. Even
python which catches flak for forcing indentation as tabs let's you choose the
indentation depth and character. Go made me feel slightly violated; forcing my
directory layout was the last straw, and the lack of any configuration in a
place where it would not be complex to add it seamed stupid.

~~~
drivebyacct2
> _Forcing one brace style_

This has been discussed numerous times on the mailing list. The answer, for
good reasons, is too bad. As you note in your conclusion, consistency is
prioritized above configuration.

There's reasons for this, they were meticulously debated and chose by the
designers to help people out. If you have a pure Go project, you can install
it anywhere Go is available in a single command. No autotools, no makefiles,
no build-essentials, nothing. Just a single `go get` command.

If you ever work on a decent sized project in Go, you will quickly come to
appreciate the enforced consistency across the project.

> _To use the Go tool you are required to have your directories set up in a
> specific way_

Not with the binary distribution. And "have a source directory on GoPath" is
too restrictive... set `GOPATH=~` and for 90%+ of users, their existing dir
structure is perfectly fine.

> _No support for using user defined types as map keys_

This is no longer true IIRC.

> _Two initialization functions, new and make. One returns a pointer, the
> other a struct._

I don't understand why this is a negative?

~~~
MatthewPhillips
I've been off Go for a while, weren't they thinking about getting rid of new
at some point? I recall a long thread on the mailing list debating dropping
it.

~~~
drivebyacct2
Most of the "debates" I've seen have been people desperately trying to explain
that they do different things under the hood and thus removing the different
keywords adds 'magic' that they don't want.

------
kristianp
It's also been pushed to App Engine: [http://groups.google.com/group/golang-
nuts/browse_thread/thr...](http://groups.google.com/group/golang-
nuts/browse_thread/thread/9434eea15a05af8d)

------
melling
Wouldn't Go be a good fit for Android? That would be on my wish list.

------
jeffffff
releasing without generics is a huge mistake

~~~
p9idf
Your argument is not clear to me. However allow me to share some of the Go
authors' thoughts about generics:

<http://research.swtch.com/generic>

[http://commandcenter.blogspot.com/2011/12/esmereldas-
imagina...](http://commandcenter.blogspot.com/2011/12/esmereldas-
imagination.html)

I am inclined to agree with them. I like writing Go programs quickly, but not
at the expense of compilation speed† or execution speed. The point of Go is to
be fast. If I valued programming speed for a particular program, then I would
use the right tool for the job and choose a language other than Go.

† Though considering the speed of Plan 9-style compilers, I can't imagine at
what scale this would begin to be a problem.

~~~
ootachi
As I stated below, Go's lack of generics isn't buying the language anything
from an implementation standpoint. What Russ Cox is missing is that, absent
some way to write generic code, programmers will end up paying the exact same
taxes via their handwritten non-generic code.

Consider, for example, a binary search tree that can be instantiated with keys
of int type or keys of string type. There are two ways to implement this in
Go: (a) use an interface and dispatch calls through a vtable; or (b) implement
the tree twice, once for ints and once for strings. But note: these two
implementation strategies carry the exact same costs as the corresponding
implementation strategies for generics! In the case of (a), the programmer is
performing boxing via interface types, while in the case of (b), the
programmer is performing code duplication. So not having generics doesn't
relieve Go programs of compile-time or runtime overhead in any way; it simply
increases the burden on the programmer.

~~~
eternalban
Let's take case (a) -- that's the approach I adopted when implementing a Splay
tree, introducing a Comparator interface. Granted it is a bit of a pain to
write IntComparator, LongComparator, etc., but given that Go is _not_ an
object oriented language e.g. all types do not support a (hypothetical)
CompareTo(other T), it is not clear to me _how_ would the availability of
generics would help in this case.

For basic type coercion, yes, it is a pita to write boxing code, and clearly a
maintenance issue as well.

~~~
ootachi
The simplest way that they would help your example is by ensuring that you
can't add a mix of ints and strings to the same splay tree. Presumably this
would cause a runtime failure. Generics add type safety.

------
drivebyacct2
If this thread proves anything, it's that independent research is needed when
picking a language. There are many inaccuracies, anecdotes and personal
opinions that in my and many others' opinions don't matter once you've
actually built something useful in Go.

~~~
grourk
"There are many inaccuracies, anecdotes and personal opinions that in my and
many others' opinions don't matter..." The content of your comment renders
your comment meaningless. It's like a Hofstadter Strange Loop of
meaninglessness.

~~~
drivebyacct2
I anticipated this comment, though I decided against discussing it. The core
concept is clearly: "It's that independent research is needed when picking a
language." and my anecdote merely served to counter the negativity and
reiterate the importance of evaluating language choice based on one's needs.

