Go and... what else?

[Peter Kleiweg]

I've been using Go for nearly a year now, and it has taken
central stage in most serious coding I do. Before, it was mainly
C and Python.

Lately, the only C programming I did was writing simple wrappers
for a few C and C++ libraries, so I can use them from Go. I
tried Swig, but I prefer to do this by hand.

I still use Python, but not without the feeling I might have
used Go as well, and getting things done faster and better.

And of course, I use several tools for small stuff (like a one
line Perl script for a simple task), and special purpose
languages like R or PostScript.

But for general purpose, serious coding, it seems like Go is
first choice, without competition.

This makes me wonder, am I missing something? Surely, you can't
have a single solution that works best in all circumstances?
Does using Go, and my fondness of this language, narrow my view
to the things Go allows me to do?

My question to you all is: if you are free to choose any
programming language, what are circumstances where you think Go
is not the best option?

What are languages worth learning besides Go, and why? (Aside
from external factors such as job opportunities and working on
existing code already written in other languages.) What are
languages that complete Go?

What other languages do you think are as fun and useful to learn
as Go?




--
Peter Kleiweg
my Go programming cookbook: http://www.let.rug.nl/~kleiweg/go/

[Patrick Mylund Nielsen]

Nope. I'm in the same boat as you. Used C and Python before, and now it's almost exclusively Go. I don't start any new projects in C, and I use Python only for rapid prototyping, especially when it's some simple math.

I've used Python for one new project recently, and that was because other members of the project preferred an ORM and a Jinja/Django-style templating system, so we went with Pyramid and Chameleon/ZPT. I have a constant "this would be so much faster, and almost as easy" in Go at the back of my head all the time though :) Also, interestingly, I've become quite bothered by Python's overly long variable and function_names after spending most of my time with "C/Go-style."

The language I've enjoyed learning as much as Go, and one that was very eye-opening, is Haskell. I can definitely recommend learning it, or something similar like CL/Scheme/Clojure or OCaml. I'll use Haskell when it seems like the problem I'm facing could be solved more easily in a functional way, but, otherwise, Go has become my go-to language :)

[Joel Webber]

I've been a C[++] programmer the majority of my career, and had to switch mostly to Java and Javascript for the last 8 years or so (with occasional flashbacks to C++ for low-level and WebKit work). While I've always missed the simplicity of C, I don't miss dangling pointers and reference-counting bugs (or, god forbid, string [de]allocation bugs across various flavors of the win32/com/ole/god-knows-what runtimes)! So I was mostly convinced that Java was a net win (or even better, C#) -- even if I never particularly loved the language.

A coworker finally convinced me to take a look at Go, and after a day or two I was convinced that almost every decision made in the language design was exactly what I wanted. Even the constraints it imposes are easy to understand, and it's usually fairly obvious why a given constraint exists and what you get out of accepting it. As I think someone said in the quotes file, "it's like a better C brought to you by the people that didn't bring you C++". I particularly love the fact that it produces a simple, statically linked binary, just like C, that starts in a few milliseconds. You know, what we used to call a "program", which is something you run directly on an "operating system". Makes me want to burn all the VMs to the ground :)

Since then, we've started using it for bits and pieces in our new company (the guy who talked me into trying out Go is a cofounder). We wanted to build all our server infrastructure in it, but the still-somewhat-weak debugging situation was a showstopper for us. I filed a few bugs with Luuk, and remain convinced that it will be something we can use for all our server code next time we're due for a rewrite -- maybe in a year or so.

(I know, I know: "real" programmers don't use debuggers. I've never bought into that particular flavor of BS. I find having good tools and a good, low-friction debugger to be absolutely invaluable in understanding code, especially if I didn't write it, but even if I did. "gocode" + sublime was good enough for the first half of this problem, but the gdb bugs blocking us were just too much for day to day use.)

In the meantime, we'll continue using it for all our deployment and build scripts, utilities separable from the main server code, and so forth. I find it to be leaps and bounds better than Python and Ruby for this kind of thing, and it doesn't become an incomprehensible mess once you get past a few hundred lines! Hopefully we'll be able to rewrite server code in Go before too long.

Now all I need is a way to target Javascript, iOS, and Android so we can write *everything* in Go. But that seems like a distant pipe dream at this point (I've worked on translating other languages to Javascript before, but the devil's always in the details, so I think it will be quite a while before anyone does a production-quality job on this).

[dga]

On Wednesday, July 4, 2012 2:47:30 PM UTC-4, Peter Kleiweg wrote:

My question to you all is: if you are free to choose any
programming language, what are circumstances where you think Go
is not the best option?

Go:

    rpc.Register(master)

    rpc.HandleHTTP()

    l, err := net.Listen("tcp", fmt.Sprintf(":%d", *portnum))

    if err != nil {

        log.Fatal("Master listen error:", err);

    }

    go master.run()

*ahhhh*. :-)

No Go (yet), almost all related to performance:

1)  inside a concurrent, single-writer multiple reader optimistic hash table implementation designed for 10s of millions of requests per second, which uses some of the lower-level atomic primitives for high performance and safe concurrent access:

    vs = __sync_fetch_and_add(&ht[h1].seq, 0);

...

    ve = __sync_fetch_and_add(&ht[h1].seq, 0);

and/or similar examples using per-CPU locks in cacheline aligned structures.

2)  As others have noted:  Realtime.  The former example (go master.run(), etc.) suffers from a *lot* of performance variance due to the garbage collector.  To the point where it bugs us, but not quite enough to abandon Go.  (But we're not aiming for realtime, just 99.9%ile.)

3)  Heavy use of crypto.

4)  Heavy use of GMPlib.

The latter is actually an interesting case, because while part of the rationale is performance, another part of it is ease of use:  This is one place where C++ operator overloading makes things much, much more readable.  Using GMP in C++ looks like:

  mpz_class x, y, z;

  x = 5;

  y = 5;

  z = z+y;

As opposed to Go's more C-like requirement of writing:

  mpz_add( ... );

For most things, I find Go a heck of a lot more concise and pleasant than C++, but not for high performance high precision math.

5)  Integrating with GPGPU programming. 

5a)  Many-core applications that aren't trivially parallel.

That's a long list of negatives, but keep it in the right context:  I've switched my entire undergrad distributed systems course over to using Go because I feel that it's the best language for that domain.  Most of the "don't use" scenarios I gave were particularly performance-critical, and of those, many of them, though not all, should yield to long-term performance improvements in the Go compiler and libraries.  I do a lot of my personal projects in Go as well, because it's just way more fun to program in than C++ is.

  -Dave

[Matt Joiner]

I'm a huge Python fan, but since the go1 release I haven't been able
to justify writing anything larger than trivial programs in Python. I
also wrote a lot of C, but much of the time that was to avoid issues
with concurrency overhead in Python. Other than Go, I'm really only
using a little C and Python now.

[Matt Joiner]

I'll add my biggest difficulties with Go have been poor
interoperability with C (shared libraries, foreign thread callbacks),
lack of bindings, and lack of library maturity, but I'm optimistic.

[Job van der Zwan]

Peter, am I correct in recalling a post from a few months ago where you stated that you were just trying out Go, but were quite skeptical about it being the right language for you? :)

Anyway, I hardly use Go at all, because the programming I do is pretty much always related to real-time visualisations that have to be easy to use and deploy cross-platform, making Processing, Cinder and OpenFrameworks (java and c++ libraries for "creative coding") the easier choices at the moment.

However, Go is my favourite programming language I hardly use. That probably sounds a bit weird, so I'll try to justify it.

In my case, from the first time I watched a youtube lecture by Rob Pike on Go's interfaces, I was convinced it was the language I had been waiting for without knowing it. I know, completely ridiculous. In fact, I was following the development Go for over a full year before I actually started programming in it.

The thing is, I'm quite chaotic, and easily lose track of the big picture. So when have an idea for a program, I usually grab a pen and paper first to get my thoughts in order: what's the idea behind the program, how do I translate that to an algorithm, how do I translate the algorithm to actual code etc. Turns out that the Go syntax is pretty similar to how I tend to write pseudocode for C++ or Java, except, you know, shorter, clearer, more expressive... and it compiles. Blazingly fast.

It hits a sweet spot of similarity to programming languages I already know, and a greater ease of use. If I read someone else's source Go code, and don't understand what is happening, it's never because I have difficulty figuring out what the language is doing. It's neither too cryptic nor too verbose, nor too "magical". That makes it a thoroughly enjoyable language to learn new programming concepts in.

And it makes concurrency so easy even I can use it.

And gofmt reduces the need for self-discipline when it comes to coding style.

It's only a matter of time until the third party libraries cover everything Processing/Cinder/OpenFrameworks is better at at the moment, and then I'm sure it will take over as my main programming language.

Actually... I just realised... maybe I can use SWIG to get all the benefits of the OpenFrameworks library in Go... I'll have to look into that :).

[Matt Kane's Brain]

On Wed, Jul 4, 2012 at 7:52 PM, Job van der Zwan
<j.l.van...@gmail.com> wrote:
> It's only a matter of time until the third party libraries cover everything
> Processing/Cinder/OpenFrameworks is better at at the moment, and then I'm
> sure it will take over as my main programming language.

Yeah, I like Go for these purposes as well. I would love to use Go to
control SuperCollider's synth server instead of its weird language.
(In fact, I've used Go programs to write SuperCollider scores)

> Actually... I just realised... maybe I can use SWIG to get all the benefits
> of the OpenFrameworks library in Go... I'll have to look into that :).

That will be tricky. openFrameworks has its own main(). Maybe you
could do some IPC something?

--
matt kane's brain
http://hydrogenproject.com

[Andrew Wilkins]

On Thursday, 5 July 2012 02:47:30 UTC+8, Peter Kleiweg wrote:

My question to you all is: if you are free to choose any
programming language, what are circumstances where you think Go
is not the best option?

I was gushing about Go to a colleague yesterday, and he asked when

would I use it? My answer was "almost always". I program primarily in

C++ and Python, and in Java when circumstances dictated. Go has

mostly supplanted my need for Python, save for odd one-off scripts.

It has also mostly supplanted my need for C++ in side projects.

There are two primary reasons why I can't push Go in my workplace

for the near future. Much of the software I work on runs on numerous

platforms not supported by the Go compilers, and ones that probably

never will be (like HP-UX PA-RISC). The other reason is performance.

Go is fast, but sometimes you need to go (pun not intended) faster

still. Sometimes you need more control over memory than a GC affords.

Andrew

[David Symonds]

On Wed, Jul 4, 2012 at 6:44 PM, Andrew Wilkins <axw...@gmail.com> wrote:

> There are two primary reasons why I can't push Go in my workplace
> for the near future. Much of the software I work on runs on numerous
> platforms not supported by the Go compilers, and ones that probably
> never will be (like HP-UX PA-RISC).

Are you sure? Does gcc work there? If so, gccgo should work.


Dave.

[Andrew Wilkins]

Perhaps, but we don't use gcc on HP-UX for a variety of interoperability reasons.

The reason I assumed PA-RISC wouldn't be supported even by gccgo is due

to its anaemic atomic operation support. Probably better platforms to have called

out would be z/OS and i5/OS.

But now that you've asked the question, I'll have to go and find out. It'd be nice

to replace some C++.

Andrew

[brad clawsie]

haskell, mostly for illumination and frustration. i say frustration because haskell is not easy to learn and it will force you to think differently, and as a result gain valuable perspective. along the way you will find an educated, helpful community that has spent several years making haskell a useful choice for practical applications. haskell is particularly innovative with regards to concurrent and parallel programming.

[Dorival Pedroso]

Hi Peter,

The same has happened to me: I tend to use Go for every new work; even if there is a feeling that it would not be the best candidate (within my knowledge constraints: C/C++, Fortran, and Python) -- I find Go to be "simple and beautiful language with power".

I'm especially happier on this decision after seeing the great improved performance of the latest source -- listed here: https://groups.google.com/d/topic/golang-nuts/_8fN3tiqR4w/discussion

The occasions I use another language (C/C++/Fortran) are when dealing with high performance computing that needs multicore and/or parallel processing (OpenMPI and/or GPGPU) -- but multi-threading with Go seems a good 'way-to-Go' ;-)

Sometimes things are much easier with NumPy+SciPy+Matplotlib=PyLab and there is no point on using Go... So I wonder: is there scope for a GoLab project similar to PyLab? -- that'd be awesome!

Cheers.

Dorival

[Kyle Lemons]

On Wed, Jul 4, 2012 at 11:47 AM, Peter Kleiweg <pkle...@xs4all.nl> wrote:

I've been using Go for nearly a year now, and it has taken
central stage in most serious coding I do. Before, it was mainly
C and Python.

Lately, the only C programming I did was writing simple wrappers
for a few C and C++ libraries, so I can use them from Go. I
tried Swig, but I prefer to do this by hand.

I still use Python, but not without the feeling I might have
used Go as well, and getting things done faster and better.

And of course, I use several tools for small stuff (like a one
line Perl script for a simple task), and special purpose
languages like R or PostScript.

But for general purpose, serious coding, it seems like Go is
first choice, without competition.

This makes me wonder, am I missing something? Surely, you can't
have a single solution that works best in all circumstances?
Does using Go, and my fondness of this language, narrow my view
to the things Go allows me to do?

My question to you all is: if you are free to choose any
programming language, what are circumstances where you think Go
is not the best option?

Real-time: use C.

GUIs: I have no idea, but I have had occasion to slap together a javax.swing GUI frontend for my non-technical colleagues for a command-line tool.

Things that have existing libraries: whatever language you have to use for those libraries

Uh, that's probably about it. :)

 

What are languages worth learning besides Go, and why? (Aside
from external factors such as job opportunities and working on
existing code already written in other languages.) What are
languages that complete Go?

I've always labored under the belief that every language is worth learning, if only so that you appreciate your language of choice that much more (and for bragging rights).  In that vein, I strongly suggest being conversational in C, C++, Python and Java if you want to be able to stand your ground when defending the choice to use Go on a project.

 

What other languages do you think are as fun and useful to learn
as Go?

I think Go is the most productive, practical, and well-balanced language I have ever used.  To be fair, though, I also found Ruby (*not* on Rails) to be exceedingly enjoyable to write, and I also found abusing the Python data model to be endlessly amusing.  C is also a great language if you can stomach the care that is required to write it, and assembly to a greater or lesser degree: the performance you can get and the amount of control you have is incredible.

[Sebastien Binet]

Dorival,

Dorival Pedroso <dorival...@gmail.com> writes:

> The occasions I use another language (C/C++/Fortran) are when dealing with
> high performance computing that needs multicore and/or parallel processing
> (OpenMPI and/or GPGPU) -- but multi-threading with Go seems a good
> 'way-to-Go' ;-)
>
> Sometimes things are much easier with NumPy+SciPy+Matplotlib=PyLab and
> there is no point on using Go... So I wonder: is there scope for a GoLab
> project similar to PyLab? -- that'd be awesome!

+1, from my end.
that's why my first commit in the go stdlib was on exp/eval (to get a
nice interpreter) and my first project was go-gnuplot.

and I think you and I are not alone in that boat:
https://groups.google.com/forum/#!topic/golang-nuts/TL3vnDnwfiw/discussion

-s

[Peter Kleiweg]

On 5 jul, 01:52, Job van der Zwan <j.l.vanderz...@gmail.com> wrote:
> Peter, am I correct in recalling a post from a few months ago where you
> stated that you were just trying out Go, but were quite skeptical about it
> being the right language for you? :)

Perhaps you are confusing me with someone else. My memory is not that
good, but it seems unlikely to me I wrote it. And a quick search
through the archive shows me nothing of the kind.

[Job van der Zwan]

If you think it's unlikely that you wrote that, then that's probably the case. My memory isn't the best either, so confusing you with someone else is very possible (most likely someone who just posted before or after you in a certain topic).

[Peter Kleiweg]

On 4 jul, 20:59, Patrick Mylund Nielsen <patr...@patrickmylund.com>
wrote:

> The language I've enjoyed learning as much as Go, and one that was very
> eye-opening, is Haskell. I can definitely recommend learning it, or
> something similar like CL/Scheme/Clojure or OCaml. I'll use Haskell when it
> seems like the problem I'm facing could be solved more easily in a
> functional way, but, otherwise, Go has become my go-to language :)

I have some background in Prolog. I have studied Erlang for a while,
but never made any practical use of it. With Haskell, I haven't done
more than look at some descriptions and examples.

I think a functional language is nice if you need unification and
automatic backtracking like in Prolog, and Erlang has that. But beyond
that, I don't see the advantage. If I have a box and a ball, and I
want the ball in the box, I want to be able to say "put the ball in
the box". I don't want to write a mathematical description of what it
means for the ball to end up in the box. I think it just adds an extra
conceptual layer that you need to reason about. I don't believe in the
idea that a more mathematical program can be proven correct better
than a program written in an imperative programming language.

I would like to see examples of functional programming in practical
use, were it is clear that functional programming is a better tool
than imperative programming. And when it comes to using it myself, I
think Erlang would be my first choice.

[John Barham]

> I've heard that Eifel is fabulous

Considering the cheapest compiler costs $2799 it's certainly
fabulously expensive (http://www.eiffel.com/purchase/).

[Leo Jay]

For me, the PyQt is the best cross platform GUI solution.
I still cannot find a competitor in Go.
I hope I can use Qt in Go some day.

--
Best Regards,
Leo Jay

[Justin Israel]

That is my situations as well. I am trying to make Go my primary language but we just use PyQt so extremely heavily at my studio. I always end up just having to stick to python and then use Go when I can.

[Paulo Pinto]

On Jul 4, 9:19 pm, Joel Webber <joelgweb...@gmail.com> wrote:
> I've been a C[++] programmer the majority of my career, and had to switch
> mostly to Java and Javascript for the last 8 years or so (with occasional
> flashbacks to C++ for low-level and WebKit work). While I've always missed
> the simplicity of C, I don't miss dangling pointers and reference-counting
> bugs (or, god forbid, string [de]allocation bugs across various flavors of
> the win32/com/ole/god-knows-what runtimes)! So I was mostly convinced that
> Java was a net win (or even better, C#) -- even if I never particularly
> loved the language.
>
> A coworker finally convinced me to take a look at Go, and after a day or
> two I was convinced that almost every decision made in the language design
> was exactly what I wanted. Even the constraints it imposes are easy to
> understand, and it's usually fairly obvious why a given constraint exists
> and what you get out of accepting it. As I think someone said in the quotes
> file, "it's like a better C brought to you by the people that didn't bring
> you C++". I particularly love the fact that it produces a simple,
> statically linked binary, just like C, that starts in a few milliseconds.
> You know, what we used to call a "program", which is something you run
> directly on an "operating system". Makes me want to burn all the VMs to the
> ground :)
>

I share your feelings about VMs.

I started to think that it is a shame Java and C# compilers to native
code are
not that much used, to the point many developers don't seem to know
they exist.

Regardless of the my complains about Go's design, the offering of
native compilation
from day one is really great. For a old timer like me, it brings me
back to the days
when compilation to native code was the rule, and not some JIT thing.

Thankfully the trend seems to be changing, as it seems the C# AOT
compiler from
Singularity project might become an official compiler as well,

https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=6&jid=76831&jlang=en

--
Paulo

[David Roundy]

I like go, but find there are few "real" projects where I can use it.
For me, "real" projects consist of computational physics. Currently
I'm using C++ and haskell code to generate C++ code (computing
gradients analytically). In both cases, operator overloading is
extremely valuable, since it allows the code to look more like the
math, and go's strengths (concurrency and garbage collection) are
pretty close to useless. Perhaps go would allow me to parallelize
more efficiently, but I don't feel confident about that, and would
then be forced to either develop an MPI binding myself or restrict
myself to single-node operation.

If go had multi-dimensional slices, it might present a challenge to
C++, since that would make the code cleaner, although even then, the
lack of operator overloading (or at least the ability to add and
subtract numeric slices) would be a significant hindrance.

David

--
David Roundy

[Zippoxer]

No tool is good enough for all purposes. The mistake of C++ is trying to be so.

Go will never support operator overloading (I'm aware of the risk of saying such statement). Your best chance with Go and physics is a domain specific language for math (or more specific, for physics).

[kar]

I code in GO mainly (a tiny bit of C just to wrap external libraries), everything else is javascript either directly from browser or thorugh javascriptcore. My Go server apps been been serving thousands of request per day for around 5 months with no hiccup (only hot restart for updates).