101–110 of 189 posts
How's the garbage collector these days for Go? Is it close to the performance of the Java GC?
No, still the same old one. Improvements are supposedly coming though (though, they were coming 2 years ago also).
GC is an area where always there is room for improvement, no matter how much you work at it.
Earlier quoted context omitted.
It's not as sophisticated, but Go structs are smaller than similar Java objects, so that helps beat the tradeoff
I like Go, but this is total nonsense. It does help that you can embed values in a struct, rather than using pointers. But marking everything that looks like a pointer is not efficient. Not having generations does not help. Go is still very young, a better GC will come, just give it time. In the meanwhile, let's not pretend that the current sub-par generator is as performant as that of modern JVMs.
And with Go if you really care, you can be even more careful and produce close to no garbage.
Control over memory layout is really useful.
@enneff Do you know if they are using the default gc compiler, or gccgo which is supposed to have better optimisation?
gccgo does better at some things, but the default compilers do quite well already.
Earlier quoted context omitted.
Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
Earlier quoted context omitted.
200 servers for 800mio requests seems a little nuts. Two of my customers are doing 500mio and 400mio respectively on ~20 each, on Rails (i.e. as slow as it gets).
Do you count cache hits as a request?
Moovweb creates mobile versions of standard websites on the fly. That sounds pretty expensive, and they probably have a ton of network overhead from distant servers and slow clients.
"100% of our production system is now running Go as 95% of our application (C being the other bits)" So... 95% of their production system is running Go.
Earlier quoted context omitted.
Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
What's your definition of generic programming BTW? I'm looking at several definition right now and cannot find out if, for example, a generic list container in C using void pointers to data would be considered generic programming.
Wikipedia states generic programming is "a computer programming paradigm based on method/functions or classes defined irrespective of the concrete data types used upon instantiation". That reads like "templates" to me.
Earlier quoted context omitted.
"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement." I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally,…
As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible . I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the fr…