It feels like Go is the new Fortran.
Why I Program in Go
131–140 of 171 posts
Re: Why I Program in Go
#132Can anyone explain in less than ten words the most important reason to program in Go?
"Many of the best part of both C and Python"?
Re: Why I Program in Go
#133Java is perhaps the most depressing language I've ever programmed in.
I'd have to agree with him there.
Re: Why I Program in Go
#134Go nails code readability and documentation better than any other language I'm aware of. For example, look at the package documentation for Go's list data structure at http://golang.org/pkg/container/list/ . 5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, http://golang.…
> Go nails code [cut] documentation better than any other language I'm aware of. That's because you haven't seen PHP's documentation. Look at your Go's list example. It doesn't even show how to create a list and fill it with items. It doesn't have users' comments. It doesn't explain much about the data structure. Can it be a circular doubly link list, for instance? Is there a method to empty the list, or quickly inse…
"Sorry, but this documentation is shit."
Yes, they are short of useful examples but, then, so are the PHP docs. Worse than that I find most of the user comments on the PHP docs are noise: self-proclaimed PHP gurus trying to out-clever each other.
The Go Library docs have one major advantage: you can click on the supplied link to see the simple, understandable implementation.
Re: Why I Program in Go
#135Earlier quoted context omitted.
You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess. This is what systems administrators with grey beards thought in the 1990s…
Well back in the 90s we kept the machines lean more because disk space was fucking expensive.
Re: Why I Program in Go
#136Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
Just one point : > C++ doesn't have this [Tools for writing IDEs quickly] Well indeed it does, libclang does exactly that, and quite well. As a result, you have plugins for Vim, Sublime Text and others providing autocompletion and in editor compiltation and error reporting.
And it only took 25 years since the language was born for the those tools to become available!
In all seriousness, C++ is extremely difficult for automated tools to work with, including C++ compilers.
Re: Why I Program in Go
#137Earlier quoted context omitted.
> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages. This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think imm…
>> * I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.* I don't want to join into a language war, but I wanted to point out two things with this statement: 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this…
> 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years.
Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact that most of the concurrent code today runs on mutable structures shows that it can be done.
Re: Why I Program in Go
#138Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…
> Go error handling is not to be taken lightly
The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion.
Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions of lines of code, the software community is not going back to error codes.
Re: Why I Program in Go
#139Earlier quoted context omitted.
What is the "biggest" gain a language can have is a matter of taste. Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly. That you do not value those things as highly is not particularly profound. It doesn't mean that he is wrong to be excited about that, nor that he is excited about the wrong language, nor even that there is no reason for…
> Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly. Not really. Someone who values those things highly would have written the code as such, instead of relying on a utility to reformat the code.
Are you being purposefully obtuse? Do we really all just use and read our own code and not the code of others?
Having `gofmt` drastically increases the probability that any particular Go program has the same style/formatting that you're used to.
Re: Why I Program in Go
#140Earlier quoted context omitted.
> Yeah- that is great as long as you don't care about using 30x times more memory.... > Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... . There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).
Makes me wonder why people don't use Free Pascal more ... It shares many of Go's advantages described here (simple language, powerful libraries) and is frequently faster and uses less memory (8KB memory in 4 cases where Go uses 700-1200KB!) on the Benchmark Game programs. It's probably the C-like syntax that tips the scales every time ...
Nothing complicated -- Pascal has been out-of-fashion for many decades.