Impressions of Go

http://blog.bensigelman.org/post/56158760736/golang-impressions

by icey • 13 years ago

187 268 13 years ago

blog.bensigelman.org

rwmj4• 13 years ago

I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them. More here:

https://rwmj.wordpress.com/2013/07/03/golang-bindings-for-li...

There's still room out there for the C replacement language. Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.

swdunlop• 13 years ago

Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken".)

Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.

rwmj4• 13 years ago

Well you can't call 'var' type inference (Edit ':=' .. it's still laughable compared to real type inference).

But I'll explain the GOROOT stuff in a bit more detail ...

Basically the way it's set up prevents golang modules from being packaged up for Linux distros. There are two main problems. Firstly the 'go' utility tries to recompile installed modules, which isn't going to work as those modules are in files and directories owned by root and 'go' is not running as root. By very carefully setting up timestamps it's usually possible to avoid this, but it's fragile.

Secondly if you do install a golang package, you can't compile an alternative copy in GOPATH, because the one in the (root-owned) GOROOT overrides it. Which is dumb and backwards.

harrytuttle• 13 years ago

Perhaps you don't "get" Go?

burntsushi8• 13 years ago

No type inference. Because obviously it’s 2013 and I want to write types everywhere.

The `:=` does a fair bit for the programmer in cutting back on writing types. For me, the most needed place for type inference would be for writing anonymous closures (like what Rust has). In most other places, I am quite content with writing the types, particularly at the top level.

Like what’s the point of all the odd rules around := vs =

The former is short-hand for variable declaration with assignment and type deduction, while the latter is just regular assignment. The primary benefit here is type deduction, which partially relieves the lack of type inference.

and what types you can and can’t assign and pass to functions

Huh?

And why do you have to declare imports, when the compiler could work them out for you (it’ll even moan if you import something which is not used!)

The compiler absolutely cannot work them out for you. If you have a package `github.com/PeepA/wat` and a package `github.com/PeepB/wat`, how will the Go compiler know which `wat` package to import?

The Go compiler merely moans if an import (or its alias) hasn't been used in the source file that it was imported in. I like this feature, even if it is a mild bother while debugging.

Hello, world is about 8 lines of code. Camel case! Java rang, wants its boilerplate back.

It's two lines. [1]

No breakthrough on error handling.

Breakthrough? I'm not sure what you were expecting, but I think the error handling is pretty sane and at least far better than error handling conventions established in C. It could be adjusted if sum types were added to the language, but that has its own trade offs.

If you desperately want exception-style error handling, then you can use panic/defer/recover, but it's frowned upon to overuse it.

The whole design of GOROOT/GOPATH is completely broken. It’s actually worse than Java’s broken CLASSPATH crap which is some kind of achievement, I guess.

I have the exact opposite opinion. Did you know that you probably shouldn't be setting `GOROOT`? [2] After Go is installed, you just need to set `GOPATH` and add `$GOPATH/bin` to your `PATH`. That's it.

It’s not even enforced error checking, so bad programmers will still be able to write bad code.

That is true, but Go's compiler forces you to address errors returned by functions that also return another value. You either need to explicitly ignore it or use the variable the error is stored in. (Lest you get an "unused variable" compiler error.) This doesn't cover all cases---like completely ignoring the return value(s) of a function---but don't throw the baby out with the bath water!

[1] http://play.golang.org/p/ihEoJ0yL9I

[2] http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroo...

mratzloff4• 13 years ago

Nice response. I would add

It’s not even enforced error checking, so bad programmers will still be able to write bad code.

Bad programmers will always be able to write bad code. You can't structure a programming language around preventing bad code without completely hamstringing the language.

masklinn8• 13 years ago

That is true, but Go's compiler forces you to address errors returned by functions that also return another value.

Barely and badly: you can ignore the error and it's by far the simplest course of action. Contrary to Haskell where it is easier to propagate it, or Erlang where it is just as easy to turn the error into a fault if you don't want to handle it.

don't throw the baby out with the bath water!

There is no baby in that bath water.

stcredzero12• 13 years ago

The whole design of GOROOT/GOPATH is completely broken.

I too thought this, until I took a couple of minutes to actually understand how it's supposed to be used. It's a very opinionated setup, but it seems well thought out.

acuozzo2• 13 years ago

Go was neither designed to replace nor compete with existing functional languages.

Even if it were demonstrably true that functional programming languages are a "better" (leaving this loosely-defined for now) choice than Go in 100% of the circumstances in which one would choose to use Go, your argument still wouldn't hold water, as it neglects other important characteristics of a programming language that are neither quantifiable nor useful in the context of comparing programming languages, such as perceived simplicity and the ability to hold the entire programming language in one's head.

What's the value in denouncing a programming language because it isn't designed with your favorite programming paradigm in mind? That's just dick.

Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do?

Really? Really?

rwmj4• 13 years ago

I didn't say Go was designed to replace or complete with functional languages. I said it would be good if Go's designers understood functional languages, but whatever their history or how internet-famous they are, they don't.

asdasf7• 13 years ago

Also, are you really going to call-out Rob Pike and Russ Cox on whether or not they truly understand Functional Programming like you do?

Appeal to authority really only works if the people you mention are authorities. On what basis would any reasonable person conclude that either of the people you mentioned are authorities on functional programming? Have either of them even been willing to respond to the constantly referenced parametric polymorphism paper from the 1970s yet?

Peaker9• 13 years ago

Do Rob Pike or Russ Cox know any functional languages?

I am not in either's fan club, and I find it easy to believe that they indeed do not understand functional languages.

RogerL2• 13 years ago

I kind of think Rob Pike knows about functional programming.

Go was written at Google to solve very specific problems Google had. Looming large was the need for a C family language that implemented concurrency, fast compiles, and so on. The C family requirement is quite simple: most google engineers are young and don't know functional programming, have experience with Google's existing C/C++ code base, and they will be using Go to replace and extend existing systems already in C/C++. A new functional paradigm, nice as it is, would just get in their way. I'm not enamored by many features of the language, but I'm really hard pressed to say that those features do not solve Google's problems.

mseepgood4• 13 years ago

The first Go program was a LISP S-expression parser: http://blog.golang.org/first-go-program

Stephen Wolfram writes about the birth of Mathematica: "Macsyma was written in LISP, and lots of people said LISP was the only possibility. But a young physics graduate student named Rob Pike convinced me that C was the “language of the future”, and the right choice." http://blog.wolfram.com/2013/06/06/there-was-a-time-before-m...

tptacek5• 13 years ago

Yes, what a dummy Rob Pike is, to have jettisoned all the functional goodness of C.

masklinn8• 13 years ago

Something with ML/OCaml-level of expressiveness but with a replaceable garbage collector might be the sweet spot.

That's Rust: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...

TylerE10• 13 years ago

Kind of a shame that the Rust crew doesn't seem to "get it" the way the Go team does. The Rust stdlib is TERRIBLE. Even basic stuff like file IO isn't implemented sanely. A shame as the language itself is pretty good, other than the idiotic semi-colon decision.

dom962• 13 years ago

Nimrod is also a good option: http://nimrod-code.org

qznc• 13 years ago

Or D if you want C++level of expressiveness. The garbage collector is replaceable.

http://dlang.org/

The difference between ML and C++ is a tradeoff between efficiency and safety in my eyes. D comes from the C/C++ level of efficiency and improves safety. ML comes from a safe point and tries to be efficient.

coldtea5• 13 years ago

I thought it was a pretty poor language, obviously written by people who'd either never heard of functional languages or never "got" the point of them.

Or "got it" and didn't find it any that good, for the types of problems they work on.

rdudekul• 13 years ago

Good pros and cons of Go language. There is some information around why Go and not say C++/Java/Ruby etc. The statement "I see Rails as the emperor with no clothes on" seems to be made in haste, since Rails is awesome for basic forms based apps.

slaxman• 13 years ago

I know a lot of friends of mine who have C/C++/PHP background struggle with rails at the start, primarily because of the magic of convention over configuration that happens (they aren't used to it). It takes a while to understand it. But once you understand it, it's a breeze.

Disclaimer: I am a Rails developer. My views are therefore biased.

tracker1• 13 years ago

I think that, as with any automagic framework that the edge cases become exponentially more difficult to implement. I'm very comfortable with MV* frameworks on client and server, and still not big on rails.

It's also likely that TFA's author was frustrated with performance under load, where Ruby (and Python) generally do not shine.

Jd• 13 years ago

In many ways the problems people have with RoR are the same problems people have with ORMs. They abstract away a lot of the clutter, but then, just as you become totally dependent on the abstraction, you find you need something that you can't get in the abstracted layer.

When this thing is a substantial increase in speed, sometimes you are totally f*ed, since to get it you need to toss away a lot of the detritus. For an ORM you can gradually phase away parts of it, but for a web framework generally you can't architect away the box into which your app is placed.

I'm unaware of any RoR that has successfully scaled, except by removing Ruby (Twitter). Github is probably the largest existing Rails app (at least that I use), and there are Unicorns aplenty (the new fail whale), or weird caching issues that seem to arise regularly.

bsaul• 13 years ago

Best sum up of the language i've ever seen (plus it seems completely coherent with what i've supposed so far about that language, both pros and cons).

About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?

pkulak• 13 years ago

You pretty much can't write your own container without significant pain. That said, with the built in objects you have a map, list, set (map of bools, which is actually very nice since maps return default types - false - for missing entries), and concurrent blocking or non-blocking queue (chan). Stacks get a bit cludgy, but can be done without too much pain. Apart from those, I've really never had to roll my own collection class. Someday I may, but it is surely not something you need to do very often.

tptacek5• 13 years ago

On the contrary, I found it significantly easier to write a custom container (a trie in my case) in Golang than in Ruby (which let's stipulate is pin-compatible with Python). In particular, Golang provides fine-grained control over memory layout, and is even expressive enough to implement allocators, both of which are practically impossible in Ruby.

It's true that Golang grants a very useful power to its builtin maps, which makes it rankle that you have to cast in and out of interface{} to make your own general-purpose container. But apart from the fact that interface{} is a stupid name, I don't find it much more painful to write general purpose containers in Golang than I found it to write templated containers in C++.

nickpresta2• 13 years ago

You should actually be using a `struct{}` as the value, as it takes no space (opposed to a bool).

http://play.golang.org/p/KK1ymLzd_e

tptacek5• 13 years ago

As you might expect, it produces code that is somewhere in between C and Python, where custom containers are also somewhat out of idiom.

masklinn8• 13 years ago

There's nothing "out of idiom" of custom containers in Python (or are numpy arrays or pandas dataframes "out of idiom" now? I could swear that wasn't the case yesterday), and pretty much anything available to builtin containers are also available to custom ones (the exceptions being literal syntax, and true immutability unless the container is written in C).

In fact there are a few domains where they are rather common (e.g. multidict implementations in web framework, pretty much every web framework has one for query and form data; optimized or analysis-focused structures in scientific python)

mratzloff4• 13 years ago

About the "no generic / you have to cast ,recast / the make issue" , could anyone here with a bit of experience gives an example of what that would look like in real code ?

Sure. Say you have a Set type (which is custom, since Go doesn't provide a `container/set` type.

    type Set struct {
        set map[interface{}]bool
    }

All of the methods (`Add()`, `Contains()`, etc.) are going to be declared with `interface{}` parameters, e.g.,

    func (set *Set) Add(x interface{}) bool

You would also want a method to get a slice of all members, e.g.,

    func (set *Set) Members() []interface{}

If you want to use this as a set of strings, you would add without a cast:

    mySet.Add("foo")

However, when pulling it out you would need to cast it to a string. So if you were converting `[]interface{}` to `[]string`, it would look like this:

    values := make([]string, mySet.Len())
    for i, member := range mySet.Members() {
        values[i] = member.(string)
    }

axelf• 13 years ago

But since you have to use casts you are giving up some advantages of static typing, right?

fbomb• 13 years ago

For me, no templates + no exceptions = DOA.

jeremiep• 13 years ago

Exceptions I can easily live without; Haskell's monads provide a much better mechanism for error handling (Maybe, Either, IO, etc).

klibertp3• 13 years ago

You have generics^2 if you're using Haskell, so it's no wonder they are able to replace exceptions ;)

masklinn8• 13 years ago

Go has exceptions (panic/recover). They're pretty bad, you shouldn't use them (just as you generally shouldn't use exceptions in Erlang) and some in the Go community downright refuse to accept that they exist, but they're there.

TylerE10• 13 years ago

Templates are a sad hack in place of true hygenic compiler macros.

marshray8• 13 years ago

Macros are the sad hack. Templates can express compile time assertions.

bayesianhorse• 13 years ago

OH: "Any tips for getting started with Go?" Answer: "Yes, try Python."

coldtea5• 13 years ago

Imagine if the Go team listened all those that want Generics in Go. It would be more consistent and closer to perfect language.

As it is, it's a PITA 20% of the time.

(Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).

tptacek5• 13 years ago

What kinds of things have you written in Go, where the language has been a PITA to you?

jff• 13 years ago

"Well I would write things in Go, but I keep hearing about this generics thing so I'm just going to complain about it instead"

Djehngo• 13 years ago

Data structures usually, If you want to write a linkedhashmap or a dictionary where the keys are autogenerated from the values or any kind of structure not built into the language you are forced to either roll a new structure for each set of types or cast everything to and from (empty)interfaces.

While it's still possible with the casting, it doesn't feel as nice as the rest of the language does.

The other case seems to be any kind of generic pattern with channels, it's possible to build a channel-pair which acts as a single channel with a buffer only bounded by memory, but you can only do it for a single type.

All of these are avoidable or maybe even inadvisable, but it still feels like a hole in the language when you go to do something which is common, useful and trivial in C++/java/C# and you have to use ugly hacks or deal with heavily reduced functionality, especially when the rest of the language is so nice.

coldtea5• 13 years ago

A log scanner that does some analytics, a intra-company web service, ported a few Python programs to evaluate the performance, etc.

Copy pasting data structure code to fix for different types feels (and is) bad. Anything involving non DRY code I consider a failure. (Oh, and working with numeric types).

guywithabike• 13 years ago

Read the FAQ: http://golang.org/doc/faq#generics

Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

tikhonj2• 13 years ago

So instead of some--very limited, as languages like ML show--complexity in the type system, go punts these difficulties to the poor programmer who is then forced to constantly dynamically cast values, simultaneously adding clearly superfluous noise to the code and subverting any compile-time safety the type system offers.

Wonderful state of affairs.

happy_dino9• 13 years ago

Wow, they still mention that non-sense in the FAQ?

Let me guess, they also still link to that “OMG Generics are so hard” article where they conveniently manage to ignore the comments which point out the elephant in the room?

coldtea5• 13 years ago

This would make sense if it was written in the seventies.

jlarocco• 13 years ago

Articles on Go are getting a little boring. The majority are written by people who've spent an afternoon looking at Go and decide to rehash the same 5 bullet points. In the time it takes to read their "article" I could learn the same stuff, better, by reading the official Go tutorial.

Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...

tptacek5• 13 years ago

I agree about the articles themselves but vote them up because I tend to learn things on the resulting threads.

frou_dh2• 13 years ago

Go threads aren't as fun to read without uriel scolding non-believers for their bad taste.

zeeboo• 13 years ago

The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.

Arnor• 13 years ago

That's what's awesome about it! Everybody who uses it gets the same impressions of it (EDIT: and those impressions are 95% good). What other language has that going for it?

adw• 13 years ago

I'm a Python guy, and there's something in this, I think. One of Python's underrated virtues is how uncontroversial a lot of Python idioms are. The "only one way to do it" attitude helps there.

In my (limited, biased) experience, there's three camps among the Python community:

1. people who want principle-of-least-surprise: there's a lot to be said for boring languages (if the language is the most interesting thing about your product...). Often the systems engineering/service engineering crowd.

2. people who want it to be more functional – the Haskell/Scala/ML crowd. (I guess the overlap between camp 1 and camp 2 is Erlang...)

3. people who want access to the library ecosystem, particularly the Numpy/Scipy/Pandas/Theano stack (the scientific community, latterly data scientists). This is my tribe.

So you've got three crowds here, at least, unified by a language. Where are they going to head?

Go has nothing for the second crowd; they're all going to go to a purer FP language sooner or later. It doesn't have much for the third (no IPython, LAPACK bindings, Fortran bindings, stats libraries, machine learning, etc...); we all have an eye on Julia. But for the first: great deployment story, small language, decent standard libraries, markedly better performance than Python, much better parallelism story...

cjdrake• 13 years ago

You should look on the bright side. Every time one of these "Impressions of Golang" articles hits the front page, we get pages of bike-shedding in the comments.

dvirsky6• 13 years ago

I sorta like them for two reasons:

1. It's interesting to see what people struggle with or like about it, having written a lot of Go. That gives me some perspective, I guess.

2. The comments usually have these little gems of tips and tricks, like one I found here.

That said, #1 is getting a bit old.

SiVal• 13 years ago

I like these articles, because I like learning from other people's real-world experiences with various tools. He spent years using C++ at Google, yet decided not to use it for his own business even though he, presumably, wasn't one of the "junior developers" who couldn't handle memory management. He used mainly Ruby on Rails at his post-Google company and had a very negative experience. He says he'll write more about the naked emperor Rails. I'd love to read that article.

And if Haskell is so much better for real business infrastructure in practice, and not just a "more interesting language" in its own theory, I'd like to read more articles about companies that use Haskell, not fewer articles about companies using Go.

jongraehl• 13 years ago

This is better than the average such article.

I get the sense that many of us are just waiting for a few improvements (like generics and better GC/performance) before using Go for real work, but it seems mature enough for many uses already.

bsg75• 13 years ago

In my case at least, this article spawned a little personal research that has me now giving Go a serious try. With all of the new-ish languages and databases popping up, it can be difficult to choose which ones to try for a new project, or seek solutions for a new problem.

There is something in the initial life of a new technology that determines if the adoption rate will result in success or failure, where failure is abandonment and an end to development. If this sort of interest keeps Go going, then maybe some repetition is a good thing.

dvt7• 13 years ago

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository"

-- is unfounded. Even though there may be some good reasons why one might use Go instead of C/C++, I find it hard to justify using Go instead of Python/Ruby/JS/Java (the only criticism of Java - that it's verbose and hard to tune - is questionable as well). I've said this before. I like Go. I contributed to Go. I've used Go and I still use it from time to time. But much like D, I don't think it has a niche.

There are magnitudes more libraries and resources available for Python/Ruby/JS/Java -- thus far, it's been more than enough to sway me into using those languages (mostly JS/Java) instead of Go.

pron22• 13 years ago

I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small.

But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparalleled tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure).

Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM.

(P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go)

[1] https://github.com/puniverse/quasar

dvt7• 13 years ago

With cgo, Go can get "just as close" to the metal too. But I don't even think a cgo vs. JNI benchmark would be substantive. Most people don't use a "medium-"level programming language to write low-level code, anyway.

Like you say, Java is barely less verbose and arguably just as powerful as Go with many more times over the documentation and resources.

jeremyjh• 13 years ago

You have "ported" a green threads implementation for Java? I'd really like to know more about that.

pjmlp8• 13 years ago

My too, that is what made me stop playing with Go and look forward to D and Rust.

Initially Go attracted me, mainly because of the Oberon-2 influences (method declarations) and being compiled by default to native code. Java and .NET have AOT compilers, but don't tend to be used that much.

I even tried to do some initial contributions before the 1.0 release, but with time I got a Java 1.0 feeling. The language just throws too much away in the days that the enterprise is adopting Scala, Clojure, F# into their ecosystems.

I wish all the best to Go developers, but personally I don't think the language would be all the time here, if it wasn't being done at Google.

I mean, how often was Limbo discussed here, if ever?

quacker• 13 years ago

Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM.

I like Rust because it gives you control (like C++) but does so carefully (unlike C++). In ten years, Go should be a great alternative to Java and Python. In ten years, Rust should be a solid alternative to C and C++. (That is, assuming they both succeed.)

A language like Rust, which is reasonably expressive and safe but fast and with little overhead, should become a very desirable language as hardware improvements become more marginal (adding more cores eventually brings diminishing returns), and as battery life becomes more important with mobile devices.

But the portability problem is solved really well by the JVM. I'm hoping Rust will make writing cross-platform, native code easier.

fixxer5• 13 years ago

There are magnitudes more libraries and resources available for Python/Ruby/JS/Java

Those languages have been out longer. I think Go will get there.

EDIT: cgo dramatically expands the libraries. I hear a lot of people say "Go doesn't have X", but if X is already implemented in C (assuming some conditions are met), then you need not reinvent the wheel. I've been using Go as a concurrent parent over C functions for my geospatial research... really nice fit when you need to do 100 gigs worth of XYZ coordinate transforms.

dvt7• 13 years ago

I guess my extended argument is -- okay, so Go will get there eventually (I'll concede that) -- but then what? IMO, Go will still not be attractive enough to warrant a major migration. cgo is interesting, but we already have a Java analog - the JNI.

Domenic_S• 13 years ago

Those languages have been out longer. I think Go will get there.

Maybe so, but that doesn't help today.

pron22• 13 years ago

I think Go will get there.

Possibly, but the language has very little to add over the incumbents. I think many Python programmers are attracted to Go because it's easy and so much faster than Python. But for veteran Java programmers, Go feels like a handicapped Java.

I will admit that it's probably faster to write a short Go program than a Java one. But on the JVM I'd use Clojure for short-and-sweet stuff anyway, and use Java when I need the big guns.

microtonal• 13 years ago

This claim: [...] -- is unfounded.

Actually, most of that enumeration consists of shallow clichés. For instance, take the description of Java:

Java: too verbose,

Having written a fair share of Go and Java code, I have to say that difference is not all that profound. The usual boilerplate that people come up with is the construction of a BufferedReader/Writer. But Go has its share of boilerplate as well (e.g. error handling). Java currently has the advantage that IDEs can quickly generate whatever boilerplate is necessary. Given that Go is easy to parse and has a simple module system, there'll probably fairly complete IDEs for Go as well.

too many FactoryFactories

That very much depends on what libraries or frameworks you use. I have written lots of ML and NLP code in Java the last half year or so. I can count the number of insane 'FactoryBuilderProxy'-like classes that I encountered on one hand. Wait a bit and the architecture astronauts will also be writing Go packages ;).

stcredzero12• 13 years ago

Actually, most of that enumeration consists of shallow clichés.

You can apply this to most of the writing about programming languages out there. My view might be skewed on HN, but it seems like the majority of this stuff is put out by programmers trying to promote themselves.

ionforce5• 13 years ago

It's weird. You mention that the claim is unfounded, and then you have all this text that follows, but none of it seems related to supporting your point.

How is the claim that [X at large is difficult to maintain] unfounded?

I happen to agree. I am (was?) a Perl/JavaScript developer. I find both to be sorely lacking at a certain size. And by extension I assume Python and Ruby to be the exact same (under the shared umbrella of lacking static type safety).

davesims• 13 years ago

I was about to post the exact same comment, with the above quote from OP in my clipboard.

In my experience, this claim is made by (many times really good, experienced, intelligent) coders who have a lot of previous experience in static typing and aren't comfortable -- either because of a lack of time and sheer LOC, or because of some mental block they've doubled-down on ("where's my 'extract method' menu option???") with the techniques and peculiar challenges of dynamic type refactorings.

I work on a very large application/system of applications in a dynamic environment, and I've never encountered refactoring or maintenance issues that I thought would have been any easier in my previous life, 10 yrs in static typing.

The other thing to keep in mind is that -- at least when comparing something like, for instance Rails to Java, there will be a lot less code, and this is a significant contribution to code management. That factor, plus just experience and acclimation to the techniques for dynamic-type editing/replacing/finding/greping and so on, plus solid TDD practices -- maintenance has never been an issue for me, and I've had a decent amount of time in large codebases in both dynamic and static environments.

ionforce5• 13 years ago

With a static language, you get more with less. If you didn't have any testing framework, the compiler would tell you where you messed up. So, there's that, barring "well you should have had testing code to begin with".

Grepping is ghetto, second-class. Whereas an IDE with built-in refactorings has a much higher guarantee of hitting the right artifacts, especially with shared substring collision. Again, barring "well you should have named things better".

Having spent the majority of my career as dynamic and now a recent convert to static, I fail to see the allure of dynamic languages at a certain scale. You can shoot yourself in any language, but I think it is easier and safer to crawl out of a static mess than it is a dynamic one.

And, I would argue the majority of applications do not demand the level of dynamism that dynamic languages are capable of, making it a waste.

btilly2• 13 years ago

-- is unfounded.

Not necessarily unfounded, you simply don't have access to data on it.

I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.

The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.

stcredzero12• 13 years ago

I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.

A big part of this is the shortsightedness of the companies themselves. There are steps you can take to ensure that you can manage types in dynamic languages. Very often, companies simply don't take these steps. It's not programmers that need babysitting by tools. It's big enterprise.

pron22• 13 years ago

initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.

I don't have any hard data, but this feels right. I wonder what would be the results with Clojure, which certainly isn't statically typed, but doesn't do duck-typed function dispatch (like Ruby and Python, and even Go) either.

burntsushi8• 13 years ago

This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository" -- is unfounded.

Why is it unfounded? The author clearly qualifies his claim with "my experience". That's my experience too. I wouldn't extrapolate it to all programmers and in all scenarios, but dynamic typing just has never worked that well for me in larger projects.

It could be because I'm not as diligent about writing unit tests or it could be because I'm not intelligent enough to reason about large amounts of code without static types. Regardless of whether it is, it's my experience and it certainly isn't "unfounded."

ionforce5• 13 years ago

I don't think reasoning about types is a matter of intelligence. I happen to share your experience. It is more of a cognitive burden, exacerbated by less diligent coworkers. No amount of "convention within dynamism" can compete with first class compile time type safety.

If I were to babysit a codebase by myself, maybe I would not feel this way. But with regards to professional team development on a large code base, the ship has sailed on dynamic languages.

sprash• 13 years ago

Dynamic typing has advantages and disadvantages. E.g. Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse whereas compile time type checking reduces the effort for testing (but for very simple cases only).

asdasf7• 13 years ago

Static typing violates the DRY ("Don't repeat yourself") principle concerning code reuse

How did you come to that conclusion? I can't see any way that static typing "violates" DRY.

el_bhs3• 13 years ago

@dvt, this is the OP here.

I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't agree with me [yet! :)] about dynamic languages, though.

I will write a followup post later this week about the long-term maintenance problems associated with languages in the python/ruby/javascript family. I don't think they're "bad" (I was known to advocate for python in certain situations when I was at Google), but they're often inappropriate, and it is my sense that many developers haven't had the requisite large-dynamic-language-project trauma yet to understand that from firsthand experience. (The toughest part about those traumas is that they happen so late in a project's lifecycle that there's no quick way back to safety...)

So I will try to make that case in a future post. Thanks for your thoughts.

Peaker9• 13 years ago

Dynamic languages work out great when code coverage is ~100% at every run, and runs are short.

Virtually all programs start out that way, so dynamic languages feel great.

As they grow, the pain creeps in very slowly. As you said, by the time the programmer realizes he's in hell, it's too late to fix it.

dvt7• 13 years ago

Maybe you'll convince the rest of us! If you do write another blog post, try to include the recent indie nightmare that was purportedly caused by Go[1]. I think it's relevant here (since we're discussing large projects, after all).

[1]http://forums.thedailywtf.com/forums/t/27755.aspx -- it was also on HN but I'm too lazy to dig out the thread.

asdasf7• 13 years ago

I think go does have a niche, and it is "python/ruby devs". Yes, its niche is a set of people, not a particular role. Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby, I see a lot of ruby and python devs upgrading to go.

I also think you are being unfair to D. D is basically just what go initially claimed to be: a new systems language. D is a fantastic replacement for C++, go doesn't really enter the world C++ lives in.

stcredzero12• 13 years ago

Because go is so simple for a typeless developer to learn, and has essentially no downsides and a massive upside (performance) compared to python and ruby

I think that's a brilliant observation! It's all of the duck typing goodness with far less of the static typing overhead. It's static types "lite" for duck typing lovers.

codezero• 13 years ago

I agree with most of this post, but I actually found online resources (especially golang-nuts and various SO pages) to be very helpful with debugging.

VeejayRampay• 13 years ago

I see it's become trendy to poke fun at Rails and the hurdles it puts on your way to "scale". Not only have many companies been able to do so using Rails, but it also completely overshadows the ease it provides to get started in the initial phase of a project.

That being said, Go really seems like an awesome language, I've dabbled some and I can't wait to get back to it.

oakaz• 13 years ago

"The standard library is missing x"

What you are looking for is actually a productive community with a good module manager. This what Golang is missing.

(Golang fans: don't get me wrong, I use and love Go.)

stcredzero12• 13 years ago

C++: too much rope, hard to maintain, painful to introduce at a company with no prior C++ footprint, frightens junior devs who no longer absorb relevant memory management idioms in school

So, are we now in an era when there are lots of people in the job market who couldn't write a doubly-linked list to save their life?

When I was in my 20's, I noted that there were lots of programmers around who basically treated compilers as "magic" and hadn't the tiniest inkling about how they worked. Now that I'm in my 40's, I've noted "so what" attitudes in languages that require manual memory management. (iOS and Objective-C. ARC goes a long way, but it still doesn't take care of everything for you.)

tropicalmug• 13 years ago

I am one of those programmers: I have no real idea how a compiler goes about its business, my university does not offer an accessible compiler class (only for grad students and very irregularly), and I have no idea where to start besides trying to force my way through the purple dragon book.

What are things I should know about compilers that I probably don't? What is suggested reading on compilers?

xtracto• 13 years ago

I am not an expert in compilers, but in my undergrad compiler's class one of the things I remember the most are parsers (such as LALR). I remember having a great time implementing different types of parsers:

http://en.wikipedia.org/wiki/Category:Parsing_algorithms

I think the dragon book is the absolute reference for learning compilers:

http://www.amazon.com/Compilers-Principles-Techniques-Alfred...

stcredzero12• 13 years ago

As xtracto mentioned, parsing and enough automata theory to understand what context free grammars are and where they fall should be part of your basic toolkit, but how they generate code is even more useful to C programmers. (One study done decades ago found that the average C statement resulted in 2.7 CICS assembly language commands.)

The Dragon Book is not the best teaching tool out there. Maybe try The Elements of Computing Systems Chapters 10 & 11? You might need to peek at the earlier chapters to get a grounding in the particular assembly language they use.

RogerL2• 13 years ago

I am not the person you are responding to, but I don't think the point was to understand how compilers parse code, but to know how the compiler implements your code in assembly. I.e. knowing things like the difference between the stack and the heap, how to do a function call in assembly while passing parameters, how memory actually gets allocated to you from the operating system, what happens when a page fault occurs, how the compiler lays out data in memory (this has huge implications in your code as to whether you generate a ton of cache misses or not). None of that really has much to do with understanding compilers, but understanding modern microprocessors and assembly code.

But, of course, you need to pick what makes sense to you. If all you ever do is write MySQL queries for low performance requirements apps, probably all of that knowledge will prove of little use to you. But to actually debug something when it goes all the way to the OS, to deal with hardware, to write a device driver, you really can't get far without knowing it. If you are programming in C/C++ or otherwise doing anything performant (3D graphics, CUDA GPU programming, and the like) you'd better know all that stuff intimately if you strive to do more than "program by magic" (when something breaks, randomly change code until it seems to work without you understanding why).

When you know this, you can basically go into any programming assignment and get it done. Interface this phone to this hardware? Done. Fix this nasty blue screen crash? Okay, no problem. Modify the linux kernel for some local need? I'll get right to it! Without it you are kind of restrained to working on top of the infrastructure that others have built. Not that there is anything wrong with that - it's your career, and your life, you might as well try to have fun while doing it.

electrotype• 13 years ago

"Java: too verbose, too many FactoryFactories, painful to tune"

Paintful to tune... Maybe. But I don't understand why so many people say patterns like FactoryFactoryFactories are inherent to Java!

I can write Java code with NO factories at all. Writing shitty and unflexible code is really easy. When you understand why a factory is used in a particular piece of code, you start to appreciate it!

It's also very possible to write C++ or Python code with too many overengineered components.

Also, I like a language to be verbose, I don't think it is an issue. As long as the code is clear and easy to read... And it's often the case with Java programs. For my eyes, Java is way more readable than, let's say, Perl, Scala or Clojure. I couldn't care less about the number of lines required to achieve the same result!

I'm getting tired of this Java bashing... The only thing that really sucks about Java is Oracle!

pron22• 13 years ago

Even Java bashers would concede that Java is a brilliant language, certainly for its time. And the JVM is the most impressive programming environment to this day.

But the language has become a little dated. Oh, you don't need to go as far as Scala to fix it (to me Scala feels like a deranged, haphazard combination of javascript and Haskell), but something like Kotlin could really be a "better Java" (it also happens to be a better Scala, but that's a different point).

sarnowski• 13 years ago

In fact, since go does not have explicit constructors, it encourages the factory pattern all over the place. You'll find static factories everywhere in the go library.

http://golang.org/doc/effective_go.html#composite_literals

tomp2• 13 years ago

In modern languages, you don't need to write a class when all you need is a first-class function.

pjmlp8• 13 years ago

Modern languages?! This has been possible since FORTRAN.

Ygor• 13 years ago

I guess when you talk about a language, you usually also end up talking about the platform, libraries, community and the whole environment. It is hard to escape from this when talking about Java.

For those that are not in the Java land - the whole Java ecosystem is heading in an interesting direction.

Not just the platform (with all the other jvm languages), but the java language itself. Using Java 8 and some of the new features, suddenly standard Java code starts looking more and more modern. Add to this some interesting developments in the framework land, like NIO with Netty, Gradle combined with maven repositories for dependancy management, even new developments in entrenched stuff like Spring or JavaEE...

The community and the ecosystem is slowly evolving outside the whole enterprise monstrosities. It will be interesting to observe the platform in the next couple of years.

dvirsky6• 13 years ago

I know it's not a popular view, but being pretty much in love with Go, what I find most difficult about it is the lack of any real IDE. And by real IDE I basically mean: a rich editor, stable code completion, jump-to-declaration etc; and tight debugger integration.

Unless I'm really unaware of an IDE that has all of them, all the IDEs that support Go fall short:

1. IntelliJ plugin - excellent editor, a lot of the intellij goodies; but I've managed to break the code completion, and it's tricky to configure with respect to GOROOT and GOPATH. and most importantly, no GDB integration whatsoever.

2. GoClipse - reasonable (although buggy) debugger integration, very good code completion, no jump to declaration which is a pain, plus a wonky build system - the build can fail and you see no message, and the program just runs from the previous build.

3. Sublime with GoSublime and SublimeGDB: the build system is buggy, code completion is great (managed to break that too on complex projects), no jump to errors, don't remember re jump to source. I had to do a lot of voodoo to get SublimeGDB to work half decently, and even that was not very robust because SublimeGDB is buggy on its own.

4. LiteIDE - has everything in theory, but just feels a bit clunky and hard to configure. I didn't like it as an editor and haven't spent much time with it. But it's constantly improving so I hope it will get there some day.

The rest are Windows only so out of the question, less complete/mature than those 4, or vim with plugins. I don't like vim, I like graphical IDEs, shoot me. :)

Again, I really really love Go, I hope it will allow me never to write C++ again in my life. This is not a "Go is not ready yet" gripe. It's just what I find most difficult about it.

TylerE10• 13 years ago

Just curious, but what issues did you have with GoSublime builds? It's using the `go` tool under the covers.

dvirsky6• 13 years ago

A few are just UX quirks - ctrl+b tries to build from the current package, not the project root, leaving you tabbing to main.go for each recompile, which is annoying; cursor "runs away" from the prompt not affecting anything. but mostly, the output is buffered.

I wrote a toy MapReduce framework that yielded tons of output. It crashed Sublime because it buffered the entire output into the console instead of printing it into some sort of FIFO buffer like IntelliJ or Eclipse do. Again, running from a terminal is ok, but the whole point of an IDE is to save you from fiddling with lots of windows and terminals.

Ziomislaw• 13 years ago

vim + a bit of tweaking , ie. completion plugin [1] (probably there is an emacs mode too - which has all of the above)

[1] https://github.com/nsf/gocode

dvirsky6• 13 years ago

I tried the recommended vim plugin. it was okay, nowhere near as powerful as intellij's plugin - and still didn't solve my gdb issue.

papaf• 13 years ago

Although it is not as shiny as modern IDEs it is worth making the effort to use emacs - and I say this as a vi user :-)

Whenever a new language comes out it is usually supported by emacs and vim (go has the support files in the source tree). Learning emacs is a small but frustrating investment in time that pays off over the years. Of your points, it has a rich editor and tight debugger integration.

Jump to declaration is a pain but possible using exhuberant etags [1]. You may even prefer using ack [2]. Emacs does code completion but I've never been bothered to get it working.

[1] https://groups.google.com/forum/#!searchin/golang-nuts/emacs

[2] http://www.emacswiki.org/emacs/Ack

rubiquity• 13 years ago

I'm getting sick of all these Go goroutines... err threads.

pjmlp8• 13 years ago

You mean Modula-2 co-routines. :)

st3fan• 13 years ago

How is "deploying modern Java applications, which is a minor nightmare IMO" true?

Dropping a .war file in a directory is hard? Or am I missing something about 'modern' Java apps?

mwcampbell• 13 years ago

I agree with the point about statically-linked binaries. However, I wish there were a compile-time facility for including the contents of a file as a read-only byte array in the binary. Then web application servers with HTML templates, and even images and other assets, could be truly self-contained.

lectrick• 13 years ago

The more I learn about other langs, the more I appreciate the language design of Ruby, even though Ruby is slow as shit.

Impressions of Go

Related Stories