
Go is amazing, period. - dhaivatpandya
http://poincare101.blogspot.com/2012/03/experiences-in-go-ing.html
======
georgemcbay
As someone who is 38, and has programmed in everything from 6510/68k/MIPS/ARM
assembler to C/C++ to ActionScript/haxe/JavaScript to D to Python, et al, I
also think Go is pretty great.

In addition to the cool things in the language, I really love what they are
doing with the build system. The Go programming I've been doing has been on
Windows but targeting an ARM CPU (the PXA168 in the Chumby 8 device) and
cross-compiling Go code requires simply setting a couple of environmental
variables. Sooo much nicer than having to set up a full-on GNU-style cross-
compiling setup and using different toolchains for all your different targets.

eg:

set GOOS=windows

set GOARCH=386

go build

Just built my project for Windows x86.

\---

set GOOS=windows

set GOARCH=amd64

go build

Just built my project for Windows x64

\---

set GOOS=linux

set GOARCH=ARM

set GOARM=5

go build

Just built my project for the Chumby device.

\---

I highly recommend checking Go out and looking past any of the superficial
allergies you have to it (I'm historically a braces-on-their-own-line guy, so
getting used to the strict enforcement of the other style was a pain for me)
and giving it at least a few weeks to sink in. If it still isn't your cup of
tea after that, then that's fine, but it is well worth a look, IMO.

~~~
tedunangst
Windows port details? I start at golang.org, link to
<http://golang.org/doc/install.html>. Says "A port to Microsoft Windows is in
progress but incomplete." That in turn links to the world's least helpful wiki
page: Page "WindowsPort" Not Found.

Where do I find out more about the Windows port?

~~~
enneff
Go 1 is about to be released. See the install docs for Go 1 at
<http://weekly.golang.org/doc/install> \- these include windows instructions.

~~~
tedunangst
Thanks. If I was somehow supposed to know about the weekly site, I failed.

~~~
enneff
Nope, there's no way you could have known.

We've been working on Go 1 for about six months now, but have resisted pushing
people toward the weekly (unstable) snapshots until the most recent one, as
the documentation story was incomplete and we didn't want to leave newbies out
in the cold. We're nearly ready on all fronts now, and hope to pull the pin on
Go 1 before the end of the month.

~~~
canop_fr
As a coder who use mainly weekly (and now use godoc locally each time I need
the package documentation), I still find it strange not to have links between
release, weekly and tip on top of the documentation pages. Coders have to keep
in mind the three links. I see a lot of questions on sites like stackoverflow
that would probably not have been asked if the different documentations (and
their existence) had been more visible.

And I suppose this small problem won't stop with Go1 as I hope we'll see new
progress in weekly as we're used to.

~~~
enneff
You won't see progress with weekly as you're use to that's the point of Go 1.
We are hoping to spend some time actually using Go, rather than building it.

------
tpsreport
Here's a summary of the article:

* author cannot write portable C sockets code

* author cannot handle C/C++

* author believes his app would be too slow in Python, later abandons App, but retains his bias against Python

* Go has no parens for if/for

* Go has unicode support

* Go has closures "like salt shakers"

* Go is cohesively designed

* Go has nice libraries

Go may or may not be a good language, but this kind of argument is not going
to win me over.

~~~
dhaivatpandya
I usually wouldn't respond to mean comments, but, this one really throws me
off (I'm the OP).

There is a very strong difference between "cannot write" and the need for
something to be simple.

I can definitely handle C/C++, and I don't think writing something in a
higher-level language changes that.

If something is doing processing with 4000 threads with around 10 years worth
of by-the-minute data, it sure as hell will run too slow in Python.

And, the arguments stated after are not crucial to "making you switch to Go",
which was not the point of the article anyway.

EDIT: Also, I did not abandon the app, and in fact open sourced the Bayesian
filter stuff I wrote right here: <https://github.com/Poincare/Bayesian.go>

~~~
Peaker
Did you try Haskell?

Knowing Haskell makes reading about Go a very underwhelming experience.

~~~
jbarham
On the bright side, waiting for the Haskell compiler to grind away means you
have plenty of time to read up on Go.

~~~
Peaker
I don't generally wait for GHC more than a few seconds at a time, except when
I'm bootstrapping a new installation. Then I wait some minutes for "cabal
install".

Compilation times are not bad enough to be a problem.

------
ek
I really like most things about Go, and was even going to use it for a
bytecode interpreter project I was working on. A problem that I ran into,
however, was that in interpreting a dynamic language with a stack machine, we
needed a way to be able to store arbitrary data in stack values, which in
C/C++ would be done using a struct with a type flag and then a union of
various types.

Go doesn't have unions, though, and so this means that we would have ended up
using a struct and using about 3x the memory on average, per stack value. You
can see this limitation exposed as well in goyacc, the port of Yacc to Go (as
the name suggests). Where Bison uses a union for yylval, Go is forced to use a
struct.

I think this has been discussed on the golang-nuts mailing list a couple times
and dismissed, for reasons of which I'm not fully aware.

~~~
jkn
Couldn't you use an empty interface to store arbitrary values?

From the tutorial: _Every type implements the empty interface, which makes it
useful for things like containers._

Unions are on the roadmap: <http://golang.org/doc/devel/roadmap.html> but it's
a list of ideas rather than features promised.

~~~
JulianMorrison
C people: think of interface {} as roughly the same as void*, except that
values pointed to preserve information about their type which can be extracted
and used later.

------
joe_the_user
Hmm,

The complaint I see here seem to be about c/c++ libraries. TL;DR; c is too
level and boost sucks (ie, is too complexified).

Go sounds like one fine answer to this. I would claim that c++ with QT is
another answer to this. Write parsers for DSLs quickly and easily with QT -
its container classes work without nightmarish overtemplating, its string
class is like an ordinary class, etc.

~~~
rplnt
I've used glib for some "string and network stuff" with C and was quite happy.

<http://developer.gnome.org/glib/2.30/>

------
firefoxman1
Is there currently a good web framework for Go?

Edit: web.go looks pretty sweet: <http://www.getwebgo.com/>

Edit2: As does app.go: <https://github.com/georgenava/appgo>

...There's a large list of Go projects here:
<http://godashboard.appspot.com/project>

~~~
enneff
> Is there currently a good web framework for Go?

The standard library gives you almost everything you need.

The http package provides a web server and client:
<http://weekly.golang.org/net/http/>

The template package provides text templates:
<http://weekly.golang.org/text/template/> and automatically-escaped HTML
templates: <http://weekly.golang.org/html/template/>

For other bits and pieces, see the rest of the standard library:
<http://weekly.golang.org/>

I also recommend the Gorilla Web Toolkit for some other useful web-app
functionality: <http://gorilla-web.appspot.com/>

~~~
4ad
Yup, the standard library was all I ever needed. People from other languages
are familiar with frameworks and seek them in Go, but I'd say they are seldom
required. The rich standard library and the language makes everything easy.

------
j45
A lot of great and capable languages are overlooked.

The question is how do they overcome the opinion, hearsay and preferences that
are louder than the truth?

Too few devs:

\- truly give something 5 minutes before jumping to their foregone conclusion.

\- admit that most languages with a decent capable and decent programmer are
all, pretty equally equipped.

\- every language + framework has it's pros and cons.

~~~
lusr
5 minutes isn't fair. I took a look at
[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=go)
first. OK so Go is about on par with Mono's C# performance and uses up to a
1/3 of the memory with code that is more concise. That's cool because it means
I'm not sacrificing anything over the platform I specialize in (C#; although
the last time I looked at the Alioth C# code I thought I saw some obvious
improvements). I see there is a Go STOMP client for Apache Apollo, which means
I can supplement the existing code in my current project without having to
rewrite everything.

So next I looked at:

* <http://golang.org/doc/go_tutorial.html>

* <http://golang.org/doc/effective_go.html>

Way more than 5 minutes. Where are generics or do I have to learn some new
construct? Wait a minute, is this thing object oriented or what? If not, why
not? Do I have to learn some new philosophy? Already feeling a sense of dread
having been through this game 10s of times before with other languages.

I decided to research a bit to see if anybody else with a C# background had
looked into Go. I found this, which confirmed my feelings that Go is for
people who probably haven't given C# or Java a fair chance:
<http://www.jondavis.net/techblog/?tag=/c%23+vs+go> . That's when I also
discovered searching for 'Go' on Google is impossible because of the poor
choice of name and decided I wasn't going to spend any more time on it,
already being aware that aside from what looks like a total philosophy change
(without it being clear whether it'll be worth it), I'm going to lose out on
my awesome set of development tools (Visual Studio), years of C# experience
and the HUGE .NET ecosystem, in exchange for what? Relatively unimportant
performance advantages?

At the end of the day, if performance/memory are issues I can just add more
EC2 nodes to my architecture. At some point I'll hopefully make enough money
to pay other people to worry about the technology. That being said I realize
that as a developer who wants to be a manager/owner I'm probably in the
minority of readers here.

~~~
adgar
It seems you deleted your comment asking why you were downvoted. Here's why
you were downvoted:

> Way more than 5 minutes. Where are generics or do I have to learn some new
> construct? Wait a minute, is this thing object oriented or what? If not, why
> not? Do I have to learn some new philosophy? Already feeling a sense of
> dread having been through this game 10s of times before with other
> languages.

If you didn't get past the fact that Go isn't object oriented, then you
clearly didn't get very far into the language. And your resistance to "some
new philosophy" shows you aren't interested in a new language with real ideas,
but at most a different way to express what you already know and do while
programming.

~~~
lusr
It was no longer relevant and seemed to attract more downvotes. I have spent
years with x86 + MIPS assembly language, C, C++, C#, Visual Basic and
Q[uick]BASIC; months with Java, Scheme, Python, PHP; days/weeks with AS3,
HaXE, Erlang, Scala, E, Objective-C, Ruby, Delphi, Pascal, Concurrent Clean,
Prolog, ADA. I've probably missed a few.

My point is (a) I'm not a lazy developer that doesn't enjoy learning new
things or experimenting with new languages and (b) I have found a great
ecosystem in .NET and C# and I've been around the block; at first sight I
simply cannot see a compelling reason to invest more of my increasingly
limited time into learning Go.

If Go has great new vision or compelling difference from other languages then
_why isn't it there on the homepage at golang.org_ jumping out at me? All I
see are technical details and a huge guide. While I applaud clear, detailed
documentation, I'm _not_ going to read through that documentation unless I
have _some_ idea of the payoff. I just spent half of my weekend researching
and investigating a ton of message brokers for my current project because
there's value in the outcome. Researching a new programming language needs to
have a huge payoff, or I need to have lots of free time (which unfortunately I
don't).

There is _absolutely nothing_ to sell me on the language on the homepage, or
in the OP's blog post, and nothing to distinguish it from the 10s of other new
languages out there. The FAQ touches on the fact that e.g. it's not object-
oriented but not WHY. It just mentions "interfaces" and says "we believe". So
I'll have to go and play with it and build something substantial to find out
what they _might_ be talking about. The goals mentioned in the FAQ are really
not interesting (have you read it?) - perhaps the ideas around concurrency are
convenient but they are limited in scope and don't directly address the more
complex concurrency issues better than my current platform that I'm facing
while I build a web crawler.

To be clear once again: It may be that Go is absolutely amazing and awesome...
but if I had to spent days looking into every new language that pops up on the
Internet I would never get anything done, and this is the point I was trying
to convey in response to the parent's post. It's still on my list to look into
but I just don't have a week to commit to what looks like quite a lot to
manually digest.

~~~
Kototama
Given all the languages you already programmed with, and given that the Go
specification is relatively short (approximately the same as Scheme), maybe
you overestimate the efforts it would require to learn it. But you don't need
to, that's all fine.

~~~
lusr
Heh I think you inadvertently proved my point. I spent 6 months with Scheme,
working through half of the SICP for personal growth. Just because the
specification is simple it doesn't mean the patterns and lessons are
straightforward, and I'm a pretty slow learner. If you read the Go FAQ you
will note that about 1/3 of it is along the lines of "Why doesn't Go...". When
I see that sort of language it's clear that between the lines there's a lot to
learn, and the only way for me to learn a language is to write code.

But after all of this I think I'm going to have to write one of my site-
specific crawlers in Go for fun; since Go has a STOMP binding it should be
easy to integrate into my existing architecture. Where things will get
interesting is finding a compatible serialization library (and so we start
getting into the real world problems of using a new language to solve
interesting problems... hopefully one of the .NET protocol buffer
implementations will work correctly with the one I imagine exists for Go).

~~~
adgar
> hopefully one of the .NET protocol buffer implementations will work
> correctly with the one I imagine exists for Go

That's one of the primary points of protocol buffers ;-)

------
jwr
Support for Unicode as a groundbreaking language feature? Closures (and first-
class functions) as a major achievement?

I don't want to sound smug, so I won't mention any languages I'm comparing to
— but seriously, unless you've been living in Python-land, those things are
nothing to write home about. I'm surprised this is getting so many upvotes.

If I were to praise Go, I would concentrate on something innovative —
concurrency primitives are interesting, for instance. I would not consider
them sufficient for all applications, but they are intriguing and worth
discussing.

~~~
saulrh
Closures and first-class functions aren't an achievement. Closures and first-
class functions in a language low enough and fast enough level for systems
programming? That's an achievement. Same for unicode. These aren't just
features. These are features done _fast_.

~~~
unlogic
Lisp has been having all these for five decades now and those features are
done fast.
[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=go&lang2=sbcl)

~~~
jff
So much for Lisp as the ultra-expressive, compact language, I guess...
Impressive speeds, though.

~~~
unlogic
Well, the link to the shootout statistics is probably not the best
demonstration for Lisp speed/memory consumption/SLOC count relation. If you
look into the Lisp sources there you will see that there are lot of things
precompiled for the sake of reducing the execution time. Here's where the
extensive memory usage and source size come from.

I intended to say that Lisp's and Go's both performance and succinctness in
the wild are probably on par. But Lisp is already there for a long time.

~~~
jwr
This discussion is increasingly weird and non-technical, mostly because there
is no such thing as "Lisp". There are implementations of Common Lisp,
implementations of Scheme, there is Clojure on the JVM, all of those are in
the "Lisp" family. So comparing a particular language to "Lisp" makes no
sense.

And I don't understand the comment about things being "precompiled". So what?
Compilation is a natural step. Note that with most lisps "compilation" is not
something you wait for while your server farm keeps crunching .c files, it's a
natural step, sometimes happening behind the scenes.

~~~
unlogic
> This discussion is increasingly weird and non-technical, mostly because
> there is no such thing as "Lisp". There are implementations of Common Lisp,
> implementations of Scheme, there is Clojure on the JVM, all of those are in
> the "Lisp" family. So comparing a particular language to "Lisp" makes no
> sense.

Since I've posted a link to Shootout comparison of Go and Common Lisp I
thought I made it clear which Lisp I was talking about.

> And I don't understand the comment about things being "precompiled". So
> what?

It means that a descent part of the computation was done in the compile
(macroexpansion) time and this time was not measured and included into the
total result. This may be great for cheating Shootout benchmarks but does not
fairly demonstrate the performance of the language.

------
juliennakache
Wow. This dude is 14 year old.

~~~
oomkiller
Yep, and he just released his bayesian alg he talks about here:
<https://github.com/Poincare/Bayesian.go>

------
Aqueous
"And, the worst problem I faced was of sockets. Non-blocking, multi-plexed and
cross-platform socket support with C is basically non-existent (unless I
wanted to use libev or libevent,"

What are you talking about? Most every single evented io library out there
just boils down to a single system call in the underlying language - C:
epoll(or select, poll, or kqueue) on socket/file descriptors. You do know that
socket() returns a socket, which is actually just a file descriptor, right?
You don't need libev and libevent because you can just write your own in two
seconds with epoll! And if you're really attached to having the library handle
the work for you you can always use one of the many cross-platform event
libraries, like Glib which, last I checked, works on Win32, Mac, and Linux.

------
jstepien
_I couldn't sacrifice performance (lots of number crunching was involved with
costs tight), so, I couldn't pick Python._

PyPy, Cython or Shed Skin might have been answers to those number crunching
problems. I'd love to learn whether they would be sufficient for OP's
performance requirements. Some benchmarks look promising, for instance this
one published in late 2010: [http://geetduggal.wordpress.com/2010/11/25/speed-
up-your-pyt...](http://geetduggal.wordpress.com/2010/11/25/speed-up-your-
python-unladen-vs-shedskin-vs-pypy-vs-c/)

------
halayli
The OP easily dismissed numpy in Python and coroutines (e.g gevent)

~~~
zemo
to be honest, I've used both gevent and Go and concurrency is far more natural
in Go. Sure, you can do most of what you want with gevent, and if you're using
stackless or pypy you can even have channels, but implementing concurrency at
the library level is a mistake. It feels bolted on. It's like how some
programming languages weren't object oriented from the start, but then they
bolted an object system on top of it in a later release; it feels kludgy and
you notice that it's bolted on. Concurrency in Python reminds me of that. Yes,
it works, but it's awkward and feels like a second-class citizen.

~~~
jbarham
I've done concurrent programming in both Python and Go, and to be fair to
Python, its standard library queue class
(<http://docs.python.org/library/queue.html>) is very close to Go's channels
so it does CSP style concurrency quite nicely.

However, Go's goroutines are IMHO superior to Python threads since they're
much more lightweight and can run in parallel on multi-core CPUs and you can
have a lot more of them.

Go gets it right by putting goroutines and channels into the core language to
encourage CSP style concurrency, but putting other more traditional, but
harder-to-use, concurrency primitives like mutexes into the standard library.

~~~
luriel
I agree with most of your comment. But I'm sorry, this part is not even close:

> its standard library queue class
> (<http://docs.python.org/library/queue.html>) is very close to Go's channels
> so it does CSP style concurrency quite nicely.

Among other things, it lacks any construct similar to Go's `select`, without
which channels are nowhere nearly as useful.

And then there are issues like what you point out about how incredibly cheap
goroutines are.

------
srean
I have'nt managed enough time yet to familiarize myself with Go, but the
little that I have glanced at, it seems a nice enough language for scientific
computation. The syntax and semantics of arrays are nice and binding to C is
purportedly simple. Ease of binding with Fortran would have been nice too. So
I find it a bit strange that I never hear of Go in the context of array based
computation, that is the stuff people use Numpy, MATLAB, J, K for.

Is there any particular reason for that or is it just that not many have got
around to doing it.

A type-inferred language with first class functions, with strong support for
parallelism, and good support for arrays and slicing seems a really sweet
deal. Throw in SIMD and it is already very compelling. Is anything wrong with
the picture that I am missing. Performance issues ?

~~~
ootachi
The concurrent stop-the-world garbage collector is a performance issue.
Additionally, the Plan 9-based compiler is not an optimizing compiler.

~~~
dsymonds
Have you found the GC to be an actual problem? Or are you assuming it is? It's
a very different situation to other GC-based languages.

~~~
ootachi
Why is it so different? I'd be curious to know.

In my experience, a stop-the-world collector that must be threadsafe ends up
being a disaster. You hit a brick wall in terms of real-time performance
quickly (look at iOS versus Android for an easy example, and Dalvik's GC is
much more sophisticated than that of Go these days).

I predict that Go is going to have to put a _lot_ of effort into making the GC
fast in order to compete with C++ and Java. They're going to need a
concurrent, generational garbage collector much like Java's, probably with a
server mode and a client mode. It'll have to be heavily tuned and will require
man-years of work.

~~~
enneff
Java requires a powerful, sophisticated garbage collector because it is
extremely difficult (and in many cases impossible) to write Java programs that
don't generate a lot of garbage. Even many of the core APIs are allocation
heavy. It's a pain.

Go data structures tend to be much smaller than the Java equivalents, and it
is much easier to track down and eliminate unnecessary allocations in Go code.
When you have better control over allocations you don't need to lean so hard
on the garbage collector. (Some of this is touched on here
<http://loadcode.blogspot.com.au/2009/12/go-vs-java.html>)

You seem to have a lot of strong opinions (and predictions!) about Go, when
you clearly don't have much experience with it.

~~~
ootachi
Go gives you slightly better control over allocation than Java (in that you
have a choice to allocate on the stack and inside other data structures -- but
keep in mind that escape analysis can give you this too, see the optimizations
in the Jikes RVM). However, in Go, you still have no choice but to allocate on
the heap in many instances (for example, when returning a data structure from
a function, or when using maps, etc.) You're taking a big bet that programs
will be able to use the stack and manually use free lists or whatever (which
you can still do in Java!), and that the slow performance of the GC won't be a
problem. I wouldn't take that bet.

Besides, once you have a stop-the-world multithreaded GC, it has to trace all
the roots in the program for correctness. There's no way around that. At that
point having all the data on the stack doesn't help you (except for cache
locality, but Java's GC already does that via the nursery and copying during
major collections). You must still trace every pointer in the object graph,
while keeping all threads suspended. You can run the GC less often, but that's
not much of a help when interactive performance is at stake. iOS feels so
great because the UI is _always_ running at 60 frames per second. Stop-the-
world GC can't do that.

~~~
dsymonds
We don't bet, we experiment, measure and analyse. So far, I have found memory
allocation in Go to be extremely predictable and controllable, and the GC
behaviour likewise predictable.

I don't know why you claim that "having all the data on the stack doesn't help
you". That makes no sense. If data is on the stack, any references starting
there disappear as soon as that stack frame is popped, so there's no lingering
work for the GC to do; the GC arena is unchanged.

Your comments strongly imply that you have no practical experience with Go's
GC. I suggest you stop claiming that it has certain performance
characteristics or behaviours when you have not experienced it yourself.

~~~
ootachi
"If data is on the stack, any references starting there disappear as soon as
that stack frame is popped, so there's no lingering work for the GC to do"

You're only considering the sweep phase. Sweep is the easy part of tracing GC
- you can always chuck sweep into a background thread. The mark phase is the
problem. Marking always has to trace roots, including stack roots - that's how
GC works. Tracing GC never traces dead objects.

You can reduce allocation pressure by using the stack, which will make the GC
run less often, but my point is that when it _does_ run you're no better off
than Java, and quite a bit worse since Java's GC can run in parallel with the
mutator and Go's can't.

"Your comments strongly imply that you have no practical experience with Go's
GC. I suggest you stop claiming that it has certain performance
characteristics or behaviours when you have not experienced it yourself."

I have experience with GC generally. There's nothing particularly special
about Go's GC: it's a standard stop-the-world mark-and-sweep collector for a
language that supports a limited form of stack allocation but generally uses
heap allocation. The performance characteristics that this form of GC must
have are well-known.

If you want data, look at the binary-trees benchmark:
[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=go)

It's mostly a test of GC. Java's GC runs more often (thus the memory use is
lower) and yet it's still 4x faster. This is because Java has a generational,
concurrent-incremental collector.

------
chmike
I looked at its serializing documentation and I was surprized to see that
every floating point value is serialized to a double precision value. There
are now four types of foating point values and this simplification is
downgrading the capabilities of data tranfer. Extended is needed in some
scientific computations. Appart from this, the base type encoding is great.
The other weird choice is the structure encoding with field numbers and
omitting null value fields. My impression is that this is less efficient than
coding the null fields. Is this choice based on measurements ?

------
sigzero
Inside a function, the := short assignment statement can be used in place of
the short var declaration.

(Outside a function, every construct begins with a keyword and the :=
construct is not available.)

===

Why is that? I would find that frustrating and inconsistent.

------
andrewnez
Incidentally we're hosting a free "Evening with Go" tomorrow night in London:
<http://eveningwithgo.eventbrite.co.uk/>

------
observer1
If you are going to create a headline that ends with ", period." the content
of the article had better contain a cohesive and very strong argument that
supports the emphasized statement. You could have easily posted - "Go is
amazing." That is a statement of opinion -- which pretty well describes the
article and the author's place as an expert. "Go is amazing, period." claims
something much deeper, which the article completely fails to deliver.

------
Osiris
My background is in garbage-collected languages, including .NET and PHP.
Because of my lack of background in manual memory management, I've always been
nervous to try to learn C, even when it may be a better approach.

Go sounds like a great language for someone with my background to be able to
work with a closer to the metal language but by handling some of the more
difficult aspects of working with C like memory management and pointer
arithmetic.

------
namidark
So he recommends Go but has never actually used it? The only reason he looked
at it again was the potential to use it for a small project he never finished
or did I miss something?

------
fdb
How would you call foreign functions in C or C++ from Go? Is there something
like a foreign function interface?

~~~
jkn
From <http://blog.golang.org/2011/03/c-go-cgo.html> :

    
    
      package rand
      
      /*
      #include <stdlib.h>
      */
      import "C"
      
      func Random() int {
         return int(C.random())
      }
      
      func Seed(i int) {
         C.srandom(C.uint(i))
      }
    

So calling C functions from Go is very easy. However the other way is not
supported, AFAIK.

~~~
luriel
Calling Go from C is supported, but is not quite as straightforward. You can
also use SWIG.

------
prtamil
Is the Author is 13 years old. When did he really start programming.? just
wondering After 16 years of programming experience still not able to decide
which language is best. At last Settled for C and Common Lisp. But still have
Doubts. As per Personal Experience Both Language is more than enough for me.

~~~
prtamil
ok guys,, Let me print my wisdom, "Its not the programming language its
You,its always you"

------
briancurtin
> The first thing I immediately noticed is that they got rid of the
> parentheses in "if" and "for" statements. Coming from Python, I really like
> this.

Python doesn't enforce any parenthesis in those statements, so how were you
using them in Python that changes how you'd do the same thing in Go?

~~~
andrewflnr
I assume he likes it _because_ it doesn't change anything. He's used to the
Python way.

~~~
briancurtin
Maybe I'm missing something, but "they got rid of the parentheses" sounds like
either Go used to require parentheses for this or he thought Python did. If it
was the former, then I misread (I don't know very much about Go).

~~~
travem
The author is writing in the context of moving from c and c++ so I imagine
he's talking about getting rid of c style parenthesis.

------
swah
I'd love to have Python library availability in a staticly typed language.

~~~
ootachi
Many statically typed languages have excellent library support. At this point
Java, for example, has all of the libraries that Python has, and more.

~~~
edwinnathaniel
Not only excellent library support, but also a large array of productivity
tools ranging from superb IDE, static code analysis, build+dependency tools,
great Continuous Integration, etc.

------
nsomething
Go needs Allman style. It's unnatural to me otherwise

------
Radzell
I like go. As a guy who really doesn't like javascript I like the structure of
GO. I like really structured languages. For anyone who like the mobile/desktop
type of programming this seems like a refreshing change.

~~~
ootachi
Er, JavaScript is a structured language (meaning it doesn't mandate labels and
goto for control flow).

~~~
enneff
I think what your parent is referring to is that, compared to JavaScript, Go
provides a fairly rigid structure in which to write programs. You write
packages that consist of type, function, and variable declarations, and link
them together with import statements. Its rich standard library supports a
range of useful, omnipresent interfaces, which make it easy to do things in an
obviously correct, interoperable way.

By comparison, JavaScript lets you structure your code in however you like,
and there is a very tiny standard library and no real uniformity across
implementations, frameworks, and so on. This can be a strength, but I think on
balance it is a real weakness in JS. node.js has done a lot to improve this,
though the language itself still lets you define anything, anywhere, at any
time, and change that state from anywhere else.

~~~
ootachi
"By comparison, JavaScript lets you structure your code in however you like,
and there is a very tiny standard library and no real uniformity across
implementations, frameworks, and so on. This can be a strength, but I think on
balance it is a real weakness in JS. node.js has done a lot to improve this,
though the language itself still lets you define anything, anywhere, at any
time, and change that state from anywhere else."

Not true with ES6 modules.

Besides, Python and Ruby have open modules, and that hasn't hurt their
usefulness in the real world. Quite the opposite, actually; one of the great
pragmatic strengths of Rails was that it monkey patched Ruby's standard
libraries. It's hurt _optimization_ , but that's a different story.

------
rian
i truly believe go contributes negative work to society. it's basically
C/C++/Java/C# with syntactic sugar except it's different enough to get bored
programmers to waste their precious time reporting all their code.

if you want to learn a new language, actually learn a new language. learn a
language that's actually breaking the mold in terms of how we communicate with
computers. think at a higher abstraction level than dynamic dispatch and
composable objects and subroutines, that stuff is already more than 40 years
old.

[http://www.thocp.net/biographies/papers/backus_turingaward_l...](http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf)

~~~
jshen
I completely disagree. My goal is to build better systems, and if an
evolutionary change helps this, then that's where I'm going.

You seem to value "breaking the mold" for the sake of "breaking the mold" Or,
you didn't give a good reason to value it.

"that stuff is already more than 40 years old.". Is this the fashion industry?
Or do you believe that quality is a function of age?

~~~
njharman
I agree with your goal. But the parent is correct in that learning a really
different language will help __you __become a better developer and thus build
better systems.

~~~
jshen
That isn't the only thing he said. I'm all for learning different paradigms,
but he made a much different argument.

"i truly believe go contributes negative work to society"

