Hacker News Reader

Comment by Jabbles | Hacker News Reader

Yes.

The speed of development is far better than any other language I've experienced. I use it as a replacement for C++ and Bash, a statement I don't think you could make about any other language. Apart from the lowest-level kernel work and the highest-performance code, I think Go will become the NBL. Even on the subject of performance, Go is improving quickly, and if you're using it as a replacement for, say Python, your performance will be substantially improved anyway.

Its simplicity is astonishing. Very few things will surprise you whilst coding, although a few topics take a while to learn. I know many hackers try to work in accordance with the phrase "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.". I cannot think of anything Go has that it doesn't need. Not even goto :P

http://www.quotationspage.com/quote/26979.html http://golang.org/ref/spec#Goto_statements

View on HN

> The speed of development is far better than any other language I've experienced.

No, it isn't. Here's the proof: someone has said exactly that about, and I'm really not kidding, every newly popular language over the last 20 years. They said it about Java. About Python. About Ruby, and CoffeeScript and Clojure and Haskell and...

Yet the Great Leap Forward in programming productivity hasn't arrived. And Go won't bring it either.

Go no doubt improves your speed of coding. And being a new and different toolbox it's more fun, so it makes your coding more engaging. You "feel" more productive. But your hard bugs are still hard. And your maintenance hassles are still hassles. And your bad designs are still bad. That stuff is what takes time, not banging out your code.

Programming languages can make the easy stuff easy. They can't fix our own stupidity.

(To be clear: I'm not saying Go is bad, it actually looks like a ton of fun to me, though I haven't had the chance to really kick the tires yet. But don't attribute to it properties it doesn't have.)

    > someone has said exactly that about, and I'm really not 
    > kidding, every newly popular language over the last 20 
    > years.

That's probably true, and I grok your point, but pretty much everyone who's using Go in a production environment cites speed of development among the major, top-N reasons they're using the language. Past a certain threshold, there's something there that can't be hand-waved away.

    > Programming languages can make the easy stuff easy. 
    > They can't fix our own stupidity.

One of the neat things about Go, in my opinion, is that it converts a lot of "hard stuff" to "easy stuff", especially in the domain of concurrency, simply by the nature of its idioms.

Sure, but again, recognize that your points are all the same stuff we've already heard. Moving from C++ to Java was like that (especially in the domain of debugging). Moving from PHP to Ruby was like that (especially in the domain of reuse). And these points were universally recognized by everyone writing Java or Ruby, and they weren't wrong.

And you aren't wrong. Go has made you more productive, and I don't argue with that. But how much of that is Go and how much of that is simply you becoming better after being tickled by your new toy?

Back the clock up to the '98 C++/PHP world, and you'll see all the same bad software. It's not that nothing has improved, but the improvements are mild. People "wrote code" really fast back then too, and that code was clean, and just like back then people spend most of their time evolving that now-much-less-clean code to work in new design domains. And that's the stuff that has barely changed at all.

So you're not saying that everyone was wrong when they claimed they were more productive in C++/Java/Scala than in C/C++/Java?

We're using modern languages to build things that were difficult/impossible in older languages. Sure, the 1998 PHP world looks primitive, and the actual code may be bad, but I think it was miles ahead of the 1988 COBOL world.

I would have thought that each language brought more suitable tools to the jobs at the time, and people were more productive. I feel more productive in Go now than I ever have. It's not a factor of 10, but it's noticeable. Yes it may be that it's new and I enjoy it so I'm more productive, but given the language's designers' rock-hard stance on introducing complexity, I am confident in a frustration-reduced experience in Go for the foreseeable future.

Also, if this increase in productivity is just due to learning a new language, I think that's as good a reason as any to learn it :)

'Performance' is not a bullet point. Please do not wave hands about 'performance' without thinking about the actual benefit in the actual domain you are programming in.

If you need to write fine-grained embedded, DSP or graphics code you are probably going to use a true low level language like C or C++ anyway, not a gc language.

If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck. By the time you have measured you can often find a targeted place to optimize with FFI or extension modules.

If you are using a language just because you think it is faster at everything, you are optimizing prematurely and in a somewhat naive way.

> If you are not working in a domain like that, you need to measure to even know whether the language is even a significant bottleneck.

Or, if one is confident that the project can be done in Go, and that existing performance measurements of alternatives are accurate and show much worse performance, and the alternatives aren't much easier to use anyway, use Go and don't look back. Why optimize with FFI or extension modules when one can scrap that idea at little expense?

As an analogy if I wanted a faster car I'd probably be better off switching cars than tweaking my existing car's engine.

To continue your car analogy, buying a Porche isn't going to make you go faster if the route you're optimizing is across Los Angeles in rush hour.

True! But the whole cross-state trip likely has plenty of open road.

A new car doesn't have the same learning curve as a new programming language. You can pretty much jump in any car and drive it.

Performance is a huge bullet point for me. A language such as Python or Ruby requires you to make considerations (writing performance-sensitive code by shelling out to a native C extension, for example) that don't crop up in a natively compiled language such as Go.

In fact, for performance-sensitive things the difference is often staggering, even for things that scripting languages were originally invented for, such as text processing. Performance-sensitive doesn't always mean "DSP or graphics code". If you want to process huge log files in Ruby, for example, you can start as many threads you like to attempt to parallelize it without getting anywhere because of the global interpreter lock, and will find yourself resorting to things like forking off child processes. Ruby would be a bad fit because it does not perform well. I often end up writing such processing code in Lua (using LuaJIT) because of the dramatic difference in performance.

One must always consider the domain, but performance is one important facet of Go: Go gives you high performance without sacrificing much of the expressiveness of dynamic languages such as Python and Ruby. (Conversely, C/C++ gives you high performance without the same expressiveness.) If Go had the same VM as Ruby I would probably never consider using it for anything, as I don't see any language-level benefits that outweigh the performance aspect.

Python, your performance will be substantially improved anyway

Except not really - if you are doing computation in Python you are probably using NumPy which in turn is using hand-tuned assembly language BLAS or whatever under the hood. And if not, you are probably I/O bound.

That's a small use case compared to the whole language. The statement you disagree with is more true than your anecdote about one library. On top of that, all the network I/O is automatically nonblocking.

His point is that it probably doesn't matter for performance whether you're building in Python or Go, since neither language can make the kernel handle socket buffers and network events faster. I/O-bound programs in either language will have poll/select/epoll/whatever at the top of their profile.

The main point is that for CPU bound tasks, other than those that use Numpy, the performance is still a dog with Python.

I threw in the comment about nonblocking I/O niceties as icing on the cake, but since we're on the topic it's worth mentioning that a language with these features built in is superior to one where it is either a tricky library or a monkey patch, referring to Twisted, Tornado, Gevent and Eventlet.

What? No it isn't. Go's concurrency support is fundamentally different than Python's idiomatic approach (event libraries). It's an apples/oranges comparison. If one approach is more performant than the other, I'd bet on the event library, since evented programs are more or less scheduled purely by I/O.

I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.

I'm pretty sure i/o bound go routines will use the very same kernel eventing mechanism. I looked into this recently, and you have to explicitly tell it to use more than one thread with http://golang.org/pkg/runtime/#GOMAXPROCS

Exactly.

In both goroutines and events, blocking IO will be parked waiting on a select (or similar device). In both, they implicitly context switch while blocking, meaning that processing ready IO might have to wait for other stuff to reach a scheduling point. Unlike events, goroutines can be processed on more than one underlying OS thread at once.

Advantage: goroutines.

It certainly is. Just look at the insanity of the nonblocking I/O experience in Python. It's confusing, divided, and results in duplicated work all the way down to the database driver level.

I'm not overselling it. I'm someone who's built an entire web framework around gevent and knows that having this functionality in the library is a massive weakness of Python.

In Python, we have monkey patching vs. an entirely new driver vs. just using blocking calls.

In Go, we just have nonblocking I/O because that's how it works.

Well, scipy/numpy is quite relevant in the Python ecosystem; it's not something you can ignore when talking about the language. Like Rails to Ruby, numpy is quite a big feature of Python.

It might be nice for a quick script or standalone program, but most decent size software projects need plenty of mature libraries to be of much use. Python and C have decades head start here.

Can Go make use of C or Python libraries? Or is that a crazy question?

(Part of Python's popularity is that it is such a great glue language)

It can call into C easily: http://golang.org/cmd/cgo/

I think Lua is still the most simple and easiest in this regard. And Lua is embeddable.

Everyone is striving for concurrency as a language feature but sometimes it seems like a solution looking for a problem. What is it that you _cannot_ do now that you must have concurrency in order to do? What specific real world problem is it that you cannot solve? What are the cost-savings you will achieve with concurrency?

Maybe concurrency is a matter of smart programming, not dummy-proof languages with concurrency "built-in"?

Concurrency seems to be Go's main selling point (along with fast compilation). But Go is not small, it's not embeddable and it can't leverage C functions with the same ease as Lua. With Lua you can extend apps written in C. With Go you are writing the same old C apps again in Go. All the Go libraries I've see so far are just libraries that exist in other languages to do the same old things we've been doing for years, rewritten in Go.

At least with Lua, creativity and expression is encouraged by letting people write their own libraries. All the existing C libraries don't have to be rewritten as Lua libraries. What a boring exercise that would be. All you need to do is understand how to interface with C functions and there's little you cannot do vis-a-vis existing C libraries to do the "usual things".

Just my opinion. Lua is an arbitrary example. It's the general concepts of simplicity, small size, extending applications, and leveraging existing C code of which I am a "fanboy". It just happens that Lua meets some of these criteria. Sorry if it offends anyone.

I've evaluated Lua for a number of use cases and even use it on my Ti NSpire calculator occasionally, but it has some horrible problems, particularly related to metatables and the concept of 1-based indexes. It also doesn't give us any advantages over other languages. LuaJIT is impressive I will say though.

However, Go's apparent concurrency focus is a bad assumption.

The problems that Go solves are simply: simplicity, synchronisation, thread scalability, time to market, modularity, testability, consistency, security and memory management.

All of those, you really can't do in C quickly and safely.

Go is a fixed C, with a fixed standard library that suits NOW, not 20-30 years ago. That's all it is and that should be applauded and praised. It also fixes the inevitable mountain of stuff you have to do to get something significant done in C and ignores the utter retarded complexity of C++ and Java.

Ultimately:

A single person can build something significant in Go in a week.

A single person cannot build something signficant in C in a week.

cgo is very easy. I've plugged SDL into it in a few minutes.

I agree with you mostly. Although you are comparing Go to a language with manual memory management, not another GC language, like Lua (sorry to keep using that example).

A question: What is your idea of "something significant"?

Go seems like an ideal language to quickly build servers. Am I missing something else?

Go has FFI hooks with "import C", outside of that I haven't found anything (though Go's way looks much simpler than typical FFI setups at first glance). No direct access to C / C++ libraries like D does, though that's probably a good thing.

There is Go support for SWIG: http://www.swig.org/Doc2.0/Go.html

Still, it is rarely used, building in pure Go is much nicer, because one of the great things about Go is building systems where you can understand all the pieces.

And if you want to understand what a Go lib does looking at the source is surprisingly informative. (This also addresses most of the complaints about documentation).

Well, I don't expect most programs to be re-written in Go, but I think in, say 10 years' time most new programs will be. By then Go's mature, fast libraries will be comparable to any of Python's (although C will have the kernel-level advantages still I think).

I think 24 months quoted in the article is optimistic...

Make Go code easily usable from Python (as C is) and the point will be completely moot. Why not do it?

Is already possible: https://bitbucket.org/binet/go-python

But is simpler to just write all your code in Go, Python code is not just slower, it is also less reliable and less maintainable.

What is substantially different from GO besides performance. It just always seemed like another boring OO language that is fast. I've not really been impressed with the programming languages created at google. None of them seem to be very innovative or solve anything new. I guess it stems from google's affection towards java and misusing python (not using any of it's more powerful features, so it the code basically looks like a prettier version of java).

Reply on news.ycombinator.com