Go After 2 Years in Production

http://blog.iron.io/2013/08/go-after-2-years-in-production.html

by treeder • 13 years ago

323 171 13 years ago

blog.iron.io

melling2• 13 years ago

The memory footprint for Go seems to makes it ideal for mobile devices. Also, considering that Dalvik performance is much slower than Java, it really seems like have Go on Android would be a huge win.

http://en.wikipedia.org/wiki/Dalvik_(software)#Performance

Go compiles to native, so "compile on install", would probably be needed.

programminggeek3• 13 years ago

Go on Android would be great, but Google used Java in the first place so that they could leverage all the Java devs in the world to build Android apps.

Go might be a much better choice from a pure dev standpoint, but from a getting everyone to build apps standpoint, it's a fail in the short/middle term.

melling2• 13 years ago

I didn't say get everyone to build apps. It would simply be another option. App development is getting more competitive, of course, so people that want to stand out might need to move to Go to gain an edge. Plus, I image that a Go environment might provide a better interactive development cycle.

jlarocco• 13 years ago

I'm not so sure. There's no lack of iOS developers, and most of them are using Objective-C...

lttlrck• 13 years ago

NDK on Android is native (C++/C) and it's there to boost performance and avoid GC in game loops. I've seen too many devs discussing how to mitigate the effects of GC in games to consider Go to be a worthy upgrade at this point in it's development, the NDK would probably still be needed...

rdtsc• 13 years ago

Go has a GC so still not sure that would help. You'd have to benchmark it though, it might not matter.

binarycrusader• 13 years ago

(disclaimer: My opinion on Go is based on my own limited experience from writing a few private projects using OpenGL.)

Go seems like an exercise in frustration to me at the moment for anything GUI or low-level OS-related.

Many GUI libraries use an object model that's difficult to map onto Go's heavily restricted interfaces, especially with a lack of generics.

In addition, interacting with popular libraries (such as libsdl or even OpenGL) that use thread-local variables (TLS) means using ugly workarounds like this one:

http://code.google.com/p/go-wiki/wiki/LockOSThread

So I think it really comes back to the "right tool for the right job." For most command-line utilities, and for anything networking-related, Go would be my first choice.

But for anything that needs a modern GUI toolkit and uses OpenGL, it would be difficult for me to justify.

Again, I love the model Go provides for programs and packages purely written in Go; it's only when interfacing with system-level components that I get cranky.

dancric2• 13 years ago

As a developer on the Python stack, I would love to know when would be a good time to start using Go in serious production work. It seems to me that it solves a lot of the backend services infrastructure problems associated with interpretive languages (one of the reasons I was considering diving in Scala or other JVM languages), is relatively reliable, and has a fairly strong core library. It still seems bleeding edge, but the language seems to have developed far faster than Python did over the last decade or so.

eblume• 13 years ago

Only one way to know that: give it a try!

dancric2• 13 years ago

Good point!

kintamanimatt3• 13 years ago

I would love to know when would be a good time to start using Go in serious production work

Now would be a good time. No language, runtime, compiler, library, or framework is ever going to be perfect, but now is a great time to dive in.

It still seems bleeding edge

This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people.

but the language seems to have developed far faster than Python did over the last decade or so

Language designers are getting better at marketing. No language succeeds without fantastic marketing.

gnur• 13 years ago

Exactly, there is never a better moment to start learning something new then now.

microtonal3• 13 years ago

This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people.

As was Javascript plus Node.js two years ago, Ruby and RoR five years ago, etc.

You'd think that more reasons are required than 'it is new, doesn't have baggage in was created by smart people'.

bhauer7• 13 years ago

The analogy is a little flimsy, but I'll run with it anyway: I consider Go today to be similar in some ways to Java at around the time of Java 1.1 or 1.2.

Obviously, Go is modern and is in many ways better than today's Java 1.7. But I am trying to illustrate its maturity level and the trajectory that I believe it's on. If you recall the days of Java 1.1, it was already seeing a great deal of early traction. The early traction of Go seems roughly the same to me. Also Java in its 1.1/1.2 years was on a clear trajectory to become a dominant language. I think Go will only grow in popularity for years to come in the same fashion. Even as a primarily Java developer, I look forward to Go being a clear and viable alternative.

I could be wrong about the trajectory, of course.

But I believe a short answer to your question is: if you're considering it, take some time to actually do something with Go. At first something experimental, then something for production use.

As a long-time JVM user, I've been trying to explain to other developers for a while now that assuming you use a modern approach to Java development, the performance of the JVM allows you to be (in my opinion) even more efficient than a dynamic language because you can code your application fairly recklessly. You can defer optimization in all of its forms for a long time, perhaps infinitely. The resulting mindset is a dramatically reduced concern about performance. When I work with most dynamic languages, I can never fully set aside the inner voice saying, "this is going to perform like crap." Trouble is, the voice is often right.

Go brings the same ballpark of performance as the JVM and a style that I believe is more appealing to Python developers than a modern Java stack (although I don't think modern Java stacks are given much of a fair shake because of Java's legacy, but that's a separate rant entirely).

Pxtl2• 13 years ago

And like Java 1.2, it is still missing some critical deal-breaker features for a lot of people.

waterside81• 13 years ago

This might help you:

http://blog.repustate.com/migrating-code-from-python-to-gola...

I love using Go and I'm a Python guy through & through.

nknighthb• 13 years ago

I'm using Go in production, and migrating existing Python services to it. I've found nothing wrong with using it for "serious production work". The ecosystem obviously isn't as mature, but it's getting there. There don't seem to be any gaping holes.

programminggeek3• 13 years ago

Go seems to be hitting some kind of tipping point where it's going from being more of a niche thing with a small user base to something with a broader appeal. I don't think that it's because go is changing so much as the kinds of problems people are encountering writing web services that need to scale (or at least have that option).

I've been comparing go to scala lately and what has really got me into go is the development speed. The fast compiles and fast web page auto-reload make it feel every bit as fast to develop in as ruby or python or php, but with type safety, fewer tests, and very clean code.

Scala is a fantastic language, but even with jrebel autoreload you still have 2-3 second page reloads and a 5 second test suite reload. That seems like a small thing, but the faster I see code change results, the more hooked I am to the process. A 5 second wait is probably enough to get me out of the zone.

With go, on just a default simple test of a small thing it is less than a second to compile/run. In revel, pages reload/update as fast/faster than they do in rails/sinatra.

Oh, and with go, each web request will run in a separate goroutine, so you get excellent nonblocking IO performance without dealing with the callback soup of node.js.

It might just be irrational exuberance because I haven't built anything big and messy yet, but so far go is seriously fantastic and solves a lot of real world problems elegantly.

illumen• 13 years ago

So you've enjoyed all the marketing and Google employee upvoting?

untog• 13 years ago

So you ignored the part where the OP described having actually used it in development and liking it?

tptacek2• 13 years ago

Comments like this never, ever improve threads.

thezilch2• 13 years ago

As much as you've enjoyed the "GENERICS OR BUST" and anti-Google, downvoting crowds.

_ak3• 13 years ago

Yes, it's all a conspiracy! Because that's how open source development at Google work: create shitty technology, spam HN, Reddit et al. with it, and then let the massive Google workforce and the fanboys upvote the postings.

swah• 13 years ago

Their philosophies are so different, though. Mostly the only thing they have in common is being "modern" in their own ways.

eranation2• 13 years ago

Oh, painful point, I still try to ignore Scala's compile time and hope it will improve in the future, (it does gradually on every release) but when I do, then Scala feels a bit more natural to me than Go (it feels closer to Ruby for me, which I like, and has the Java interop aspect, which I unfortunately need). I just close my eyes, do sbt ~test-quick, and hope for the best. It's just that Scala feels to me more like a statically typed Ruby, where in Go I need to shift some paradigms and do some mental twists to accept how great it is.

carimura5• 13 years ago

A long tipping point, but one indeed.

Pxtl2• 13 years ago

I know it's cliche, but I still can't live without generics or a macro-like approximation thereof. I suffered under Java 2 for too long to go back to that.

rprospero3• 13 years ago

It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in:

div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a))

than it is in

(-b+sqrt(b^2-3ac))/(2*a)

On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably curse any programmer who used it and thank the gods that it was left out of Go.

Conversely, since I write a lot of numerical code, I don't care about generics or typing, which is crucial to many other programmers. Generics don't matter since everything I work with is either a Double or a collection of Doubles. Similarly, static typing doesn't help, since most functions just have the type (Double -> Double) and the type checker can't tell a sine from a logarthim. Of course, the reverse is also true. Since everything is either a double or a collection of doubles, the fancy tricks that dynamic languages offer don't give me a damn thing, so I'm extremely ambivalent about the typing debate.

Of course, on other projects, I've written code that benefited from static typing and I've written valid code that would choke any type checker. I've written code that heavily needed generics. When I did that, I used the languages that had the features I needed.

Go just won't work for the programs I write and it sounds like it doesn't work for yours, either. That's why we won't use Go. I've heard it works wonderfully for a certain class of server software and I'm glad those guys have a useful language for their domain. If I ever have to write another server, I might even teach myself Go. But don't feel guilty that you're using an old hammer instead of the shiny new saw.

termain• 13 years ago

Ambivalent or apathetic regarding the typing debate?

Typing can become useful in numerical code when you move past operating on scalars. Column and row vectors needn't be confused, a two-vector and a complex number have different types, etc.

Also, physical quantities can have different types and a type system can be useful there.

I totally agree that for numerical code, operator overloading is of great utility.

scott_s4• 13 years ago

If you haven't seen Julia, you may want to give it a look: http://julialang.org/

Introduction to the manual: http://docs.julialang.org/en/release-0.1-0/manual/introducti...

zwieback• 13 years ago

Agree with what you're saying but I think you probably wanted 4ac

lightcatcher2• 13 years ago

If you don't mind me asking, what sort of work do you do where you mostly write numerical code? Academia?

howeman3• 13 years ago

It's not quite that bad in Go,

(-b + math.Sqrt(bb - 4ac)) / (2 a)

though if you're using a ton of matrices it could be.

I for one have found Go great for computing. The really quick compile times with static checking plus the composability are great. It definitely depends though; while the native concurrency is great there aren't a lot of easy solutions for non-shared memory computations. (I saw an MPI package at one point, but I haven't tried to use it)

JulianMorrison• 13 years ago

You and FORTRAN were made for each other.

kibibu• 13 years ago

and the type checker can't tell a sine from a logarthim

Oddly enough, in Go it can.

    type sine_val float64
    type log_val  float64

These are now incompatible types, and you couldn't pass a sine_val to a function expecting a log_val, for example.

(Not that I am advocating this sort of approach, but it is possible to let the typechecker work this stuff out if you are dedicated)

bpodgursky• 13 years ago

Totally with you. I can't imagine using a language where I can't create easily re-usable data structures. It feels like a huge step backwards.

bitcrusher• 13 years ago

I can't be the only person who thinks Go is really interesting, but can't get over the 'package' hump... It's just too wonky for 'real-world' from my experience. For example, how do you create clear lines of separation with internal modules? If you want to use 'namespaces' then each namespace has to be it's own package, which then requires its own Repo that you have to 'go get'. There's unsustainable for a project of any useful size.

I must be missing something.

BarkMore3• 13 years ago

Organize your packages in a directory tree. You can check the entire tree into a single repository. There's no requirement to put the code in a repository or use 'go get'.

The page at http://golang.org/doc/code.html explains how to organize code into packages.

Game_Ender• 13 years ago

Google has said they don't use 'go get' internally to manage dependencies, so they appear to agree with you.

gt384u• 13 years ago

I would imagine this has something to do with having an existing package dependency management system company-wide and it causing friction trying to get the two to coexist.

I have similar issues where I work with trying to integrate an internal build system and rubygems. Our answer is to essentially mirror the gem version internally into our own repo. It's not the best answer I could hope for.

trevordixon• 13 years ago

Exactly what I've been wondering. I've done `import "./[internal_module]" in some of my little experiments, but I've read that's unacceptable.

BarkMore3• 13 years ago

Absolute import paths are preferred. If the import path for the importing package is [app], then import the package using `import "[app]/[internal_module]"`.

Laremere• 13 years ago

Each package does not need to be in its own repo. You can put packages inside subdirectories. The standard library is full of these, such as the net library. There is the net library itself, and there are subdirectories, including http, smtp, and more.

zeeboo• 13 years ago

You can have multiple packages in one repo. All of our code consisting of dozens of packages is in one repo.

jbooth• 13 years ago

They can all be subdirectories of the same main repo, yet import each other with paths like github.com/mainrepo/packagename.

The real thing that I haven't figured out a consistent solution to is how to manage versions. You could approximate version numbers with branches or tags, but nobody's put together a convention for it that works well with the tooling. That'll be important as go matures and has more libraries.

paddyforan3• 13 years ago

Packaging is both the best and worst of Go. I love the decentralisation, so there's no central directory of Go code. We don't have pypi, we don't have rubygems or npm, we have Github.

As others have pointed out, you can use directories as namespaces, which works nicely. But I've found, personally, that splitting my projects into separate repos for each namespace is actually beneficial. Helps keep my code clean and separated.

That being said, versioning is a real pain right now. The best thing I've found is to fork a repo when I decide to use it, then pull in updates as I adjust my code to work with them. Definitely not ideal, and if you have a lot of projects using the same dependency, it becomes a major headache.

There are some workarounds, and we've discussed the topic at great length on the mailing list. I think it's something we'll see a solution to in the next few years. But one of the things about Go that I really enjoy is that the core team is hesitant to push half-baked ideas onto the community. When we see a solution, it tends to be an elegant, clean solution that fits perfectly into the problem it solves.

In other words: yes, there are some problems. Yes, I do think they'll go away. Yes, I do think we'll need to be patient. Yes, I do think it will be worth it.

jd0072• 13 years ago

"Two years in, Go has never been our bottleneck, it has always been the database."

I would expect this to be true with any language, if you code well. Regular web applications do not have state so they are very easily scaled horizontally anyway. Databases on the other hand are trickier to scale the same way and will end up being the bottleneck almost all the time.

bhauer7• 13 years ago

In my experience, with slower platforms/languages, while it may be conventional wisdom that the database is the bottleneck, that's not actually the case in many circumstances.

Certainly in circumstances where you're doing a complex query involving fields that are not indexed or several joins, you're going to be waiting on the database.

But if you're just fetching rows by ID or indexed fields, slower platforms and languages end up being a bigger bottleneck than modern databases. Sometimes this is masked somewhat by the fact that the database drivers and/or ORM are slow, so from the application's perspective, the "database" is the bottleneck. But one should not confuse the drivers and ORM for the database.

jd0072• 13 years ago

If you are talking about a breakdown of time consumed during a single request's processing, then yes on slower platforms/languages/frameworks, the database access portion may not be the most significant percentage of time used. But this is not that relevant as even the slower platforms usually can handle a single request reasonably fast.

What I was talking about was more about in the scaling of a system, i.e. what happens when your architecture needs to handle lots of requests. In this case, it is very rare for the application server part of your architecture to be a bottleneck in scaling because it is generally stateless (for normal web apps at least) and hence very easily horizontally scaled out. Of course a faster platform will allow you to use fewer servers but 15 servers on Go vs. 20 servers on Python is not that big of an issue.

noelherrick• 13 years ago

Horizontal scaling does not take away latency. Also, iron.io saved a bunch of money by not using extra instances.

jerf• 13 years ago

Profile your code. You might be surprised.

You might not.

Or, you might be surprised when you find something like "I'm making 5000 DB queries?" instead of your language being slow.

But certainly if "enough" people take my advice here who have not profiled one of their web pages before, there's a non-empty set of them that are going to go "Oh crap, I didn't realize that's what was so slow, I just assumed it was the database!" Not every web app is a glorified select statement.

And there'll also be quite a few people who discover that their page isn't "slow" or anything, but who will discover that the CPU vs. IO is closer to 50/50 than they realized or something.

paddyforan3• 13 years ago

I think one of my favourite things about Go is that it makes it easy and obvious to code well. Generally the first thing that comes to my mind is going to be performant and extendable.

The reason this is the case, I think, is that Go strives to make algorithmic complexity clear: you know when you're allocating memory, but you don't need to jump through hoops to do it. You know the rough performance costs of what you're doing because the core team works hard to make it obvious. For example, some regular expressions features (lookahead, if I remember correctly) aren't implemented in the Go standard library's regular expression package, because they're impossible to achieve in O(n) time. https://groups.google.com/forum/#!topic/golang-nuts/7qgSDWPI...

This level of care in making simple, clearly-defined tools with known properties makes it easy to code well. Ruby, Python, PHP, NodeJS... you can shoot yourself in the foot and not even notice.

nexneo• 13 years ago

Thats not true for Ruby or it needs lots of fine tuning to make this statement true.

asdasf2• 13 years ago

Throwing servers (money) at the problem is often incredibly wasteful, and exasperates the other problem you mentioned (the database). Having 500 servers all connecting to the database is not so awesome. Having 10 is a lot nicer.

encoderer2• 13 years ago

Ah yes the old "engineers are more expensive than machines" adage.

Thing is, that's true for some small number of machines. But when you build scalable systems and actually scale them you get to a point where the balance tips. And it just so happens that building those systems is exactly what the Golang team has in mind.

neya4• 13 years ago

Another Scala user here. And I've been using Scala for the last six months. Mostly developing web applications on Scalatra and Play. I love Scala - It still has its goodiness and it's an excellent alternative to Java.

If you notice in all of the Scala books (I've read the one by Martin and the One by David Pollak as well), they all seem to push you towards the functional programming model instead of the much more common imperative model.

But you know, there's a problem with that. Not with the language itself, but with the web development side of Scala. There's only certain ways by which you can program with a particular function that accepts a request and returns a response. So, most of the time, I would find myself wasting time thinking "How can I make this more functional?"

Functional programming is really great when you can actually enforce it - When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks, because you have to constantly keep changing your mindset between these two models.

Another downside of Scala is its HUGE syntax. Processing strings? Here's a ten million ways to do it.. (a bit over-exaggerating). Oh and if you chose this way, then you should use this syntax. No, not that one, THIS one. Oh no, not that one, this variation of that one that looks like this.

I've advocated Scala to many HN members here in the past, you can even check out my comments, for instance. But from my experience, I think Scala is an Academic language. But it's superior in its own ways - I just LOVE the concept of avoiding nulls and passing an Option. It's beautiful. But the downside is its huge academic complex syntax. I want to be able to write code which shouldn't reduce my hair count even if I look at it after 6 long months. I don't want to refer to an 800 page book each time I'm confused about something.

That's why I think Go is beautiful. The syntax is just enough to keep it inside your head forever. I fear that as the language matures, this might also evolve into something as complex as Scala, but let's hope not so.

Go isn't a magic bullet though. It has its own downsides, but nothing w.r.t performance or similar. For the most part, it's awesome.

Once you go Go, you never go back.

P.s - I still love Scala as well ;)

m0th87• 13 years ago

I think Scala is an Academic language

Sometimes "academic" seems like a catch-all for stuff people don't like. Scheme has a strong academic history in its use and implementation, yet it seems to be described as "academic" only when someone is unhappy with how minimalistic it is, which is the opposite issue described here.

neya4• 13 years ago

Sorry, maybe like the other commenter mentioned below, the word I probably was looking for was 'industrial'. Or whatever refers to it as 'massive and complex'.

Not necessarily a bad thing, for web development, most of it's depth is an over-kill.

winter_blue3• 13 years ago

Has anyone here used Haskell in a production environment?

I want a language that is small, clean, and can provide a lot of static guarantees. I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small. C++ and Scala are large. You know what I mean..

Now, static typing is just one kind of static assertion[1] I'd like to have. Side effect isolation (i.e. language-enforced purity) would be another feature I'd like to see become common. For example, the D programming language has a "pure" keyword that lets you mark a function as side-effect free. (In Haskell, all function are pure by default, and you escape the confines of purity via monads.)

I'd like to do research into (inventing) other forms of static assertions. One thing that's been on my mind lately, has been static "complexity assertion" for programs. I don't know if this even possible, but it would be nice to be able to ascertain before running a program, certain time & space complexity bounds on it. This would perhaps require us to drop the programming language itself to some level "slightly below" Turing machines -- but this in itself could be achieved via a keyword like D's "pure" or something more elegant. (Note: my point is not that we're going to make the entire language non-Turing complete -- but rather that we'll have subsets of the language that are not, and this reduction of power would/could bring with it a greater possibility for statically asserting stuff.)

[1] FYI I made this term up. Let me know if there's something better that describes this.

eranation2• 13 years ago

For an academic language (which I assume is factually true as it was developed in a university) it is one of the most developer friendly academic languages out there IMHO, I rather write Scala than Java in terms of complexity, and if I would need to rewrite a Ruby code base, I would give it a shot in Scala before trying Go (feels more natural to me, they have way more similarities than I thought) I have the parts I need from Scala easily fitting in my head, which is perhaps just a subset, but enough for me to be very expressive in it.

I think one of Scala's biggest issues is people being turned off by what sometimes feels as functional zealotry[0]. But people perhaps are not aware that it is also a great imperative language, you get no compiler warnings if you use a var or a mutable collection. I find it very close to Ruby actually and I think Ruby developers will feel at home with it [1]

The other thing that holds it back IMHO is the compile time. (But this is improving from version to version)

[0] https://twitter.com/wycats/status/372107196617592832 [1] https://twitter.com/yukihiro_matz/status/372181477909200896

winter_blue3• 13 years ago

The other thing that holds it back IMHO is the compile time.

Now that you mention compile time -- one of the biggest things that the Go designers cared about was compile-time. Go touts it as one of its major pros; and I do agree for personal experience that compile time matters.

You can often cut down compile-time by making "run-time compromises". For instance, with C++ code, dyn-linking rather statically linking everything can speed up things significantly. This is because with massive C++ codebases, when you change a couple of lines, rebuilding the relevant objects only takes a few seconds - but the static linking stage can take forever.

On memory constrained system (4GB) of RAM, I've seen a particular codebase that I've worked with take up to 28 minutes just to link. The same code on a machine with 8 gigs of RAM (just double) took less than 4 minutes to link. Due to the sheer number of objects that need to be linked, your system ends up thrashing (swapping pages out to disk).

That being said, I read somewhere that Go doesn't support incremental compilation. I don't if this is still true, but that's a major problem that needs to be fixed right away.

With interpreted languages, practically everything is done at run-time and you have no compilation stage -- but at a massive performance penalty. Tracing JITs do help though.

dragonwriter• 13 years ago

But from my experience, I think Scala is an Academic language.

Your complaints about Scala's size are more on point and oppose this; Scala is such a big language because it is designed to be an industrial language (academic languages tend to be small and focussed) specifically targetting the enterprise uses of Java.

Academic functional languages that aren't designed to provide an easy glidepath for users of a particular large imperative OO language and provide access to that industrial ecosystem tend to be smaller than Scala.

neya4• 13 years ago

Thanks for the correction. I probably meant industrial when I said academic.

ulisesrmzroche5• 13 years ago

For real? That's cray. I didn't know the syntax was so hard to internalize.

teddyh2• 13 years ago

For a while I thought you meant Seymour Cray, or one of the supercomputers he designed and built.

Was it so hard to type one letter in support of readability? Or is "cray" its own word now?

marincounty• 13 years ago

I think there should be a 500 page law. If you go over by one page, even if it's blank--the book is free?

noelwelsh• 13 years ago

I find your comment quite odd, as a web service is just about the most functional thing you can get -- it's just a function request => response as you note. I don't see where you'd need to make it "more functional."

pkinsky• 13 years ago

Another downside of Scala is its HUGE syntax. Processing strings? Here's a ten million ways to do it.. (a bit over-exaggerating). Oh and if you chose this way, then you should use this syntax. No, not that one, THIS one. Oh no, not that one, this variation of that one that looks like this.

On the other hand, Scala lets you deal with collections and Strings using the same enormous set of methods.

    "\"foo\"".drop(1).dropRight(1)

is just

    List('"', 'f', 'o', 'o', '"').drop(1).dropRight(1)

asdasf2• 13 years ago

When writing algorithms and so forth, but otherwise, you are forced to fallback to this imperative model which sucks

You don't need to fallback to imperative style. The fact that people write web apps in pure functional languages should make that obvious.

Once you go Go, you never go back.

That depends where you came from. I really tried to like go, but went running back to haskell. Go is just way too primitive.

cgag• 13 years ago

Yeah, I'd like to hear more about what kind of things make you fall back to imperative style.

rybosome4• 13 years ago

I've historically been pretty pro-Scala 'round these parts, so my response to this should be considered in that light. So, with that disclosure out of the way... =)

I have to admit, I don't agree with the assertion that the cognitive dissonance associated with programming in an imperative way versus a functional way is a major problem to Scala. I realize personal preference is a very big part of this, but there are many problems which are just easier to solve in a functional way versus an imperative way. Of course, the opposite holds true as well. This is the beauty of Scala; one can write performance-critical imperative code while exposing a functional interface; or, one can consume a fluent functional interface to produce imperative code.

Frankly, I guess I've become something of a functional zealot, so my problem with Go is that it's so stubbornly imperative. This is why I can't get behind Go, as much as I want to. I feel like it doesn't consider many of the lessons that have been learned about FP making life easier. Set operations (map, filter, reduce) are insanely common, yet doing them imperatively sucks to the point of discouraging them. Excessive mutability is difficult to reason about. Nobody expects the nil/null/none inquisition. We tend to forget about side effects. Without an extensible language, which requires truly first-class functions, you're at the language designer's mercy.

Hell, Scala probably isn't the be-all, end-all answer to all of this. I just don't think that a doggedly-imperative, non-composable, statement-oriented language is the future of programming "in the large", not when the past has shown us that we tend to produce buggy, unmaintainable software this way. I'm pragmatic enough to realize that pure FP isn't a solution, but I feel strongly that sticking to traditional imperative because it's familiar is a costly mistake.

I can't argue with your take on the syntax, though, since that's personal preference. =) If you have any thoughts on why you feel productive in Go, I'd love to hear them; as I've said, I've been really struggling with motivating myself to learn and enjoy it.

realrocker• 13 years ago

Have ever tried programming in Go?

Edit: Functional Programming in Go 1. http://stackoverflow.com/questions/4358031/functional-progra... 2. http://golang.org/doc/codewalk/functions/

caciquefun• 13 years ago

Maybe you would try nimrod language, it's similar to go but a bit more functional, and it has generics and the concurrence is managed using actors (also supports channel's) , and rust also is a good language for functional programmers trying to find a good system language...

Go language is so different to scala or Haskell because it follow the principle what a simple language is better than a complex one (the less powerful principle). The type system is a bit weak in go, probably one simplest type system ever, nimrod has a basic oop joining with algebraic data types and something similar to clojure multi methods, rust I believe has type classes..... So yes, I if you're happy writing functional code and using powerful languages maybe you will not totally happy with go language...

neya4• 13 years ago

I agree with everything you say. I think functional vs imperative is a matter of taste, though. Even I tend to incline towards Functional Programming (FP) in most scenarios, but in some cases imperative languages are 'good enough'.

And since my background used to be client-side Javascript mainly (I was a front-end designer), I find it fairly confusing to switch myself between the two mindsets (FP and IP), which like you said is something more of a personal preference.

And like I said, I still love Scala, for the reasons you've cited. But then again, there are a couple of reasons which I have in mind for going with Go.

The main problem with Scala for me:

1) Difficult to find good Scala engineers. IF you find one, you still need to figure out if he's comfortable with the Functional or Imperative model.

2) Syntax:

This is an example from one of my previous commenters (dxbydt, thank you) on my thread:

    scala> def test1 = println ("hello world")
    scala> def test2(f: =>Unit) = println ("hello world")
    scala> def test3(f:Unit) = println ("hello world")
    scala> test1
    hello world
    scala> test2()
    hello world
    scala> test3()
    hello world
    scala> val t = test2 _
    scala> t apply Unit
    hello world
    scala> t()
    hello world
    scala> t(())
    hello world

It is mostly a personal preference, but I still feel too many ways to do one thing is a recipe for disaster.

With all that said, I know of people writing a Scala program and not touching it for a year or two unless they wanted to update their OS on their servers.

djhworld• 13 years ago

I liked Scala, but it's just the sheer weight of it that puts me off using it in my personal projects, and it still comes with JVM baggage.

What it needs is some leadership. A few weeks ago Rob Pike and Andrew Gerrand (developers of Go) appeared on The Changelog podcast, which I recommend listening to, and one thing that Rob Pike said really intrigued me. He said that a policy they have when designing Go is to ensure that all members of the core team agree on any design decision before it gets put into the language. If one of them disagrees it gets tossed.

That's probably one of the main reasons why Go is such an "opinionated" language and very small in nature. This probably infuriates some people as their favourite feature from other languages is missing in Go, but it keeps the language where it is and steers it on a path that the designers are maintaining complete control of.

islon• 13 years ago

I had more or less the same experience with Scala but I just jumped all the all way to functional programming and started using Clojure, never looked back =)

txutxu• 13 years ago

I wish we could know what happens "after 12 years in production" (just 10 more).

Update:

Sorry if someone did feel offended (the negative voting), I said it with my best and more constructive intention.

In my opinion, the problem is not in the content of my comment. Well, maybe, if someone understands it as: "oh, can't argue against that, is attacking the language" instead of, "let run your imagination to 2023".

Have a nice day/night.

ulisesrmzroche5• 13 years ago

Anyone got a good tutorial on Go? I'm interested in fiddling around with it.

BarkMore3• 13 years ago

http://tour.golang.org/#1

ulisesrmzroche5• 13 years ago

Sweet, thanks Barkmore!

genwin• 13 years ago

Beyond the online tutorials and e-books, I've found the book Programming in Go (by Mark Summerfield) to be an excellent reference.

ulisesrmzroche5• 13 years ago

Just kindled that up thanks dude. I'm going to see what what all the buzz is about.

pjbringer• 13 years ago

It's a shame they have actually converted a real system, and they rely on the language benchmark to make an argument about performance.

That said, not having run into a problem is a worthwhile feedback.

netcraft• 13 years ago

on an unrelated (to golang) note, does anyone have any experience they would like to share about iron.io? especially it vs rabbitmq or amazon sqs?

paddyforan3• 13 years ago

We're friendly. Drop by get.iron.io/chat and we'll answer any and all questions you may have. :)

carimura5• 13 years ago

that too.

carimura5• 13 years ago

[Disclaimer/Warning I work there and this is about Iron.]

Vs RabbitMQ: - Native cloud service over HTTP transport - Clean easy API - Scales to unlimited queues/clients - Push queues can have URL endpoints as subscribers - Highly available (our #1 priority is to keep it running at all times) - Nice UI to manage queues, stats, rate, etc. - IronWorker integration (workers as a service)

Vs SQS: - Fast, clean API - FIFO - One time delivery - Multi-cloud - Push queues / pubsub / fanout as first class feature - IronWorker integration (workers as a service)

Best way is to just try it out. It's already one of the leading cloud MQ's out there and we have a lot of big plans for IronMQ to make it the safest "bet your business" cloud message queue available.

rabbitmq• 13 years ago

RabbitMQ supports HTTP and has a clean easy API. Scales in lots of ways. Supports very high throughput on a single cheap AMI. Has awesome GUI and UI. Etc. YMMV.

anfleene• 13 years ago

I've used IronMq in production for about 6 months. It's easy to use but the uptime is terrible http://status.iron.io/history so if the messages are time sensitive I wouldn't recommend it. You should also queue the messages locally to ensure they end up in IronMq at all.

carimura5• 13 years ago

Sorry for your issues anfleene. Reliability is our top top priority. FWIW our uptime has been 99.9% over the past year - and this is far from where we want it to be.

We now also offer isolated clustering for production level highly available applications that need "4 nines" availability.

toqueteos3• 13 years ago

Not so relevant but for any of you who prefer Rust to Go and haven't tried Go, don't do it.

Go's std, visibility by case and gofmt, among other things will make you cry for using Rust.

I really hope Rust get's better with time and it really focuses on being developer friendly not just a bag of nice features.

eevee• 13 years ago

Maybe we should do less crying and more contributing. Google has a bit more dev muscle to throw at projects than Mozilla, so community involvement is far more critical to Rust's health.

wtf_is_up2• 13 years ago

The Go team at Google consists of a handful of people: http://thechangelog.com/100/

pcwalton4• 13 years ago

Not so relevant

Then why post?

axaxs• 13 years ago

I, as a user interested in both, did find value in the comment regardless of his/her intentions. This comes off as a 'shut up' when really, it could be a good opportunity to look at what Go does right for implementation in Rust, no?

jff• 13 years ago

Because Go is getting more press than Rust and that is really, really hard for some people to handle.

dodyg• 13 years ago

This is awesome. I much prefer this to "we rewrite some stuff with Go" articles.

stephenitis• 13 years ago

I would love to see codeacademy, codeschool, treehouse, and the online course community to jump on creating go curriculum.

enneff2• 13 years ago

http://tour.golang.org/

knodi• 13 years ago

Being using go for a year now. Really enjoying using it.

zurn• 13 years ago

Interesting that Go lost so heavily to Ruby on amount of code (~ 3x more on average.)

Go After 2 Years in Production

Related Stories