Go and Assembly | Hacker News Reader

Go and Assembly

doxsey.net

190 pointscdoxsey124 comments

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too).

I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful.

I don't know if any language can beat that list of tool chain benefits. Maybe I will give go a whirl.

I thought it would be a deal breaker for me, too. C/C++/C#/Python have been my standard languages... but after coding in it for a while, I love it. You never have to worry if someone downstream is going to throw an exception make your function exit before it gets to the end. That means you can write robust code without needing a ton of try/catch everywhere, or using statements (from C#) or whatever.

Yes, there's some of this:

if f, err := io.Open("foo.txt"); err != nil {

   return err

} else {

   // use f

}

However, that's not really any more code than

try:

    f = open("foo")

    // use f

except IOError as e:

    return e // or throw, or whatever

Plus Go uses multiple returns everywhere, so you don't have to worry about errors being confused with actual data returned.

It's pretty awesome.

Don't bother with the else. Just continue with your code outside a nested block since the if returns.

in this case, f is locally scoped to the if/else statement since it's assigned inside the if statement... Probably most of the time I would actually assign it outside the if statement and then check it/return and not have the rest of the code indented.

Go supports panic/recover which is very similar to exceptions. Instead of wrapping a try...catch block around something, you get to handle exceptions every time they are about to cause a function to be exited.

This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value.

tl;dr: Go has exceptions, they are just a little different (IMO for the better).

Panic and recover are non-idiomatic; using them the way you would exceptions in Python is (stylewise, I mean) a little like using setjmp and longjmp for flow control in a C progam.

In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.

The reality is that Go does not have exceptions the way Python does. If you're writing idiomatic Go, you're manually checking errors.

> Panic and recover are non-idiomatic;

Exactly (and probably for a reason)

> In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.

Well, there's no real way to recover after such an assert (the C stdlib is undefined when you catch the SIGABRT, the stack is not guaranteed to be big enough to do anything, most I/O is not guaranteed to work, etc. -- really, very few uses for catching a SIGABRT). There is a way in Go, even if it is far less capable than your average "except .." clause in C++.

> The reality is that Go does not have exceptions the way Python does.

True. Some of us (e.g. me) think that's a big advantage. (I'm not implying you disagree - I don't know what your opinion is)

I'm not a fan of the lack of exceptions in Go, but it's not a dealbreaker for me. I feel like Go code is very cluttered and fussy. I don't love the language as a language. But as a tool for getting systems programming problems solved, it is pretty amazing, and I love working with it.

I think the real value of panic/recover over try/catch is the vastly improved idiomatic usage. Only to be used in exceptional cases, and never to cross package boundaries.

I just find that so much more pleasant.

Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.

Although, another post above says it's not idiomatic, so I guess working with go means accepting the lack of an exception mechanism.

No, jlgreco had it exactly right.

I think the only thing missing is a REPL as part of the tool chain. ipython and scala shell are so useful, especially when you're learning or just testing things out.

I tend to always have a play.golang.org tab open but agree, an in-editor repl would be nice.

Even though I'm using GoSublime I haven't really dug into its plethora of feature, it might just have a repl in there...

Agreed. The way I tend to use the repl in clojure is just to code up a script in vim and then %Eval the whole thing. Editor plugins for Go could compile-and-run, and know stuff like the working directory and the gopath, which could get you a bit closer without having to build a real REPL.

> Editor plugins for Go could compile-and-run

Yep, rolled my own here: http://github.com/metaleap/go-buildrun -- I use it with GoSublime on Ctrl+B (which I strongly suspect must have some repl-like feature anyway by now, but not sure) -- but works in any editor that lets you hook a key binding to an executable and pass it the current .go file's path.

Would something like this qualify as a REPL, or is it not quite so? https://github.com/shurcooL/Conception/tree/simple-live-edit...

I think the defer keyword more than makes up for the lack of exceptions. And you can panic, you are just not supposed to let it get out of your package; catch it and return the error.

Here's how to do inline assembler in D:

    int *_memset32(int *p, int value, size_t count) {
      asm {
        mov     EDI,p           ;
        mov     EAX,value       ;
        mov     ECX,count       ;
        mov     EDX,EDI         ;
        rep                     ;
        stosd                   ;
        mov     EAX,EDX         ;
      }
    }

The compiler adds the function prolog/epilog for you, as well as any save/restore for used registers.

Well, this article wasn't about _inline_ assembler. Regardless, inline forms have a number of problems, the biggest one being supporting multiple platforms w/o a bunch of preprocessor noise. That doesn't stop it from being useful for certain languages but it matters less and less given how compilers behave these days.

There is a steady drift away from using assembler even in languages that support it. Intrinsics, for example, often work better. But there are a few things where it really comes in handy.

I wonder if we'll see more user-side emulation of intrinsics given new __attribute__ flags compilers are implementing. It certainly is easier to reason about.

Go doesn't have anything like that yet but I wouldn't be surprised if an experimental implementation is done by one of the alternate compilers being worked on.

Great write-up. As I'm perusing the math/somefeature_arm.s and math/somefeature_amd64.s files in Go's math package, I can't help notice most of them look like this:

http://golang.org/src/pkg/math/remainder_arm.s

That is, very short code that just looks like a function call to me, the complete asm noob. What is it, are all these maths functions implemented in hardware by amd64 and arm architectures? Or is this "asm code" just reverting to calling the Go implementation of the particular function (aka the not really that "optimized")?

In this case there is a 386 implementation:

http://golang.org/src/pkg/math/remainder_386.s

The other two call the go version:

http://golang.org/src/pkg/math/remainder.go

Yeah that was kinda my point ;)) so basically 386 users get some highly specialized hand-tuned asm optimization whereas arm and amd64 merely get a commoner's gc treatment -- or am I missing something? ;)

Several things:

- The fprem1 instruction is actually a long microcode sequence and is quite slow; 26-50 cycles on SNB according to Agner Fog. Several iterations of that loop are necessary for a complete reduction of some operands.

- There is no analogous instruction on arm (or really, any platform that isn't x86), anyway.

- If you're using the floating-point remainder operation in a performance-sensitive context, You're Doing It Wrong. Programmers have gotten so used to this that there is little value in optimizing remainder; it is rarely used in situations where the optimization would matter.

This was just a random example I picked, I'm not using that function currently. But let's just say abs(), sin(), cos()...

Yep. I would guess the compiler produced sufficiently optimized code for the other platforms.

Very little of the Go standard library is written in anything but Go.

And herein lies the problem with Go. Seriously, try searching for articles about Go on HN. People always say "well the name isn't a problem, because you just search for it with "golang" instead!" but no one writes golang unless they're pointing out how to search for it. If I was trying to get back to this article a month from now and I searched for "go", would I find it? Probably not, unless I remembered the article title contained the word "assembly", but then I'm matching a search to assembly and not Go.

The name is a problem. And if the name is not a problem, then the community is a problem.

[[[EDIT: wrote this little rant before realizing you specifically refer to HN search rather than general search. Yeah why would I ever search on a specific Go topic exclusively on HN, instead of web-searching?]]]

Every time a Go article comes up, the "name searchability" discussion comes up. Go's been around for some 4-5 years now, can we all come to terms with its name?

Somehow whenever brainfuck-lang threads show up, this issue is never raised, but surely might exist just the same? What about Perl (a common word), or Basic (even more basic), heck "C" (a freakin' letter). Is that so much better for searchability? Rust -- a common word. D -- a freakin' letter. Miranda -- a language but also the name of 100s of townships, an IM client etc etc.

Go is not the first language to have this "problem", and in fair daily practice it never ever is a problem. Because you never search for Go, you search for "Go channels" or "Go image processing" or "Go GTK binding" or "Go compiler error X" etc. etc. Like you would for all these other fine examples of oddly named languages. And somehow, Google is semantically smart enough to present a few decent matches among the first 10, even with all your personalization & tracking cookies etc. etc. disabled.

So... problem? Herin lies the problem with Go? Seriously... it's just not a big freaking deal getting in the way of getting stuff done. Promised.

Your examples make no real sense, other than "Basic". Perl is absolutely NOT a common word. Pearl is common, but Perl is the programming language (only)

In fact I have heard from Larry Wall that one of the things he liked about the name Perl was that he could easily grep a Usenet feed for the term. That let him keep track of every mention of Perl back in the early days.

I think it is too bad that in the days of Google and the web there is no easy way to keep track of all new references to an uncommon term like that.

zOMG you're right re pearl -- I'm kinda shocked at myself right now. In my defense, in German it's "Perle" so not that different...

OK scratch the Perl example. Still standing by my point: it's a "problem" shared by many languages and it's not a problem in the first place.

I found a list of English words by frequecy of use in Project Gutenberg texts.

"Basic" is around #9,500.

"Rust" is ~#10,950

"Java" doesn't appear at all (List goes out to 40,000) (Admittedly, somewhat biased by the dated-ness of the material, but it's still not a common one.)

Go is #106, and modern lists based on contemporary sources place it in the top 50 most used English words.

http://norvig.com/mayzner.html

(1MB) word count list: http://norvig.com/google-books-common-words.txt

Go: 187, Basic: 759, Java: 7136, Rust: 13110

With relative frequencies 320M:103M:8.9M:3.6M ~ 100:30:3:1

This is very biased, because there's a whole junkload of intro-to-java textbooks in Google books.

https://www.google.com/search?q=java&btnG=Search+Books&#...

Actually, before the modern programming languages (say pre-1990 for simplicity), "perl" was just as common a word as "java" (though falling), and at one point "miranda" was substantially more so. "pearl" is only around 100x more common than "perl". "basic" is certainly FAR more common than any of the above, including "pearl".

http://books.google.com/ngrams/graph?content=java%2Cperl%2Cm...

I'll assume you've never knitted.

In what way does his mistake about Perl invalidate any of his other examples?

[knitting perl]

"purl", surely?

Java, Python, Ruby, Lua, Haskell.

All names which the programming language is one of the last things a search engine would normally associate, but by sheer number of hits you end up finding stuff. When they were invented these names weren't good either.

The discussion about Go's name is indeed useless.

Every single one of those is used way less often and in way fewer contexts than "go."

If I hear about this cool new language called Ruby and search for "Ruby Sieve of Eratosthenes," it is highly unlikely there's an article about implementing the Sieve of Eratosthenes in another language that just happens to contain the word "ruby." Conversely, the word "go" is depressingly likely to appear in articles relevant to your other search terms but unrelated to Go.

This has become less of a problem as Go has gained popularity, but in my experience it was a bigger problem for Go than it is for most languages. I search for a lot of obscure language crap out of curiosity, and I have never found an obscure language that is as hard to Google for as Go was a year ago. I know the articles existed, because I eventually found them, but dang was it hard to coax the info out of search engines.

I just searched "Ruby Sieve of Eratosthenes" and "go Sieve of Eratosthenes". The language ruby was the focus of the first four results, and after that some were ruby-specific and some were just Sieve with a mention of ruby somewhere.

Exactly the same applied for Go. The first four were Go-specific, and the remainder were a mix of Go-specific and pages about the Sieve with "go" somewhere on the page.

Also, as others have said, one immediately comes across references to golang everywhere.

I feel like you must have stopped reading my comment before the last paragraph, where I point out Google has learned to deal with this as Go has gained popularity and now it's not so much of a problem in practice.

There's a crucial difference. Those are longer words. Many search engines either ignore, or outright throw an error on, search terms shorter than 3/4 characters.

I think the most damning part is that 'go' is a common verb.

"Many search engines"?

How many search engines do you use? And which of them ignore or error on 2-letter words?

I just tried this on the only four search engines I can even think of that seemed like they MIGHT matter: google, bing, ddg, and stackoverflow's site-specific. All four obviously respected the two-letter word "go" (although for my searches only Google and SO returned results I found useful).

Most message board software, for a site. Search engine doesn't just mean web search engine.

First of all, the best way to site-search is to use Google. Seriously, why are you hurting yourself?

Second of all, I can't understand the situation where this would come up. Obviously in normal circumstances it doesn't even come up.

* You wanna search all forums at once? Use Google (or DDG, or the shitty one).

* There's a Go-specific forum? So obviously you don't need to specify Go in the search.

* The forum isn't about Go? Then why are you searching there?

So for your complaint to make sense, you need to have a particular forum you want to limit your searches to, AND you don't want to use Google with site:stupidforum.com, AND the forum covers multiple programming languages, AND the forum doesn't have a tagging system to tag go-lang posts (like basically every programming forum does), AND it has this problem I've never heard of where it rejects 2-letter words?

I'm really trying to avoid just saying "bullshit", but I think you're bullshitting us. Name one such forum.

Again, as I asked in the grandparent comment, name one search engine where you, or anyone you know personally, has had this problem.

I am not surprised that shitty message board search functionality was not considered when naming the language (How do you even search for "C" with such a system?)

Well, I'm glad to hear you don't have any substantial complaints about the language.

What exactly are you searching for? Perhaps I can help you... http://lmgtfy.com/?q=site%3Anews.ycombinator.com+go

Did you even try?

(For those that have experience using Google, the search results are: http://goo.gl/fqNiC )

Would you say the HN search is a "good one"? And who would search for Go just by typing go in a search bar? Would you really do that on Google? I don't even do that for less common words, let alone one like "go". I usually use 3-4 words for my queries, maybe more. Because I have a pretty good idea of what I'm looking for and I don't want to waste time looking into pages of search results to find the relevant article, because I only searched for one word.

>Seriously, try searching for articles about Go on HN.

Well, either "site:news.ycombinator.com go" or " "site:news.ycombinator.com golang" work very well for me, getting tons of results. What exactly was the problem again?

If you don't find as many articles on Go as you would like it's because there just aren't that many. It's a relatively new language, without much of a user base yet. Heck, it only has 3-4 books out on it.

I didn't even have to use that Google feature. "go hacker news" works great.

C has a bit of a problem with search as well. There is C, C++ Obj-C and C# which all tend to come up in searches. And that is excluding things that can be avoided with additional key words in searches, such as C the default drive on Windows and C as in City Group.

Yes, the name can be difficult to search for. Same with C. Nothing is going to be done about it so most of us have moved on.

Also, it is pretty easy to find this story by searching for 'go' in the HN search box. You can further reduce results by selecting 'Stories' and search by date.

So in practice it is not a big deal.

"C" might be even shorter, but I think it's much less frequent in the english language (as a word) than the word "go".

C and R used to be hard to search for, but these days Google search does brilliantly given a bit of context. If Go is hard to search for now, be sure it will get better.

I do wish they had chosen a different name, but I realise it matters less and less.

Honestly R is still a pain in the ass to search for, much more-so than Go currently is. This might be a fluke of my personalized google search results though.

I'd imagine Google recognizes you're a programmer and modifies your results for "go" accordingly

It doesn't.

Well, considering how hard I try not to be tracked by Google, probably it does for someone else.

According to golang FAQ, the origin of the name is that, “Ogle” would be a good name for a Go debugger. [1]

I just came up the idea: why didn't they name the language "Goo", and leave "Gle" to the debugger? It would be more common for people to refer to the language itself than to its debugger.

[1] http://golang.org/doc/faq#What_is_the_origin_of_the_name

Well, Go is a dynamic name, a verb, it evokes travel, motion, activity. Goo is a very static name evoking "slimy", "disgusting", and also, "useless for building things". I don't think Goo is a very name for a computer language.

Then again... http://en.wikipedia.org/wiki/Goo_%28programming_language%29 , although the homepage http://people.csail.mit.edu/jrb/goo/ suggests that that sort of thinking is not really in Goo's pedigree... even for 2003 that's not a pretty page.

I think you should consider the possibility that the FAQ is joking.

Also, if you're suggesting "gle" as a debugger name, you're missing the joke. "ogle" is a verb meaning, approximately, "to look at", so it's a good name for a debugger. "gle" is not.

(Except that "ogle" is not actually a good name for a corporate-sponsored debugger, because "ogle" has sexual connotations. Which is why you should assume that this is a joke.)

I didn't know that! Thanks :-)

The name "Go" is a problem, but the name "C" isn't?

Silly.

Who said the name "C" isn't a problem?

I do indeed have the impression that anyone who would bring up Golang's name as a serious flaw would also believe that C's name has held it back as well.

Well, you're a bit mistaken. There are a couple of reasons why this isn't the case:

1. C was already pretty much the programming language by the time the Web took off, so it had an inherent advantage in Googlability due to its popularity.

2. The letter C does not tend to be used by itself as often or as widely as the word "go," so even if C hadn't already had an unfair advantage, it would have less of a problem just on this basis. The odds that an arbitrary programming article unrelated to C will have "C" scattered about are not all that great. The odds that an arbitrary programming article unrelated to Go will use the word "go" are actually pretty decent. Put another way, "Go" is a more common word than "C," so it generates more noise.

I don't find this issue to be all that problematic anymore since the search engines seem to have learned that "go" in conjunction with programming terms indicates an interest in Go-centric material, but I did find it vexing when Go was younger and I was first trying to learn it.

just type go language, go programming

So what does that middle dot actually do before the function names? It doesn't seem to be mentioned in the linked documentation of the Plan 9 assembler, and if I have to use a character that I can't easily type with my keyboard, I'd like to at least know what it actually does. :)

Also, doesn't doing this limit your code to using gc toolchain (since the generic Go function has to get called from the arch-specific asm code which uses that Plan 9 dialect)? Does this mean that the Go standard library can't be compiled with gccgo for example?

> So what does that middle dot actually do before the function names?

http://stackoverflow.com/a/13490787

http://article.gmane.org/gmane.comp.lang.go.general/78328

Does Go only support that crazy Plan 9 (amd64) assembler syntax that nobody uses anywhere?

Well, since two of the original three developers (Pike and Thompson) were part of the Plan 9 team, it makes perfect sense that they based the compilers on the Plan 9 ones.

I see recent commits in Go's mercurial history to fix bugs on Plan 9. Is anyone at Google actually using Plan 9 to develop Go? Or is building for Plan 9 just a sanity test for maintaining cross platform code?

Wikipedia says the last "stable" release of Plan 9 was in 2002, but there seem to be a number of recent forks.

Plan 9 is on a rolling release since 2002.

There are people that don't work at Google who contribute to Go. It's an open source project.

This reminds me of a topic that had come up earlier last year: Intermitten problems with 32bit programs in go. If I remember correctly programs would crash intermittently if the initial 512MB memory block requested wasn't contiguous. Does anyone know if this still is the case? Is the solution still to always just use 64bit?

As I'm only on 64b right now, I can't quite remember whether that was fixed by 1.0.3 or will be in 1.1 -- but I'm pretty pretty sure one of these is the case.

That is pretty neat. I'm glad he mentioned that the Go compiler will not inline functions written in assembly, but it will inline small Go functions.

Yeah but the list of restrictions preventing inlining is pretty exhaustive...

This is true currently but both the inlining and the garbage collector have improved tremendously over the past year and should continue to get better.

I do wish Go supported an explicit inline modifier that worked like haxe's though (unlike the C/C++ one which is more of a suggestion).

Most C dialects (for example, GCC and Clang) provide some form of explicit inline qualifier that forces inlining, for example "attribute((always_inline))".

This assembler is awful. I thought that AT&T had a monopoly on ghastly assembly language syntax -- but this article causes me to question that assumption:

  MOVL BX,autotmp_0000+-4(SP)    ; from the article -- terrible!
  MOV EBX,[ESP+autotmp_0000-4]   ; Intel -- comprehensible!

This assembler has an imaginary register called FP.

WTF is up with the center dot?

A programming language should not require Unicode to write -- especially assembly language!

I don't know what's worse: That this assembler exists, or that a project chose to use it after better alternatives had been created!

It's amusing that the first line is considered "terrible" but the latter is "comprehensible". For someone versed in modern languages they both look like gibberish.

Here's an explanation suitable for someone only familiar with high-level languages:

MOV x,y translates to the assignment operator "x = y" in a high level language [1].

Your program only has access to one giant array called "memory" [2] [3]. So MOV EAX,EBX means "EAX = EBX" in high-level terms; MOV EAX,[EBX] means "EAX = memory[EBX]" in high-level terms ("memory[EBX]" has the same meaning here as in C-family languages like C, Java, Javascript and Python). This choice of operator notation is intuitive, because it's very similar with the use of brackets in other popular languages.

The insane syntax uses parentheses instead of brackets. Which is confusing, since it's not related to the standard meaning of parentheses, grouping for order of operations or function call. So you would say "MOV EAX,(EBX)" in weird-syntax land.

But the insanity doesn't end there.

In the sane Intel syntax, if you want to load the value at memory location 148 + -4 + ESP into EBX, you can probably figure out how you would say it:

  MOV EBX,[148 + -4 + ESP]

The C/Java/JavaScript/Python translation is:

  EBX = memory[148 + -4 + ESP]

In weird-land, the syntax for this operation is:

  MOVL BX,148 + -4 (SP)

To me, it looks like this instruction says:

  Let t = 148
  Let u = The contents of memory pointed to by SP
  Let v = -4*u
  Let BX = t+v

Clearly, there are only two possible explanations for this: The person who came up with this syntax was drunk at the time, or the person who came up with this syntax was high at the time.

[1] In a HLL, "x = y" allows arbitrarily long expressions for x and y, but in assembly language only a few different forms of x and y are allowed. In a high-level language, in the expression "x = y", x needs to be an lvalue, while y can be a more general rvalue. "a = 5+6" is legal; "5+6 = a" is not. Both the left- and right-hand side can be arbitrarily long and complicated, for example the LHS could be "a.b.c.d.e.f.g.h" and the RHS could be "m+n+o+p+q+r+s+t", assuming the appropriate variables exist and have the appropriate types.

[2] Unless you use multiple segments. But you generally don't do that.

[3] Or paging. But you usually let the OS take care of that.

How does it require unicode?

The article talks about making a label whose name begins with a middle dot.

Why the \cdot? Is Unicode required to parse assembly?

"Source code is Unicode text encoded in UTF-8."

http://golang.org/ref/spec#Source_code_representation

Historical reason, TL;DR edition: Plan 9 based compilers, because Ken Thompson.

EDIT: see also mseepgood's response: http://news.ycombinator.com/item?id=5185334

This is a nice example how to do low level programming while using a safe strong typed language most of the time.

I only have 2 problems with Go.

1. It does have its own package manager but good luck actually finding packages. golang.org's list is out of date and so is every other resource.

This is a serious problem IMO.

2. The third party web libs are pretty poor. I'm a big fan of Express for Node and prefer just a little bit of goodies ontop of something minimal.

A lot of people like Sinatra/Flask so I'm not the only one who likes this. There's nothing like this in Go.

We have the bits and pieces to make it but no one has stepped up. Right now developing anything for the web with Go is just too annoying, you have to create so many things that literally every other language has had solved for years.

If both of these problems were solved I would insta switch to Go for everything and never look back. It's just so pleasant to program in for all the points you mentioned + more.

Try http://godoc.org/

Because Go uses URLs for package names its easy to build tools like godoc.org that automatically aggregate packages from the web.

It's a good start but it needs many more features to be considered usable. For example, I just did a search for "redis" and about 30 libs came up. Half of them don't even have a description.

How can I know which one to pick at a glance? Asking me to evaluate and profile 30 different libs for just a single task is unreasonable.

Also this page isn't even on Google's first page for when you search for something. I didn't even know it existed until you mentioned it.

Having too many possible packages to use is a nicer problem to have than having too few.

godoc.org is an interesting service because its package list is produced as a by-product of people using it to read package documentation.

How do you handle that with any other language? There is no shortage of redis libs for any language.

With Node I would use a combination of npm's site which is their package manager which ranks libs and has a wealth of info for each package and github.

When you publish an npm module it gets put on their site automatically, then there's a lot of javascript scraping sites that watch npm's site. Before you know it your module has a decent amount of coverage which in return makes it much easier to find as someone who is searching for modules.

I also never had a problem finding a good lib in Node because there's a few stand out Node devs who are insanely productive and produce extremely high quality libs on a regular basis.

With Go it feels like there's 3 or 4 lib searching sites but all of them are really flawed. Then on top of that Go code is hosted on a bunch of different sites.

Top Google results are also not very good. In that Redis search example I searched for "golang redis lib" and the highest rank result was for some lib with almost no traction and had a questionable API.

If we look at CPAN http://search.cpan.org/search?query=redis&mode=all , there are a few things right in the search results. We have version numbers, release dates, and a review score. All of those give you a chance at finding a half decent library. The first result was updated a week or 2 ago and has 4 significant digits in the version number. None of it's a guarantee but it's a place to get started.

It doesn't seem to be a place to get started for Go though. I just did a search for "golang redis" and it showed me a single perl redis lib?

I like the idea of the reviews and ratings though. Normally I would put almost no value in a rating system but we need to somehow separate the good from the bad without having to dive in and look at and profile code from 20 diff libs on a daily basis.

CPAN is the repository for Perl modules, not Go

The review score thing is nice, is there anything like that in packaging systems for other languages?

Usually I just check the commit activity on github if I want to see which Go libraries are actively developed.

This font renders odd in IceWeasel 10.0.12 , all occurrences of the letter 'e' have their left side 'cut off' so they stand out and are very difficult to read.

Chromium Version 22.0.1229.94 Debian 7.0 (161065) works fine.

Same on Mozilla's official Firefox 19 (beta channel). Raising the font size (Ctrl +) makes the issue go away.

Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.

Having used both a bit (Haskell substantially, still fiddling with Go), there's no "might" about it. But then, "Go compiles quickly" was an explicit design goal from day one. "GHC compiles quickly" is certainly much further down on the list of GHC design goals.

Otherwise, Go & Haskell are very different languages. In the grand CLispScript landscape, Go is sort of close to Haskell because of the interface/typeclass similarity, but pushed apart by the fact that Go's strong type system has some serious weak points in it by Haskell standards, for instance, there's no equivalent to a TChan a -> TChan a function as there is no way to have a function that is ignorant of "a" but can pass it through as the same type. Go forces it to collapse to interface{}, which is roughly equivalent to Data.Dynamic in Haskell. (If you want to search for it, Go calls it's equivalent to Data.Dynamic.fromDyn a "type assertion". There's two ways to use it, one that is the rough equivalent of fromDyn in that it returns whether the conversion worked and maybe the converted value, and one mode in which it does the Data.Maybe.fromJust for you, complete with violent crashing behavior if you're wrong.)

Wait, even "Go comes with a complete set of documentation available from the command line". I use hoogle from the command line, is there anything else for Haskell?

Hoogle type search is great: Give a type, get back names implementing that type or a generalization of it.

There's the haddock auto-generated documentation from cabal (if you enable it). Not sure if that qualifies for "available from the command line".

> all of his bullets apply to GHC Haskell too

No chance. Using the `go` tool to install packages is at least an order of magnitude less annoying than using `cabal`.

When did you last use `cabal`?

Cabal works much better now, and most of the problems were due to over-conservative version ranges combined with an over-eager reinstallation policy that overwrote packages in a breaking way. That was fixed about 6 months ago, IIRC.

A few weeks ago.

And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools.

Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.

Well, how can it infer the dependency on particular versions? Or on particular implementations of some interface you're using?

It doesn't. Hence:

> Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.

If you need to stick to a particular version of a software package, the common workflow involves using existing tools. (i.e., fork.)

I write haskell code all day. I spend my day writing it at work (with occasional HN breaks obviously) and then I go home and write personal projects in it. I advocate haskell on a semi-regular basis. I certainly fall on the pro-haskell side of things. But GHC absolutely does not meet all those bullet points.

Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies.

>Go comes with a complete set of documentation available from the command line

GHC does not come with command line docs.

>All Go code is statically compiled so deployment is trivial

GHC links in C libs dynamically, and as far as I can figure there is no way to get static linking working, so I have to have all the same C libs installed on my production servers as my build server. With go you can just upload your binary to a bare bones server and it works.

>but it also has a tool to clean up code: gofmt

GHC has nothing like this.

>And there's also go fix which can automatically convert Go code designed for earlier versions to newer versions

Or this.

Haskell is a great language, but it does not match go's toolchain.

> Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies

I simply did not play with Go to know the compilation speeds. I believe you that it is a massive difference, and it is indeed a major Go advantage.

> GHC does not come with command line docs.

The haddocks are available from the command line. So I don't know what this means. Hoogle is available from the command line.

> GHC links in C libs dynamically

Ah, I see. Did you try -optl-static? I haven't, but it might work.

> GHC has nothing like this.

There are tools to format Haskell code by certain conventions on hackage.

This is a complete aside, but what are the good tools for formatting Haskell code? I've been using stylish-haskell, but it's somewhat limited and barfs on certain Unicode identifiers I like to use. (I should probably file a bug report for that...)

Don't know anything better than stylish-haskell, but AFAIK it fits the bullet point completely.

>Hoogle is available from the command line.

Hoogle is roughly the equivalent. It doesn't come with ghc though, and the rather lengthy dependency list has caused problems getting it installed before. Is there a command line only version that doesn't need all the web stuff?

>Did you try -optl-static?

Yeah, no such luck. It turns out go can't do this either though, so that one shouldn't have been on the list in the first place.

>There are tools to format Haskell code by certain conventions on hackage.

The "being included with the compiler" aspect is pretty big here. People are much more likely to format their code if they already have the tool to do it. I'm not sure what you mean by tools available on hackage though. Stylish-haskell is about it, and all it does is align and sort imports/pragmas. Gofmt can basically rewrite go code however you want it to. Sort of like if hlint were built in to stylish haskell and did the replacements instead of suggesting them.

Actually if you import "net" go links to libc.so and some others.

I believe "net" does so for native dns lookups. You can disable that by building go with 'CGO_ENABLED=0', if desired.

That is correct. It uses libc for resolving names because systems might be configured to use NIS or LDAP before DNS. With cgo disabled it defaults to using its own DNS resolver and resolv.conf.

Ah, if the original bulletpoints for go are wrong then ghc may be more comparable than I figured. Can you statically link go binaries? As in, if I am using a go postgresql binding, can I build a binary with libpq (the postgresql C library) linked in statically, so it can be deployed on servers with no postgresql libraries installed?

From what I understand cgo doesn't currently support static linking like this.

You can always search "go programming", and the search engine should give you the results of go that occur in the context of programming, which should usually pertain to the go programming language.

Go also offers a set of features in the build system that make it obvious and intuitive to write assembly for different targets, all without having to muck with makefiles or macros.

http://golang.org/pkg/go/build/

Reply on news.ycombinator.com