Earlier quoted context omitted.
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.
Why I Program in Go
151–160 of 171 posts
Re: Why I Program in Go
#152Earlier 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…
Go is far more innovative than Dart. Dart is, roughly, "We want to have a Java-clone in the browser". Go actually makes an effort at cleaning up C while adding a structural OO model and building in concurrency.
Re: Why I Program in Go
#153Earlier quoted context omitted.
Well back in the 90s we kept the machines lean more because disk space was fucking expensive.
Did they have /bin/sh or /bin/bash or /bin/csh?
Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the size of a full 42u rack).
I miss those days.
Re: Why I Program in Go
#154Earlier quoted context omitted.
> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements. It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
Really? I remember reading all kinds of problems when trying to run go on 32-bit machines, like: http://news.ycombinator.com/item?id=3805302
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
Re: Why I Program in Go
#155If anyone is interested in learning go, my site has a compiled list of tutorials and so on http://pineapple.io/resources/tagged/go-language?type=tutori...
I have been unable to find a good web server tutorial. Everything seems to be listen, process page, done, repeat. This doesn't seem to allow multiple connections at once, especially if the process page process takes a long time.
Re: Why I Program in Go
#156Earlier quoted context omitted.
> 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…
Immutability has worked out really well for a lot of real-world systems built with Erlang.
"Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson"
Not exactly a strong endorsement for Erlang.
[1] http://en.wikipedia.org/wiki/Erlang_(programming_language)
Re: Why I Program in Go
#157There is some wisdom in Larry Wall's decision to make scalars, lists, and maps the main data structures in the Perl programming language and to give them the sigils $, @, %. The considerable wealth of Perl libraries available on CPAN today demonstrates that you can support essentially all data models using these three data types.
Re: Why I Program in Go
#158If anyone is interested in learning go, my site has a compiled list of tutorials and so on http://pineapple.io/resources/tagged/go-language?type=tutori...
The recent five-part tutorial on Go that ran in Dr. Dobb's also has articles worth linking to: http://www.drdobbs.com/240008277
Re: Why I Program in Go
#159Earlier quoted context omitted.
>> * 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…
My point is that Go gives you the option of immutability. Not immutability or something in between. I frequently send messages using non reference types which incurs a copy but means that I don't have to worry about who owns this code. It's easy since Go has pointer and non pointer types. Java has reference types and you have to design the object to be immutable by hiding fields behind methods and using annotations.…
Re: Why I Program in Go
#160Earlier quoted context omitted.
Immutability has worked out really well for a lot of real-world systems built with Erlang.
The main (and close to only) user of Erlang was Ericsson, and here is what the Wikipedia has to say about it [1]: "Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson" Not exactly a strong endorsement for Erlang. [1] http://en.wikipedia.org/wiki/Erlang_(programming_language)
It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.