Live data from Hacker News

Why I Program in Go

tech.t9i.in

151–160 of 171 posts

Re: Why I Program in Go

#151
post #135
post #64

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.

I'm not saying that minimal builds are silly, just that the idea of keeping compilers off systems as a security feature is.

Re: Why I Program in Go

#152
post #111

Earlier 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.

I'm sorry, but calling Dart a Java-clone is a ridiculous assertion. Care to back it up?

Re: Why I Program in Go

#153
post #150
post #135

Earlier 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?

Yes but they were only available to one user and that could only log in via the console server.

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

#154
post #39

Earlier 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

The 32-bit GC issue is an unfortunate shortcoming of the GC implementation, which will be resolved in Go 1.1 early this year. The issue was merely an artifact of dead simple conservative GC implementation.

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

#155
post #148

If 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.

Go's net/http package is concurrent behind the scenes; each request is handled in a separate goroutine. You just write your HTTP handlers in the obvious way and the concurrency is taken care of by the runtime.

http://golang.org/doc/articles/wiki/

Re: Why I Program in Go

#156

Earlier 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.

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)

Re: Why I Program in Go

#157
> Scalars (integers, characters, strings, floats, booleans), sequences (lists/arrays) and maps (key-value pairs) as built-ins are enough to support almost all data models.

There 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

#158

If 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

Added

Re: Why I Program in Go

#159
post #67

Earlier 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.…

Java has a keyword 'final' for immutable objects.

Re: Why I Program in Go

#160

Earlier 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)

"The ban caused Armstrong and others to leave Ericsson.[6] The implementation was open sourced at the end of the year (1998).[3] The ban at Ericsson was eventually lifted, and Armstrong was re-hired by Ericsson in 2004.[6]"

It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.

Post reply on HN