The Reliability of Go | Hacker News Reader

The Reliability of Go

andrewwdeane.blogspot.com

150 pointsexch139 comments

I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement.

The second paragraph reads like: replacing a relational DB with a (in memory?) key value store resulted in more throughput. He implemented it in Go, but he could have implemented it in any other language.

What I want to know is how he convinced management to use Go? Where did he find the programmers? I work in a similar environment and I don't see my firm adopting Go any time soon, although I wished they had as I'm a big fan of Go and believe it has a place especially server side processes (e.g. algo trading, market data feeds) where concurrent connections are prevalent.

> He implemented it in Go, but he could have implemented it in any other language

I assume he used Go's concurrency features, although he could have articulated on that.

> Where did he find the programmers

I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.

>I assume he used Go's concurrency features, although he could have articulated on that.

I've yet to find a good explanation of what is so special about them, why I'd choose it over F# or C# Async/Await.

In the case of pinging servers, I would have prefered to use a 'cheaper' to develop language, which has a boatload of libraries that are widely used.

Anyone got any links or stories about why you would want to use Go for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.

This is a good overview of Go concurrency:

http://www.slideshare.net/jgrahamc/go-oncurrency

As a Java developer I personally don't find it that impressive compared to something like the LMAX Disruptor or even Vert.x but I can appreciate that it is simple and that always counts for a lot.

As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.

Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.

Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.

I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit).

[1] http://blog.parse.com/2013/01/29/whats-so-great-about-javasc...

[2] http://www.codeproject.com/Articles/535635/Async-Await-and-t...

Thanks for replying.

But I'm not trying to say that async/await are superior to the actor paradigm (which is what my understanding Go subroutine, don't call em threads things are).

Just that I would have hazarded a guess for pinging a bunch of servers, the TPL stuff is a better choice, than actor?

I feel there is a lot of buzz around Go, though I'm not seeing why. I guess my only option is to find something suitable enough for it, and give it whirl. But of course I am lazy, so trying to find someone elses suitable experiences would be great.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Probably that would be the most interesting part of the story...

Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution.

There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstrate the improvements.

You build trust in the technology and work flow before moving on to larger more critical/risky projects.

(Andy is very much missed by his former colleagues)

Would be interesting to hear the details on management's side of the story: 'This guy re-wrote all our stuff in the new hotness then left the company'

Well what sort of story are you expecting to hear? Without going into detail it's not really that exciting.

There was a requirement for high volume/through put messaging component in our infrastructure.

That technological requirement (along with non functional requirements e.g. development time/costs) was more than adequately met by a program(s) written by a team member written in Go. Was it an opportunity to further explore the "new hotness" that is/was Go…absolutely but the solution could have been implemented in one of the other supported technologies C/C++/Java with appropriate advantages/disadvantages associated with each. It will stay in use for as long as it provides the best solution, if that changes a more appropriate solution will be investigated.

> 'This guy re-wrote all our stuff in the new hotness then left the company'

The Go dataStore is "a" component within a large infrastructure, it is supportable by more than one member of the development team (a core requirement when deploying any new technology to production).

I'll also note that before Andy left, being a professional and thoughtful colleague, he put a lot of effort into ensuring appropriate training and knowledge was given to team members that had not been part of the deployment.

As Andy is a very well regarded former colleague, it helps that we could easily get in touch for a query, even when we're out for a beer or five* :)

(*five might not be a maximum in that scenario)

Glad to hear it worked out well; there are many times where it doesn't. Thanks for taking the time to share an overview.

BTW, by component you mean program, right?

Yes, or a larger collection of programs/scripts/resources.

This sounds reasonable and certainly worthwhile if it really does result in adoption in "larger more critical/risky projects."

If the result was just one component out of many written in Go then the reality is it was a side-experiment and/or a poor management decision. I do hope that is not the case.

"Andy is very much missed by his former colleagues" hopefully for good reasons, not because they left him with another language and toolchain to maintain :)

Go has the advantage of being "Google's language." This may sound stupid, but this credibility-by-association is a very important factor for a non-technical manager.

Go puts the Go in Google.

Without Go, you'd only ogle Google.

No trivial feat? It seems to me that managers would be more willing to gamble than a typical programmer. But I still agree with you. I'd like to see a post about how someone switched to go from cobol.

I got my boss to let me try out Go after proving that I could solve problems that we were currently struggling with.

I also agree that you don't need to hire new devs. I've taken two programmers who've never used Go (mostly university languages) and taught them to be productive in a matter of days. Both consider Go to be one of their favorite languages.

On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. As exciting as Go is it sounds like replacing the old script with a sufficiently concurrent and well-written application in any language should have worked well.

More details would be really helpful. Also the author seems to be responding to a question of reliability by talking about performance which is not the same thing.

I doubt Andy would disagree with you, it's no slight or bad commentary against Python (Andy was the cheerleader for introducing Python into our infrastructure where it is blossoming nicely).

With sufficient development time Andy could have introduced more concurrency and optimisation into the Python monitoring component (I'm thinking Gevent might have been a nice fit)...but without introducing additional frameworks or libraries Go had these features as a core component.

The offhand performance comment aside, Andy was noting that a component written in Go is depended on to handle VERY high volumes of message throughput in a financial services firm.

While no proof of reliability it is merely anecdotal support that Go is being used in production environments.

>On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language.

"Inadequate concurrency features" IS an inherent problem with Python The Language.

(Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").

It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?

Yes, unless your code is very I/O bound using threads won't speed up your Python application

Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?

> Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't?

It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time).

As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.

It's funny how people who learn evented programming in scripting languages like Python feel like they've discovered some new hidden concept. No competent systems developer fails to understand what select() does. Suggesting that the author was't "acquainted" with select says more about this comment than about the author of the post it comments on.

>It stalls in Python because the author is not acquainted with non-blocking system programming

Citation needed.

How about "he is acquainted but can't be bothered to use it retrofitted to a language not tailor made for it"?

>As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.

And why you think you're any better than him based on a short blog post (and especially one in which he does not delve into why the Python version was slower or says it would be impossible to make it faster, just mentions it's speed in passing), is beyond me.

Maybe cut down the snark?

Without actually be able to see either script, I would assume that his Go implementation took advantage of some of Go's more natural concurrency features.

The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.

A completely different implementation would seem likely to have been made.

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place nice & tidy).

Folks - Go ain't a fad, it's a great language if your problem domain benefits from concurrency AND if you need to deploy to multiple locations and love being able to just drop a single binary and walk away.

How good is Go, as a replacement for Java?

What do you mean "replacement for Java"? It's a completely different language:

* no classes (only structs and embedding)

* no VM, only a run-time (cross-compiling is trivial though)

* hardly anything is an object

* no exceptions

* concurrent by design

It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions.

I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well.

Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.

But the runtime performance is probably closer to Java than Python...

Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages.

It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.

>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway.

Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.

If Eclipse is evidence that Java is good at GUIs, I shudder to think what the output of something bad at them must be like to use.

edit: to give you a constructive response: Eclipse is an excellent illustration of how godawful Java is at GUIs. It chugs horribly on even high end hardware because of Java's interminable GC pauses getting in the way of interactive response times. It looks native nowhere, and somehow contrives to feel even more alien than it looks. It manifests platform dependent UI bugs, completely defeating every last shred of its claimed "write a GUI once, deploy it anywhere" advantages.

If you want to make the argument that Java is good for GUI's, feel free, but you just picked the two worst examples I could possibly think of. As a Mac user, the UI for Eclipse is such a huge turn-off that it soured me on Java as a whole (back before I really knew anything about Java; today, there's plenty of other stuff to dislike besides the GUI toolkit). And Minecraft? That's not a UI, that's an OpenGL game. Nothing about the custom OpenGL-based UI it presents to users says anything about Java, or has any bearing on other Java apps you might write.

Ok, you have a good point. I'll instead list Open Office and LibreOffice and Symphony and Lotus Notes. Those are hugely complex GUI's and work as good as or better than anything proprietary out there in the same class pf products.

Actually, LibreOffice is trying to get rid of the Java dependency for a while now[1].

[1]: http://www.developer.com/open/libreoffice-3.3-frees-open-sou...

Interesting, it sounds like LibreOffice is becoming a mish-mash of technologies (search this page for Java):

http://www.libreoffice.org/download/4-0-new-features-and-fix...

> * no VM, only a run-time (cross-compiling is trivial though)

There are native code compilers available for Java.

> * concurrent by design

Java was there first

"concurrent by design" != "can be concurrent / has threads"

Not all Java implementations map language threads to OS threads.

The implementations that use green threads are no different than go-routines, which were seen for the first time in Modula-2 just as information.

What I was implying is that "built for concurrency" isn't just about threads (or goroutines). It's about communication between concurrent routines and shared state. Go is designed to have less coordination in concurrency by encouraging communication via channels instead of shared state.

The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.

I don't think Go could have existed in 1996. It feels like a reaction to Java, in some sense. And even if it was built, exactly as it is now, in 1996, it probably would have gone no where.

"It doesn't even have object inheritance! And what do we need all these concurrency things for? Windows has only had preemptive multitasking for a year, and multi-core is still a decade away."

Your second paragraph quotes a fictitious someone in 1996, right?

Haha, yes, thanks. I added quotes.

Oberon and Oberon-2 were available in 1991, which Go takes the method syntax and package concepts from.

GC enabled system programming languages, which failed most likely due to the Pascal syntax.

Yeah not enough Object for 96, but still it feels like an old language to me.

Well, Limbo existed in 1995, but it got nowhere…

Java, more specifically the JVM, was a a godsend. Develop everything in your Windows 98, then upload it to some big-iron Sun server, knowing it will run, without cross-compilation headaches.

And yes, at first, it was dog-slow, but it was the kind of dog that you could drag behind the barn when things got out of hand. Apache+PHP or (yuck) classic ASP would just bring the whole machine down on a bad day. This isn't much of an issue today, because first other languages/runtimes improved, second we have more robust monitors in place, and third the "machine" is more often already virtual and more easily recyclable.

IOW, How reusable do you feel the stuff you write in Go is?

I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google).

All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see technologists and developers go on and on about how wonderful and better these corporate languages are.

With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.

Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind.

I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language.

There is a reason go compilers are C and C++.

I too am upset at the prospect of annoying little text ads popping up in my source code. DOWN WITH GOLANG.

heh.. classic response

> I too am upset at the prospect of annoying little text ads popping up in my source code.

You are not using the correct term. In Web 2.0, these are not called "annoying", but "unobtrusive".

Go is completely open source. The primary devs just happen to work at Google. That is all.

If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.

Plus there exists not one, but two implementations that fully conform to the spec. So you're not even bound to one specific compiler implementation.

Soon to be three, llgo is getting closer!

> If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet.

I'm generalizing, but given "management" lack of technical understanding, and the (general) knowledge that Google shuts down services left right and center, then I'm not sure this is necessarily perceived as such a safe, long-term bet...

But I wouldn't have thought that the choice of language is necessarily something that management typically cares about.

Go is open source: http://golang.org/LICENSE

I never mentioned closed source or open source in my comment. I mentioned "corporate" languages. Go is Google's just as much as .Net is Microsoft's.

A major difference (re dependency on the producer) is that go is a language while .net is a platform. It would be (relatively) easy for users of golang to step away from Google if they became a problem while retaining their codebases. Moving from MS's platform is harder (mono is out there, but is it sufficiently complete at this point?).

I don't see the big deal. What the heck are you afraid of? Is Google going to put user tracking into the Go spec? Go has two compilers, both of which are open source and open to external contributions.

The irony of your statement is that Go is open source, and C# is an ISO standard. Those were proactive choices by the companies, and they should really be considered the leading stewards of the language- but not the owners.

1. I never mentioned closed source or open source in my comment.

2. Only a portion of C# is standardized.

"""The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims. However, Microsoft uses C# and the CLI in its Base Class Library (BCL) that is the foundation of its proprietary .NET framework, and which provides a variety of non-standardized classes (extended I/O, GUI, Web services, etc.). Some cases where Microsoft patents apply to standards used in the .NET framework are documented by Microsoft and the applicable patents are available on either RAND terms or through Microsoft's Open Specification Promise that releases patent rights to the public,[38] but there is some concern and debate as to whether there are additional aspects patented by Microsoft that are not covered, which may deter independent implementations of the full framework."""

source - http://en.wikipedia.org/wiki/C_Sharp_%28programming_language...

Only a portion of C# is standardized.

And none of Python, Perl or Ruby are.

Ruby has an ISO standard.

So it does, I wasn't aware. Though, is the version submitted still supported by any modern interpreter?

>I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google).

The world begs to differ.

For one, Java and the JVM have a huge ecosystem, and nobody's complaining. And .NET is huge on Windows, and nobody's complaining their either. Actually, they rather like it that MS is in charge. [For the conversational english challenged, "nobody" means "a few outliers don't count"].

Oh, and Go is open source with a large community.

>All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Which is beside the point. Almost all compilers and JITs are written in C/C++. So what?

>With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.

With those you have SOME freedoms. With .NET and Java you have OTHER freedoms. E.g I have the freedom to take advantage of a huge collection of libraries, with top-notch commercial support for a lot of them, and use them in around 4-5 top notch languages like Clojure, Scala, JRuby etc, with the most performant JIT in town. All the other options you mention don't give me THAT freedom.

>There is a reason go compilers are C and C++.

Portability, familiarity and low-levelness?

Also, you DO know that C (and IIRC C++) were once created and controlled by a corporation (AT & T) too, right?

But for those who choose languages for pragmatic rather than cultural (religious) reasons, Golang is a fairly good egg. Liberally licensed (BSD Style + Patent Grant). Focused on the problems of modern large scale systems.

With modern message passing, great build / deploy tooling, an opinionated structure and formatting standard -- it really makes putting together LARGE system with many moving pieces much easier.

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google).

.NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations).

> All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Layers of abstraction are there for convenience otherwise we'd also shortcut C++, C and even assembly and would be writing everything in machine code.

> Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind.

I actually do get the Google paranoia. It's why I cut down on my dependence on them as well. But Go doesn't up-sell Google's services like Chome (which isn't an OS by the way - you must be thinking of ChromeOS), Android, Gmail and so on. And let's be honest, other popular languages have born out from businesses: C from AT&T, Borland lead the charge with Pascal, Microsoft had their version of BASIC bundled with many of the most popular micro PC's of the 80's. Need I go on?

> There is a reason go compilers are C and C++.

Yes, but it's not the reason you're thinking of. The problem was one of the chicken and the egg. It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. C had the same problem when it was young too.

> I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language.

The reason people don't agree with you is because: a) C++ would be overkill for a web framework (which is one popular application) and b) half your points are based on misinformation.

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language.

Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

I would say it is.

Sure you will need to use Assembly for a few runtime parts, but C is no different, if you look at ISO/ANSI C without language extensions.

Not quite yet, it still builds a small bootstrapping tool with C

I would have thought so (but I'm far from an expert on such matters). However you'd still have the issue of users wanting to download Go's build tools from source (as not everyone likes to install pre-compiled binaries on their systems) and not being able to compile the compiler.

Granted gcc could now be used. But then you're back to using a compiler built in C++ to build Go code.

Considering people are writing web servers and all sorts of other things in it, I'm sure it's suitable for writing a compiler. Technically all you really need is logic, some data structures, and low level file I/O. If you're going to spit out asm and let someone else deal with that, then all you need is normal file I/O.

It seems like Go is trying to capitalize on the momentum they have. Improvements to the language are still coming quickly. I'd be surprised if a self-hosting compiler isn't among their goals, but writing a new compiler without slowing down language progress in the current reference compiler is not easy.

Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used and represents the best test that you can have for a programming language.

Also, you would want a compiler written in a high-level language (versus C) precisely because you want to speed up the development of new features.

Yes, it's more complicated, but it doesn't really have much in the way of demands on the language used for implementation. It may royally suck to do, but you can write a compiler with nothing more than logic, data structures, and file I/O. That was my point.

> Also, you would want a compiler written in a high-level language (versus C) precisely because you want to speed up the development of new features.

Sure, but you'll need to pull people away to do that and will either have to stop your C-based compiler effort or resign yourself to prolonging the Go-based compiler development by playing catchup. In the meantime you aren't really as productive as you could have been. Go seems like it's about to slow down on language-level changes, which is the perfect time to start working on a Go-based compiler.

Actually a language compiler is more complicated than a web server when speaking about the data-structures and the algorithms used

That would depend on how much of the web environment you want to reproduce and what language we're talking about. The original Oberon fit into some 5500 lines of code, if I'm not mistaken. That's sort of smaller than Apache httpd. It's even smaller than nginx and lighttpd. And we're still talking about pretty weak languages, have you seen some of the self-hosting metacompiler stuff? (META-II, TREE-META, OMeta etc.) Don't forget that the design of the reference Go implementation is actually pretty close to the Oberon tradition of making things simple.

In terms of lines of code, I'm sure that things like OMeta are pretty small, but that doesn't mean the implementation is not complicated. And I'm not that familiar with the *Meta stuff, but AFAIK that stuff is just the frontend, whereas on the backend (the logic for generating the machine code / bytecode) things can get messy and complicated.

Also, I'm sure that the Go implementation is right now simple, but every mainstream compiler quickly evolves towards doing more and more AOT optimizations, like for performance or for better error messages. Again, performance optimizations can get really complicated and messy.

It is possible to write a Go compiler in Go.

But the current compiler works, has a lot of testing and production use and isn't broken in any serious way. For a compiler, I'm not sure Go offers enough benefits over C/C++ to make it worth throwing away the existing code base and rewriting.

See https://github.com/axw/llgo for a 3rd party implementation based on LLVM that's fairly far along.

I think your point is a little incoherent, since C# is an ISO standard, while Python, Perl and Ruby aren't, nor do they have "lots of free compilers available".

Personally, I don't use Gmail, Android, Chrome or ChromeOS, for real reasons pertaining to data ownership, privacy and maintenance of services, but I see no reason not to use their fully BSD licensed tools that I can run on my own hardware. If Golang 2.0 suddenly prevents you from making HTTP requests to any server outside the Google networks I'll be pretty pissed, but I find that pretty unlikely.

Only part of C# is standardized. The majority of it is not.

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language...

There are several free Python and Ruby interpreters and they are not corporate controlled. Ruby does have an ISO standard (ISO/IEC 30170:2012).

There aren't "several" free Python interpreters. PyPy is still in an early stage and Jython still doesn't have a stable version supporting Python 2.7.

Golang has two different implementations (6/8g and gccgo), one of which part of the GNU project, so it's not particularly behind.

dont forget llgo!

> PyPy is still in an early stage

That's unfair.

If they're as nasty as you say... please don't look at the major contributors to your OSS toolchain.

You'll find the $EVIL_COMPANY quite well represented there too.

> With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.

Unfortunately, there is an important language design space that is not covered by C, C++, Python, Ruby, and Perl, which is that of statically typed, imperative languages with automatic memory management.

C/C++ give you static typing, but not automatic memory management; Python, Ruby, and Perl give you automatic memory management, but not static typing.

And unfortunately, while there are quite a few languages with these features, only few have the critical mass, long term support, and infrastructure to justify investing in them for serious development.

Oberon, Oberon-2, Component Pascal, Active Oberon, Modula-3, ...

Is this agreement or disagreement? Because all these languages don't have high critical mass, long term support, or a great ecosystem.

Sorry, I missed your comment

> And unfortunately, while there are quite a few languages with these features, only few have the critical mass, long term support, and infrastructure to justify investing in them for serious development.

So I guess I agree with you.

I started coding in 1986, on those days C was just another language and OS were written in Assembly, PL/I, Pascal, Modula-2 and probably many others we never heard of.

I always used C only when required to do so, hoping a stronger type language would take its place. And jumped into C++ as a better C as soon I discovered the language in 1992, but given its C roots many problems still persist nonetheless.

The problem is that a language to gain critical mass needs a corporation that pushes it into the mainstream, or a framework/library that makes developers want to use the language.

sounds like rust

C and C++ are corporate languages as well, ask AT&T.

All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Both of which originated in AT&T Bell Labs.

Not quite true.

Microsoft has an undue amount of influence over both C and C++ thanks to the Windows platform and their questionable lack of full support for the relevant language standards.

Ultimately, what controls a language is who controls the market and who employs most of the people implementing the most popular compilers/interpreters for it.

The only reason C++ lives on is because platform holders have been willing to support it; and those platform holders are large corporations.

All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Technically, if I'm not mistaken, Go is (currently!) implemented in Plan 9 C, which is not the same thing as ISO C.

Also, Go is very different from .NET and Java. For starters, it was published in source pretty soon after it had been announced. You have your freedom right there.

I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC)

So yes, if you have control over your environment it may be a better choice

But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc

Heck, even for Python 2 (not to mention P3) this is an issue sometimes

Every compiler has bugs. All of them, even ICC, xlC, and other heavyweight ones. The fact that Go has a bug in the GC on a 32-bit machine is hardly surprising.

http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For...

No need to split hairs.

Go had an easy to run into and not obvious to fix bug on 32bit. That's a bigger problem than most gcc/ICC/whatever bugs, which tend to be happen in obscure corner cases (because the most obvious bugs are long gone).

IIRC, Go tries to allocate a contiguous portion of virtual memory. This isn't a problem in 64-bit, because the addressable space is so big, but a 32-bit system that has been running for a while may have enough memory fragmentation that you can't allocate a large enough block.

I have to agree about libraries. You don't realize how great it is to have finely-tuned JDBC drivers for every database on Earth until you can't use them.

This was mostly fixed in yesterday's 1.1 release: https://code.google.com/p/go/issues/detail?id=909

Why, oh why, would anyone be running x86 hardware in this Year of Our Lord Two Thousand and Thirteen? It's been what, 10 fucking years that we've had AMD64 now, you can get free 64-bit systems from the curbside, just toss that goddamn PIII and get with the 21st century. Maybe then people can stop posting "Well, Go on 386 architecture has bugs, so don't use it for anything."

Intel fuses off x86-64 on some chips it sells for reasons of market segmentation.

They have stopped doing this for quite some time iirc.

still a stupid move on their behalf (as is the market segmentation of AES-ni stuff)

Small VPS instances with little RAM available.

Yep. Coupled with the fact that 32-bit applications can still marginally outperform equivalent 64-bit applications, those who have little RAM/CPU are still recommended to choose 32-bit over 64-bit.

If I had been at that conference, I would have asked the same question.

Thanks for the data point (Yes, fine for production AFAYCT).

What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness.

Does Go leave just a coredump ?

One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of what the threads are doing at the point of failure.

Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault.

Go programs can panic but that doesn't produce a core dump, only a stacktrace.

I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization.

For example, these articles allude to possible memory corruption:

http://golang.org/doc/articles/race_detector.html "memory corruption"

http://golang.org/doc/faq#atomic_maps

http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."

You are correct, I was presenting a simplified view.

While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.

Well Java doesn't generally segfault either... until you start referencing external libraries ( freetype.dll , serial_comms.dll, swt.lib )

I presume Go ( CGO ) will have to deal with segfaults too, and I'd like to understand what it does.

As I said, this is a property of the system.

The system can be configured to do anything, don't core dump, core dump but overwrite any previous core dump, core dump in some special directory taking care not to overwrite anything, etc[1]. Of course, a process can ask for special treatment, but Go binaries are no different than default C binaries.

[1] http://man7.org/linux/man-pages/man5/core.5.html

As a practical example to 4ad's answer, here is the result of NULL-pointer dereference on the C code on my system (Arch Linux 3.9.2-1-ARCH). It does yield a SEGFAULT:

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

Thanks exch, that's really decent of you to construct an example.

I wonder that if there are multiple threads / goroutines are their callchains also printed ?

It seems it doesn't go into a lot of detail as to the call-chain for each running goroutine, but this example may just not be very suitable to properly test it. Either way, here is the same deal with a bunch of running goroutines.

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

Go doesn't segfault. If a Go program panics it prints stack traces of all goroutines (including the information which goroutine caused the panic) and then exits.

Somewhat off-topic but are there any data on the penetration of Go outside Google, a few other companies [1] and weekend hack projects on Github? Thanks to its unfortunate name, even searching for Go developer positions is challenging [2].

[1] http://go-lang.cat-v.org/organizations-using-go

[2] http://www.indeed.com/jobs?q=go+developer

Use the keyword 'golang' instead. :)

This could have been a better name in my opinion. One should stay away from frequently used English words.

Maybe they wanted the name to symbolize the syntactical terseness of the language, and every other two letter name had already been taken by unix utilities.

List of organizations that use Go: https://code.google.com/p/go-wiki/wiki/GoUsers

"Excellent tooling"; from the article.

What does he mean? I've searched the Go websites but it seems all Google gives you is the Go compiler and a tour.

He is referring to the `go` command, which is a front end to all of go's build tools.

http://golang.org/cmd/go/

go doc, go fmt, go fix, go vet, go build, go run, go test, go get, go install, ... and present!

The go command does more than just compile. http://golang.org/doc/cmd

Various go projects/tools are listed here http://code.google.com/p/go-wiki/wiki/Projects

first I saw go I thought meh but with so many people saying good things about it makes go inevitably more interesting day after day. however I just feel like it's going to be like mongo. when it first got popular, people all moved to mongo as it miraculously solving all the problems. same thing happening with go now and after sudden disappear of all the mongo evangelists, this makes me doubtful about go obviously.

IMO, people like hype, and a lot of the time, they are not aware of what better alternatives exist. If Go did not have Google or Ken or Pike as names behind it, do you think it would have gone anywhere? It doesn't really offer anything special compared to more expressive and safer languages like Scala and Rust for instance.

You can see it right here in the comments: someone said that Go is a memory safe language. It is not any more safer than Java is in that regard. We need languages that are safer than Java and Go.

What happens if Google decides to send Go the way of the RSS reader, the SMS search, and the dinosaur?

Nothing, it's not a service. The code is already out there along with the documentation and language spec. The worst they can do is:

1. Cancel their future contributions.

2. Create a closed source fork (is this feasible with the license if they don't control what others have contributed?)

In the worst case, if there aren't enough go enthusiasts it goes the way of other niche languages. Since the supporters seem to be active enough, I doubt that'll happen.

Reply on news.ycombinator.com