61–70 of 127 posts
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…
Silly.
Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.
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,…
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.
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…
I do wish they had chosen a different name, but I realise it matters less and less.
Earlier quoted context omitted.
[[[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 u…
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)
Earlier quoted context omitted.
[[[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 u…
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.
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.
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 i…
Yes, there's some of this:
if f, err := io.Open("foo.txt"); err != nil {
return err
// use f
However, that's not really any more code than
try:
f = open("foo")
// use f
return e // or throw, or whatever
It's pretty awesome.
Earlier quoted context omitted.
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…
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 err…
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)
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.
Earlier quoted context omitted.
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,…
> 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 com…