This is a nice example how to do low level programming while using a safe strong typed language most of the time.
Go and Assembly
31–40 of 127 posts
Re: Go and Assembly
#32You 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.
Re: Go and Assembly
#33And 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…
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.
Re: Go and Assembly
#34Earlier 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)
In what way does his mistake about Perl invalidate any of his other examples?
Re: Go and Assembly
#35Except 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.)
Re: Go and Assembly
#36[deleted]
Re: Go and Assembly
#37And 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…
just type go language, go programming
Re: Go and Assembly
#38That 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...
Re: Go and Assembly
#39Except 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, 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.
Re: Go and Assembly
#40This 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?