Will Go be the new go-to programming language?
gigaom.com
gigaom.com
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
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.
> Programming languages can make the easy stuff easy.
> They can't fix our own stupidity.
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.
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 :)
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.
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.
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.
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.
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.
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 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.
Advantage: goroutines.
I think 24 months quoted in the article is optimistic...
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.
(Part of Python's popularity is that it is such a great glue language)
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.
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.
A question: What is your idea of "something significant"?
Go seems like an ideal language to quickly build servers. Am I missing something else?
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).
http://en.wikipedia.org/wiki/Betteridge%27s_Law_of_Headlines
This is not really even such a ridiculous proposition, either- certainly worthy of discussion.
How Much Is a Fun Job Worth? No.
Ask HN: Why is wikidot.com blacklisted? No.
Ask HN: What is your ideal income? No.
Which educational technologies are worth betting on? No.
Ask PG: What Is The Most Frighteningly Ambitious Idea You Have Been Pitched On? No.
That recalls an old prolog joke:
Q: "How many prolog programmers does it take to change a lightbulb?"
A: "Yes."
It's a very nice language, I like it a lot, but if there's one thing we all should have learnt over the last few years, it's that no programming language is the right choice for every task.
Add some sort of decent generics and you're really close.
A top-class GUI toolkit would be good too.
for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-i...
BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c).
i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).
i think the general conclusion from this thread is that generics would be useful because, at the moment, if you want top performance, you need to have type unsafe code in critical loops.
that sounds quite reasonable to me...
...so maybe i am just an arrogant bastard that doesn't think much of fellow programmers. but i suspect that most people, when they complain about generics are not making that argument. they're simply complaining because it's not what they are used to.
as i say, i may be wrong. i may be a horrible man. if people want to convert/improve me i suggest they start making comments that are a bit more nuanced than "i miss generics".
Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"?
This claim doesn't check out.
Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place.
The built-in map, while useful, is limited in how far it goes.
Maybe I'm just spoiled by the STL and the Java collections libraries.
map :: (a -> b) -> [a] -> [b]
Essential: no.
Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.
No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.
The only added simplicity here is for the compiler writers, not the end users.
for i, n := range numbers { numbers[i] = n * n }
Sorry, but I do not see a difference in the order of assembly language vs. high-level language.
Higher order functions are really useful for splitting apart navigation of a data structure and the processing of the data contained within it.
Given that you can use purely higher order functions for control flow, I wouldn't say one is more essential than the other.
a) With a more complex type (I don't see how this would affect one more than the other)
Functional would be:
foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} })
Iterative is:
for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} }
b) Composing various operations. Composing filter + map:
Functional would be:
x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 })
Iterative is:
x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } }
c) Swapping the container type is just a matter of swapping "_, n := range numbers".
It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming.
b) Composing various operations. Composing filter + map:
As you keep building them up the imperative style will have more code overhead and less efficiency.
> c) Swapping the container type is just a matter of swapping "_, n := range numbers".
This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.
b) No, it will not be less efficient. It's all done within one loop, in-place. You can compose everything inside the body of the loop. A functional language would do the same if it's intelligent.
c) You can easily create an infinite data source in Go with the generator pattern:
numbers := make(chan int); go func() { for i := 0; ; i++ { numbers <- i } }()
for n := range numbers {...}
Yes, I should have said type inference obviously. I can't think of a decent functional language that doesn't have type inference though.
> No, it will not be less efficient. It's all done within one loop, in-place. You can compose everything inside the body of the loop. A functional language would do the same if it's intelligent.
If it's all done in one loop then it isn't composing. It's writing custom code every time you need to do something.
> You can easily create an infinite data source in Go with the generator pattern:
That's nice, you only need to change all of your code to do so. The functional version doesn't have that problem.
Please note that if your comment thread starts getting squished against the right side of the page like this, it might be time to move the conversation off of HN.
================
It could be a linked list that links back to it's own head. It could be a network stream, or a series of events from an input device. The program doesn't have to care.
It's a different way of approaching things. I'd say that golang was stream-based rather than functional or imperative.
https://github.com/tcard/functional
I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...
I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive.
In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.
The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition).
Not sure how you’d handle that sort of case in Go without generics?
Implementing a top-class GUI toolkit that is not just a binding to an existing one would be at least half a decade of work. And when it's done all GUIs will be rendered by web views anyway. The web is the presentation layer of the future. Classic desktop widget sets like QtGui or Swing will fit nowhere, because all the consumer operating systems like iOS, OS X, Android and Windows 8+ will have highly custom user interface paradigms, which won't be mappable to each other by some cross-platform thing.
This. Go makes it fantastically simple to go from 0-to-web-server.
There were a few projects I wanted to write in Go, but avoided because of needing a GUI.
Then I remembered: I can just bolt a web-page onto my app, and I get a GUI for free [assuming knowledge of HTML/CSS/JS].
Even better: that GUI will work on any computer with a modern web-browser, including my phones. If you stick to standards, it should even be a reasonably consistent UX across the newer browsers.
---
While I would still _like_ to see a good UI toolkit for Go, I really think it's less of a necessity than most would have you believe.
I'm playing with the idea of a Cairo/Postscript type library with X, Win32, Quartz backends in Golang which would be a good foundation for such a thing.
I have got precisely nowhere apart from trying to connect to an X server unsuccessfully though :)
I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult. That's the only reason I stick exclusively to command-line programs.
Odd. Here's my 5 min explanation of how GUI programming works:
You have a bunch of objects that are responsible for generating events and painting themselves to the screen. They exist in hierarchies. You have objects that coordinate the transitions between different display states by swapping out different hierarchies (view FSMs, really.) You communicate with your domain backend thread/process through some kind of command channel. When your domain models change, they publish some events that go back through that channel to notify your display hierarchies so they can update themselves. Everything is async and through message passing.
The difficulties can be in a) setting up your hierarchy of display objects and b) getting your event routing / updating to happen in a clean way. Oh yea, and c) handling partially-complete domain models in the ui ;)
Cocoa/CocoaTouch and Flex are both quite nice environments for gui programming. I haven't used MFC, winforms or xaml/winrt..
Of everything you describe, I think the area I struggled most with was:
>getting your event routing / updating to happen in a __clean__ way.
I was a naive and young programmer, so I'll withhold any criticisms towards WinForms, but the event routing was a _mess_ by the end of that project.
That's a personality type (mine too). Probably best to bite the bullet with HTML/CSS. I think non-web interface builders are a thing of the past. Which is too bad, because CSS is a monster to master.
Developers need tools too so we shouldn't just abandon non-web technologies.
No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]
Colloquy represents the chatroom text as a stream of XML, which it uses XSLT themes to translate into HTML, which is displayed in a WebView. I'm sure Adium does something similar.
"Using HTML/CSS/JS as the new GUI medium" doesn't limit itself to just running stuff in a traditional browser. I was under the assumption that we were talking about making HTML/CSS/JS the new GUI layer, even for native apps.
http://go-lang.cat-v.org/library-bindings
Check out the "GUIs and Widget Toolkits" section.
1.Coroutines, Channels and Select: Concurrency with built in synchronization and communication is accessible(especially if your are new to concurrent programming) enough to handle "most" of the grunt work. 2.gofmt: Formats your code for you. No more debates(procrastination) on that. 3.godoc: Generates documents. No more looking for the best 3rd party tool and wasting time. 4. Defer and Close: Helps you to do better post-operation tasks i.e better resource management. 5. Error Handling: Multivalue returns. 6. Type Hierarchy: No type hierarchy exists in the conventional sense. 7. Slices & Maps: Just two of them, and that's why I love it. 8. Brevity and Readability: Clutter free syntax. WYSISWYG language. 9. Philosophy of Exclusiveness: This is most important non-feature which makes Go different and exciting. Go's vision is to be an exclusive programming paradigm rather than being an inclusive one. In this Google I/O video: http://www.youtube.com/watch?v=sln-gJaURzk, Robert Griesemer speaks about an incident that how in a "D" programming conference, the developers intended to include a new programming paradigm in the future. This is what sold it for me as I care more about how the language will grow instead of what new cool features will come in.
Performance is a contentious issue. In an ideal world, performance would just depend on the platform and the language, but in reality it also depends on the skill and idiosyncrasies of the programmer. For me, that is a non-issue.
Quick Reference to Go talks: http://code.google.com/p/go-wiki/wiki/GoTalks
The new Go Revel framework (by HN user robfig) looks especially promising for web MVC apps: http://robfig.github.com/revel/
No big chance for enterprise or academia. And I believe that for ordinary "check this, forward that" backend programming, Ruby, Python and Perl will still remain staples, with a few percentage points shifting back and forth, as usual. Rails didn't end Python.
On the other hand, I wouldn't shed a tear if it would eat up the majority of node.js' marketshare.
Our authentication, filestore, directory services, messaging and web front end are all easy targets.
Go seems okay. I tried to write a few small programs in it but spent a lot of time hunting around in the manual for how to do things. D (as in dlang.org) has a very similar feature set (static but not annoying typing, lightweight threads, value types, GC, native high-level arrays, yaddah yaddah) but is more familiar to us C/Java programmers. One feeling I get is that Go exposes a lot of quirks (e.g. the 'make' function and inter-thread messaging) in the syntax of the language, whereas D takes care of those cases with regular library functions. I was impressed that while writing my first D program I rarely committed any syntax errors, as I found it an intuitive extension of Java/C syntax. So if anything is to by my next go-to language, it's more likely to be D than Go. Or does that make it a d-to language? Ha ha ha heh hrm cough.
1. Go doesn't discard the last 40+ years of programming history. Ints, chars, arrays, pointers, structs -- in addition to minimalist types that build on these -- are at the heart of Go's lexicon.
2. Following off of point 1: C and C++ source code and algorithms are easily translatable into Go because they look like Go.
3. Following off of point 2: Because old C/C++ code looks similar to Go, Go's libraries will soon number C/C++.
4. A well thought-out, minimalist toolchain. Working with "go install", vim, and gocode is like dancing in the clouds when compared with the morass that is Eclipse or Visual Studio, let alone C/C++ and its makefiles.
5. Go's object-orientation is done right. Go strongly emphasizes "has-a" relations and eschews the "is-a" relations that are prevalent in C# and Java. To see the effect this has on code readability, look at Go's documentation. For example, http://golang.org/pkg/database/sql/ ...scanning one page tells one all that's needs to be known about a package. Go's objects ride just above atomic data structures. There is not a five-mile chain of object dependencies and corresponding taxonomy clouding one's understanding as in C# or Java.
6. Go's channels give the programmer their very own ksh/bash built right in to the language. Admittedly, this is an oversimplification, but piping program units together is a proven method of strongly modularizing applications and has the added benefit of being inherently concurrent. Languages have been moving away from the shell for decades and have in the process lost its advantages.
(With all that said in point 6, there is still room for something like a lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go -- does not throw out 40+ years of shell history. Unsung Tcl/Tk (http://www.softpanorama.org/Scripting/tcl.shtml) and Expect seems to fit the bill the closest currently, though it does not read like the C family of languages. Perhaps if someone were to build a Go shell, or create a cshell that used used Go's conventions, Go would have a good glue-language counterpart.)
Except for:
- enumerations
- exceptions
- generics
- dynamic modules
- ...
- iota
- http://golang.org/doc/go_faq.html#exceptions
- http://golang.org/doc/go_faq.html#genericshttp://en.wikipedia.org/wiki/Enumerated_type
As for the other two links Go fanboys like to throw them around to feel happy that they beloved language is comparable to programming languages developed in the 70's.
The things that you left off your list that I think are much more interesting are:
- Weak/Strong purity, enforced by the type system
- uniqueness typing
- chan is too special. The difficulty with implementing a good netchan interface is starting to show this.As the consternation of C# developers about windows 8, and java developers about Oracle lawsuits, relying on a language that a single company makes is foolish - especially companies that have a track record of abandoning projects.
I think C++11 will be the new go to language. It is standardized. As Moore's law runs out for single cores, C++ is positioned as the language that can run fast on a single process and scale easily to multicore
Not in the web world. Go will take programmers from the C/Java camp, but not many from the ruby/python camp.
Not even one in a hundred startups will use Go as their main programming language. Ask PG to confirm.
I am an early golang user and once in a while play with it to try new stuff, but still coding everything else in python.
To answer the question: Yes for systems work, No for web work.
Coming from a scripting language background, Go feels like a step forward in performance, without many of the headaches of C++ or Java.
But speaking to people who write C++ for a living, they see little or no use for go for them, as they need either the performance or flexibility of a lower level language like C++ - that's why they haven't moved to an alternative a long time ago.
I think Go will be well suited for web applications: 1. Google App Engine will continue to play a major role in Go's development. 2. The speed of development in Go is equal to or exceeds that of other dynamic languages. Static typing takes minimal extra time and immediately pays off by catching silly errors, then continues to ease development (and documentation) in the future. 3. Go's standard library already contains powerful tools to develop web apps.
It's important to remember that Go is still very young. Could you explain why you still prefer Python over Go?
If you need speed, you can either go PyPy, or Cython after locating the problematic code spots.
Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
It took a while for C++ and then for Java to become languages of corporate decree. If Go will ever become one of those languages, it will take around the same amount of time.
No it doesn't, it implies they are accustomed to dynamically typed languages, and unfamiliar with modern statically typed languages.
>Same applies to your description of Go as nothing more than a bridge to Scala.
That's interesting given that I said no such thing.
>Are you so sure that everyone using languages other than Scala and Haskell is that much dumber than you are?
Who are you replying to? I said nothing of the sort.
>If Go will ever become one of those languages, it will take around the same amount of time.
What does that have to do with anything? Nobody is discussing whether or not go will become the corporate standard language.
I love Cassandra, and the JVM is solid too, but the "stop-the-world-pause" in it's current garbage collectors truly blows. All of that fast latency is for not if the JVM decides to spend a few seconds churning through garbage. :(
I've looked into Azul's Zing JVM, but it's basically only for beefy hardware (16+ cores and 32GB+ RAM), and it's also crazy expensive.
Considering the naïvety of Go's GC (a non-generational, non-compacting, conservative, stop-the-world and broken-on-32b[0] mark&sweep)... I would tend to bet against it way sooner than on it.
And remember that goroutines use shared memory, so you can't have an emergent concurrent GC as in Erlang.
[0] http://utcc.utoronto.ca/~cks/space/blog/programming/GoLang32... https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
Am I totally wrong?
The latter is where Azul Zing requires a lot of RAM to operate, as I understand it.
The recommended RAM for the JVM heap running Cassandra is 8GB, and 4GB isn't uncommon in the cloud. Netflix uses 12GB, and is contemplating going back to 8GB (they made that decision awhile ago, and things have changed since then).
I have boxes that run JVM heaps as low as 2GB just fine. It really just depends on how you're using it. (I've heard of people using 256MB heaps with Cassandra.)
I get a full collection roughly once every 10 minutes. Until then, the pauses are only in the 20-30ms range (which is still double the usual latency for a request).
With Azul Zing, the longest you'll ever see is the 20-30ms range, and it's virtually always around 1ms.
http://zackarymorris.tumblr.com/post/26701252898/a-mistake-i...
But other than that, it looks like a very tasteful language and I want to use it for some parallel computation experiments since they make it so easy to spin off tasks.
Also, you can use the `gofmt` tool (when running Go on your local machine) to help you learn what Go prefers if you don't want to read all of the excellent documentation on the site. [EDIT: I see you already know about this tool but I'll leave this comment here for others]
I keep thinking I should get around to doing a real project with it, then I get irritated by the strident advocacy and put it off again. For purposes which seem to call for Go I can easily just go back to C. Which is already beyond mature and plays nicely with almost any non-JVM language.
eamonnerbonne Thursday, September 13 2012
It’s a night and day difference. Let me try a writing
analogy with Word + Notepad.
Say you’re trying to write a text for a particularly
picky client that will reject your text if you make any
mistake or use any unclear phrase. Then dynamic typing is
like Notepad: you better be careful, have lots of
proofreaders, and expect to have your text rejected
often. And when you print it, it’s in a slow-to-read
monospaced font.
Static typing is like Word with all the grammar checking
turned up to 11 (it won’t let you print or email any text
with what it thinks is an error). It’s harder to learn,
and sometimes your PC runs slowly, and the grammar
checker will find lots of irrelevant stuff, and to keep
it happy you might need to change your style, but it
*will* make certain types of error irrelevant (e.g.
spelling), and occasionally catch more complicated
mistakes too. Also, as a bonus that might or might not be
relevant, word prints in a font you can read much more
quickly.
The point being: they’re totally different ways of doing
things.
wow
I ask this because I often find myself thinking I would want such-and-such a feature in a tool, library, etc, but unless it was implemented in response to an immediate need, when I actually add it I realize it ends up unused.
My guess is that better containers aren't in the library because of the lack of generics. I really hope the Go folks get around to adding generics soon; it's a beautiful language in most other respects. It would definitely be one of my first choices for a more systems-y project.
Here is a listing I know of, this probably isn't comprehensive:
http://go-lang.cat-v.org/pure-go-libs
And I maintain both pages, and I have to confess they are badly outdated because is hard to keep up with all the libraries that are being written.
Why Learn Go? http://www.youtube.com/watch?v=FTl0tl9BGdc Short interview with Rob Pike, OSCON 2012
Get Started with Go http://www.youtube.com/watch?v=2KmHtgtEZ1s Andrew Gerrand
A Tour of Go http://www.youtube.com/watch?v=ytEkHepK08c Russ Cox
Go Concurrency Patterns http://www.youtube.com/watch?v=f6kdp27TYZs Rob Pike, Google I/O 2012 Goroutines, Channels
Meet the Go Team http://www.youtube.com/watch?v=sln-gJaURzk Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012
Computing Map Tiles with Go on App Engine http://www.youtube.com/watch?v=sPagpg0b7no Chris Broadfoot, Andrew Gerrand, Google I/O 2012
Go in Production http://www.youtube.com/watch?v=kKQLhGZVN4A Gustavo Niemeyer, Google I/O 2012
Go: Code that grows with grace http://vimeo.com/42146678 (Contains some audio glitches) Andrew Gerrand
Interview with Rob Pike http://www.infoq.com/interviews/pike-google-go/ Rob Pike, GOTO Conference
Lexical Scanning in Go http://www.youtube.com/watch?v=HxaD_trXwRE Rob Pike
Cuddle, A Go AppEngine Demo http://www.youtube.com/watch?v=HQtLRqqB-Kk Andrew Gerrand
Building Integrated Apps on Google's Cloud Platform http://www.youtube.com/watch?v=Mo1YKpIF1PQ Andrew Gerrand, Google Developer Day Japan 2011
Real World Go http://www.youtube.com/watch?v=7QDVRowyUQA Andrew Gerrand, I/O BootCamp 2011
Go: it's that simple?! http://www.youtube.com/watch?v=LWpm1qpWRwA Andrew Gerrand, OSDC 2011
Practical Go Programming http://www.youtube.com/watch?v=2-pPAvqyluI Andrew Gerrand, FOSDEM 2011
Writing Web Apps in Go http://www.youtube.com/watch?v=-i0hat7pdpk Andrew Gerrand, Rob Pike, Google I/O 2011
Go Programming http://www.youtube.com/watch?v=jgVhBThJdXc Rob Pike, Google I/O 2010
Another Go at Language Design http://www.youtube.com/watch?v=7VcArS4Wpqk Rob Pike, Stanford University
Public Static Void http://www.youtube.com/watch?v=5kj5ApnhPAE Rob Pike, OSCON 2010
The Go Programming Language http://www.youtube.com/watch?v=rKnDgT73v8s Rob Pike, Google Tech Talk
My dev plan used to be Python for rapid prototyping and C for speed optimization. With the advent of Go, I find I'm moving the infrastructure-level Python work into Go and replacing many of the C-oriented middleware tasks with it as well. I'm sure this will evolve as the libraries grow, but I don't see Python & C going away. Nor do I think this is the vision at Google. I suppose this is what is meant by "systems language".
I think Go could end up being the under 35-generation's version of Lisp (in terms of love affair with language structure, etc.).