15 ms·

Another go at Go failed

• mediocregopher 13y ago
  The author says go doesn't have generics, and he had to rewrite the same set operations for each type that he used. Would this not work? https://gist.github.com/mediocregopher/8319986 https://gist.github.com/mediocregopher/8319986 The items in the sets don't even have to be the same type
• Goranek 13y ago
  Seems that 2014 won't be a good year for Go on HN. Same old story as with Node and Mongo. First they ignore you, then they praise you, then they hate you.
  • jaxytee 13y ago
    Go never intrigued me anyway for that matter. It's supposed simple syntax was not enough of a motivator for me to chose it over a higher level language (Clojure, Scala, Etc) that requires a bit more elbow grease to become proficient it.
  • laumars 13y ago
    There's always been blogs complaining about Go and the generics issue raised in this blog is something that crops up in every discussion about Go. The problem with heavily hyped languages is that some people jump on the bandwagon without really thinking about the problem they're having. And this is exactly what the author of this article seems to be doing. If you're having to convince your clients to maintain a project in a language neither of you have developed in and you guys already have experience in other languages, then the question should be "what will I gain from switching to Go". The author's justification seemed to be "It's hyped online" rather than any technical justification; and that strikes me as a poor decision from the start.
    • commentzorro 13y ago
      What?! I you might want to reread the article and then read the author's comments here and his other Go articles. The author clearly knew about Go's lack of generics and was quite familiar with the language. After stepping away from the language for a while he decided to give it another try in a project where he thought the lack of generics could easily be worked around via Go idioms. He found out that the lack of generics _did_ hurt more than expected and wrote about that part in a way that projected his frustration.
  • matthewmacleod 13y ago
    Those three steps are basically: - New technology is introduced. Nobody's really heard of it or used it, so beyond a few "Look at this new thing!" articles, nobody talks about it. - The technology gets some penetration. New users pick it up, probably because it solves some issue or irritation they have. They write about how the technology helps to deal with it, or why it's interesting; if it didn't/wasn't, they'd probably not bother using it, and would be pretty quiet about the whole thing. - If the technology made it this far, there is an explosion in popularity as more people pick up the tools and use the technology. Typically this results in quite a few people using it in the wrong way, or because it's the current 'hot stuff' (rather than because it will solve a particular problem), or maybe picking it up a little bit too early. Lots of these people will write about how the technology sucks, or how it doesn't solve particular problems. That's fine; it's the public knowledge-gathering phase, and although there will inevitably be a lot of negativity, other people will discover the benefits, and the technology will frequently evolve to address popular concerns. - The fourth step, that you didn't mention, is that the technology and discussion around it becomes more "mature" - it's widely-used, everyone's more-or-less aware of the pros and cons. There will be the occasional post called "X Sucks, I'm Moving to Y!" or "Why I'm still using X and not Y". tl;dr: that's the way it goes - it takes a while for new technology to work out the kinks and for the community to understand where and how it should be used. And while that happens, they'll talk about it.
    • mseepgood 13y ago
      http://upload.wikimedia.org/wikipedia/commons/9/94/Gartner_Hype_Cycle.svg http://upload.wikimedia.org/wikipedia/commons/9/94/Gartner_H...
      • Tegran 13y ago
        Once you've embedded the Hype Cycle in your consciousness, it's amazing how often new technologies follow it. Also interesting just how worked up people get at each peak and trough... :)
  • reinhardt 13y ago
    The way I see it, there's very little compelling about Go to outweigh its shortfalls and I don't see it getting mainstream any time soon, if ever. If languages were stocks, I would have shorted it long before the HN hype started. Then again, I feel pretty much the same about the whole crop of hip languages du jour (scala, clojure, erlang, haskell, ...)
    • bsg75 13y ago
      For those of us coming from Python, Perl, etc., Golang brings performance and concurrency in a format that is easy to pick up and integrate. I have not touched C in almost 20 years, but I was able to write a concurrent program in Go that outperformed a similar multiprocessed Python script by about 5X in roughly one day. Go does not have the same library depth as Python, but the stdlib is pretty good. The thing about Go that is similar to Python is _my_ performance is good, and I don't have to expend much effort in boilerplate code, or learn a coding approach that is unfamiliar, yet I still get relatively high performance. Go won't replace Python for me, until things like matplotlib and Pandas become available, but it make an excellent addition to the toolkit.
• nodata 13y ago
  tl;dr chose wrong language for the task.
  • teddyuk 13y ago
    too true, if you want a fast, simple scalable network thing then look at GO, otherwise don't. I would also say if your handing over code to another team to support and they don't know the language and the only reason you are allowed to do it in that language is they couldn't think of any objections that you can't bypass then don't use that language!
  • baq 13y ago
    there seems to be quite a few people suggesting that go is the correct choice for every task. the article is a sorely needed voice in the HN echo chamber. personally i'm waiting for rust, go is nice but not better enough than python to justify switching - especially when you consider maturity of third-party libraries.
    • belluchan 13y ago
      > the article is a sorely needed voice in the HN echo chamber. > personally i'm waiting for rust See, this seems weird to me because Go is actually a language that you can build nice things with right now. Check out coreos's etcd[1] for example. Rust on the other hand gets a lot of adulation in this echo chamber but is so, so far from completion that you're going to be waiting like a decade or so before you can do anything networking related with it. And personally the varying clumsy degrees to do the same thing many different ways in Rust (the various boxing and unboxing and other memory handling options) are a real turn off. Comparing Go to Java is fair, and of course Java will come out on top given its maturity, but Go offers a lot of good things. Comparing Go to Rust is not, Rust is not ready for any kind of real world use. [1] https://github.com/coreos/etcd https://github.com/coreos/etcd
      • robin_reala 13y ago
        you're going to be waiting like a decade or so before you can do anything networking related with it Servo’s net component would like a word: https://github.com/mozilla/servo/tree/master/src/components/net https://github.com/mozilla/servo/tree/master/src/components/...
• ceautery 13y ago
  There wasn't a good description of what overall task his program was trying to do, or any source code showing how he approached maps, etc. Other than that, it sounds like proof. Of everything.
  • MetaCosm 13y ago
    Also, it sounded like he was comparing single-threaded Go versus multi-threaded Java?
    • baq 13y ago
      more like he was surprised that java did parallelization behind the scenes.
      • girvo 13y ago
        I'll be honest, I'm surprised by that!
        • acqq 13y ago
          I'm too! I don't program in Java but I've never read that the compiler or JVM can do anything like that automatically (making the user's code running in parallel even if the user didn't specify anything). I suspect that what he observes is the garbage collector running on more cores at once (AFAIK it is designed to run so now) and that the garbage collection was the cause of the slowness in Go too. I persume he managed to have a heck a lot of allocatations and that caused the slowness of Go and the full-throttle GC run in Java. But this is just a guess. If anybody knows more exact details please write!
    • mackwic 13y ago
      Go can't be really mono-threaded unless you are trying to do so (or your program is really short). A lot of the standard operations under the hood are in fact executed in goroutines in a pool of threads. IOs are, for example. So you found yourself gaining all the advantage of asynchronism without supporting the cost in the code... exactly like this example in Java.
• SideburnsOfDoom 13y ago
  > Russ Cox' original formulation of the now-famous tri-lemma is incomplete at best. Could someone give a brief introduction to what this sentence means? I have absolutely no idea about any of it.
  • signa11 13y ago
    probably this: http://research.swtch.com/generic http://research.swtch.com/generic ? go had 3 options for implementing generics: 1. leave generics out : the c way (slows programmer) 2. do it at compile time: c++ way (slows compilation) 3. box/unbox everything implicitly: java way (poor perf)
    • SideburnsOfDoom 13y ago
      Hm. Which of these does C# use? Which does Haskell use?
      • pjmlp 13y ago
        Regarding C# it depends on which compiler you talk about. Microsoft's current JIT/NGEN, generate a single version for reference types and a separate version for each value type. So a mix of Java/C++ approaches. Not sure what the new JIT/NGEN compilers, RyuJIT will use. I also don't know what approaches are taken by Mono, Bartok and IL2CPU, but they might be similar.
        • SideburnsOfDoom 13y ago
          Yep, now I can see why this is trilema is "incomplete at best" - c# and other use what can be described as a mixture of these three approaches. I was going to say that the c# compiler is fast enough despite this, but then I remembered that one of go's selling points is that the go compiler is blindingly fast compared to languages such as c#. Perhaps maintaining that performance with generics is a real issue.
          • 13y ago
• RyanZAG 13y ago
  Who would have thought that a brand new language wouldn't have the features, library support and optimization that the more popular languages have? Should be obvious, but then you read through HN posts with people dismissing languages like C++ and Java as 'too old' or something and that you need to use some brand new untested language to be worth talking about. Never select a language based off hearing about it on HN or blogs. Either stick with what you know or use a tool that has very specific optimizations for the problem you're going to tackle (and no, concurrency is not a good option to jump off the JVM as it has incredible concurrency support already: see https://github.com/LMAX-Exchange/disruptor https://github.com/LMAX-Exchange/disruptor for the fastest concurrent bus I've seen in any language). Of course, there is nothing wrong with testing out golang or haskell - just don't force your paying client to test it out with you or you might be one less client shortly.
  • mercurial 13y ago
    There is nothing wrong with testing golang, certainly. But Haskell is 24 years old. Hardly the new kid on the block.
    • RyanZAG 13y ago
      Haskell (and Lisp) will always be 'new'. Especially going by HN posts which seem to think that Haskell is some brand new language created last week to solve the problem of 'side effects' and in a few months time everyone will be using it.
      • pjmlp 13y ago
        I have spent part of the holidays reading about Interlisp and Mesa/Cedar systems at Xerox PARC. Quite powerful GUI desktop systems in the early 80s, using language capabilities that are yet to be fully usable in the mainstream. Lisp on one system, and a GC enabled systems programming language on the other one. Every time I discovered such systems being ignored most developers, I remember of Bret Victor's talks.
      • IsTom 13y ago
• yelnatz 13y ago
  tldr: I will be using a lot of generics and do tons of set operations. I will chose Go, a language that doesn't have generics and sets. (I won't post the Go code for criticism, and I couldn't stand golang-nuts)
  • shadowmint 13y ago
    and; go isn't the best language to write everything in. I think that's a fair conclusion for him to have drawn. He certainly wasn't hating on go. (golang-nuts is openly hostile to any kind of criticism, so much so that there's been talk of a community code of conduct; which the community didn't want. I don't blame him.)
  • sixthloginorso 13y ago
    So... if you need any data structure other than an array, a hash table or a channel, you should skip Go and find some other language? That's kind of limited.
    • tptacek 13y ago
      No, the problem is that he needed Sets of many different kinds. It's perfectly straightforward to implement data structures in Golang; it's just hard to make them work for a variety of types simultaneously.
      • sixthloginorso 13y ago
        > it's just hard to make them work for a variety of types simultaneously. That's sort of what you expect from any given implementation of a data structure and its related algorithms, though I imagine that some specialized implementations benefit from having them tailored to their concrete types. Examples, anyone, please?
• pron 13y ago
  When I first learned of Go I thought it had a very narrow use case. The language is basically simplified Java (or a reinterpretation of Java), and works on the same level of abstraction. It's not low-level like C/C++ or Rust, and not high-level "productive" like Clojure. It seemed like Java sans JVM, and as Java developers know, the JVM is the best thing about Java (some would say its only grace). It lacks the JVMs runtime profiling and monitoring tools, as well as the JVMs most powerful features of dynamic class loading and runtime bytecode instrumentation. Its only advantages, as I saw them, were a much reduced startup time and a lower barrier to entry for beginners; its only use case, I thought, was for writing fast command-line apps. Most people who seemed excited by Go were Python and Ruby developers who liked the speed boost and the easy set up. Now I think Go actually has some very good use cases. While I would never dream of developing a large, complex or critical app on any platform other than the JVM, the fact that Go produces self-contained executables makes it very convenient sometimes. Fast command-line programs are actually not too narrow a use case, and Go is not useful just for those. I can see myself using it for other small web or network services as well. I still think Go is a JVM-less Java, or a Java Lite, but apparently Java Lite is a very useful thing to have.
  • pjmlp 13y ago
    > Its only advantages, as I saw them, were a much reduced startup time Even that can be solved when using one of the many native compilers available for Java. As the OpenJDK does not have one, people tend to forget other vendors have them.
    • bmurphy1976 13y ago
      How does having a "native" compiler reduce the startup overhead of the JVM? That doesn't make any sense. It may reduce compile times, but ultimately the reason startup sucks is because the JVM is huge and has to load everything and the kitchen sink in order to function for even the smallest programs.
      • pjmlp 13y ago
        Because when you compile to native code ahead of time: 1 - There is no JVM 2 - All the code that is not used is not part of the binary, if you do a static build 2.1 - There are native compilers for Java where you can give exclusion lists to allow certain code to be kept even in static builds to allow reflection use
• porlw 13y ago
  Rather than storing data structures directly in the hashmap, I would store them in an array and map the keys to array indexes. Then the types of the hashmaps would all be the same (all map key->integer), and I could develop reusable procs for each set operation.
  • willvarfar 13y ago
    Wouldn't that mean an extra level of indirection while dereferencing?
    • dded 13y ago
      Yes, but so does run-time generics somewhere along the line.
      • sepeth 13y ago
        Really? AFAIK, compiler creates those functions/classes from corresponding generics (it is called templates in C++, and it really acts like template in C++). Hence, they are compile time. I believe, it is the same in Java, too: http://docs.oracle.com/javase/tutorial/java/generics/erasure.html http://docs.oracle.com/javase/tutorial/java/generics/erasure...
        • dded 13y ago
          Well, yes, compile-time generics are compile-time. That's why I said "runtime".
          • willvarfar 13y ago
            Yes, but you are recommending he do that in Go, so by having an extra array lookup you'd be further slowing down the Go program, which he says is 5x slower than the Java program already.
  • sigmaml 13y ago
    > Rather than storing data structures directly in the hashmap, I would store them in an array and map the keys to array indexes. Author of the blog post here. That is one of the reasons I shifted to using bit sets: specific element types can be elided.
• silvestrov 13y ago
  the CPU utilisation ... was around 370-380%! I was now totally stumped I guess that his code allocates a huge number of objects as all input and output classes are final. The JVM's garbage collector is able to run concurrently, so I guess it's the GC that takes so much CPU. AFAIK Go uses mark-and-sweep collection which is very slow. That would explain the unexpected difference in running time as the JVM's garbage collector is very mature and fast.
  • NateDad 13y ago
    When Go is slow, it's almost always due to excess garbage creation. This can usually be fixed by optimizing your memory usage... but I'm guessing an experienced java professional may not think of that precisely because java's garbage collection is so damn good most of the time.
    • yelnatz 13y ago
      I know theres a []byte mempool project on github.[1] Still pretty early though, I don't think it can do dynamic sizes? [1] https://github.com/thejerf/gomempool https://github.com/thejerf/gomempool
      • NateDad 13y ago
        Most of the time it's really just a matter of reusing data structures rather than creating new ones and throwing them away immediately, over and over again.
        • yelnatz 13y ago
          Yep, I think that's basically the idea there. "You already have this []byte, don't throw it away, give it back to the pool so you can reuse it."
      • jerf 13y ago
        Pooling dynamic sizes is a bit tricky; if a user requests 1000 bytes and you hand them 1000 bytes, you're in some trouble if the next guy asks for 1002. I round all allocations to powers-of-two in there. It does dynamic size but at the moment I don't have separate per-bucket pooling settings; it's the obvious next feature. The stats collection is intended to show me whether that's a useful feature. In testing so far it hasn't been in my specific use case, but I'm still only hitting my application with load testing, not real load. The use case for gomempool is relatively transient buffers, where that is a win vs. generating a lot of []bytes. Rounding to power-of-2 is a traditional, theoretically solid answer. There's also as somewhat more unusual one using Fibonacci numbers, which Erlang uses to size its memory hunks. Fortunately the interface is agnostic, if that's advantageous someday user code doesn't need to notice the difference. I couldn't resist the first time in my career in which I could justify some bit bashing: https://github.com/thejerf/gomempool/blob/master/pool.go#L395 https://github.com/thejerf/gomempool/blob/master/pool.go#L39... :)
• michaelwww 13y ago
  Note to self: don't try to foist an unfamiliar language on a client without actually knowing if it will solve the problem efficiently.
• arundelo 13y ago
  being able to do minus, union, intersection, etc. I had to code those in-line every time. I'm not sure I understand the post author's complaint here. What's wrong with writing your own SetDiff, SetUnion, and SetIntersection functions and doing stuff like the following? baz = SetUnion(foo, bar) (I have done very little programming in Go.)
  • acjohnson55 13y ago
    What's wrong with having them in the standard library?
  • tomp 13y ago
    What is the (declared) type of `SetUnion`? Don't forget, Go has no generics/parametric polymorphism.
    • lafar6502 13y ago
      So, are you saying that it's impossible to declare a function without generics? How did the world run before generics were invented?
      • sixthloginorso 13y ago
        The author said that he needed a generic set for different concrete types, so he'd have to write a bunch of these functions for all the combinations he needed. And he did. And it was a mess. And it was also slow. Edit: not that we can conclude anything from the lack of performance, though, we don't know how it was written.
        • lafar6502 13y ago
          I believe it was a mess. But i don't believe it couldn't be done correctly in Go or whatever language you take.
          • Roboprog 13y ago
• osteele 13y ago
  My rule of thumb is to use a language for something a domain that its community uses it for. Python for scientific programming, Ruby or nodejs for web servers, PHP for embedding dynamism in a static site. Then you're more likely to find libraries and support, and to find adoption for your own libraries and pull requests. This doesn't mean you're always safe even on a language's home turf (Rails and Node each had significant problems as a server platform for their first, hyped, years), or that it's never worth stretching the domains that a language is used for (that's where Ruby's Rails and Python's Numpy came from), but you should recognize that you're out on a limb when you do so.
  • okpatil 13y ago
    >Ruby or nodejs for web servers You haven't tried go, have you?
• poorelise 13y ago
  I think in many cases you don't need generics because you can use the interface mechanism instead. The way Go does it is a bit confusing at first, so I suspect many Go newcomers don't really understand they could have used it. As an example look into the way sorting is implemented in the standard library: http://golang.org/pkg/sort/ http://golang.org/pkg/sort/ I had to look at this example for a long time to get it... And now I have forgotten it again since it was months ago :-( I still thought it requires too many lines to sort stuff, but it is doable.
  • frou_dh 13y ago
    That's effectively subtype polymorphism, while generics are parametric polymorphism. Many languages (including Java) make use of both.
• facorreia 13y ago
  For fast execution of parallel processing over immutable data, I believe Scala would be an adequate choice. It would be a plus that it runs on the JVM and can easily interoperate with Java code.
• Kiro 13y ago
  Ok, so this is OT but can someone explain generics and their purpose LI5?
  • bstamour 13y ago
    It allows you write code that works for multiple types. For example, consider the following function in C++: template <typename T> T min(T a, T b) { if (a < b) return a; else return b; } This code works for any type T (ints, strings, floating point numbers) that can be compared with less-than. In a language like Go that does not support generics, you would have to write a min function for ints, a different min function for strings, etc.
    • Roboprog 13y ago
      Keeping in mind that in C++, "<" would need to be an overloaded operator defined by any type used for T. That is, to those of us non-C++ programmers, there is a function call (callback) dependency hidden in that templated function. Not saying it's a bad thing, just that most other languages would show something like "a.compare( b) < 0" to do something like this.
      • adrianmsmith 13y ago
        True, it's hidden, but the compiler will only compile code which uses that function for types which meet that condition. So yes it's hidden, but at least you'll find out about it at compile-time, not run-time, so it could be worse.
  • adrianmsmith 13y ago
    If you want to model a user's transactions you can create a List<Transaction> rather than just a List, and then - The compiler will fail to compile your code if you put anything in the list apart from a Transaction - The compiler will fail to compile your code if you try to do anything with an object from that list which a Transaction can't do - It also makes the code more readable as if my function takes a List<Transaction> you know what you can pass to it. Does it take a List<Transaction> or a List<TransactionId>? It's obvious. - If you try to pass a List<TransactionId> then the compiler won't compile your code. (Otherwise you'll only find out about it at runtime.) This means a lot fewer fails at run-time. Which in turn means a lot less time writing (and maintaining) unit tests.
• patrickaljord 13y ago
  That's ridiculous, we get articles complaining about the lack of generics in Go daily now. That's like complaining about the lack of type safety in ruby. Go warns clearly that it doesn't comes with generics. Need generics? Use something else, we all know Go doesn't have them. Nice way to get on the HN front page though.
• lafar6502 13y ago
  I'm not sure what can be said about qualifications of a programmer who doesn't know how many threads does his program run and why. And this is in Java, where the author says he's proficient. There's nothing difficult in checking how many threads are there instead of speculating on some unclear link betweeen 'final' keyword and multithreading. It's quite possible that bad performance is a result of poor implementation, not a fault of Go runtime. Unfortunately, there's no code to have look at.
• sigmaml 13y ago
  Author of the blog post here. Some of the comments here suggest that I was probably new to Go. Not quite. I was reasonably active in the Go community (and on golang-nuts) in the first two years of Go's public life. Also, when discussions of generics were taking place informally in the mailing list, I was one of the first to have actually written at least a half-serious `proposal' for generics (you can read it at http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-proposal-for-generics-in-go.html http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...). As for achieving `generic' code through static generation using an external tool, I had had considerable success with it in some earlier projects. Except that the number of types is much higher in this project, and things could not be as simply - or clearly - generated statically. I cannot publish the code because of the client's IP involved -- not because I fear criticism; see, I was ready to face _this_ criticism :-). Those of you who read my original post in golang-nuts may have already read that, of course!
  • fauigerzigerk 13y ago
    I found it a little surprising that Java's generics are a good fit for your task. Don't you have tons of boxed ints eating lots of memory? That's what I'm struggling with a lot when I do graph processing in Java. At that point I tend to resort to C++. Or do you use fastutil?
    • martincmartin 13y ago
      The 375 percent cpu is probably 1 thread of work and 2.75 threads garbage collection.
  • arnehormann 13y ago
    This is too late to help you, but still... BitSets: look at math/big - not that intuitive, but what you need is probably there. Sets: I wrote https://gist.github.com/arnehormann/6234573 https://gist.github.com/arnehormann/6234573 while thinking about an api. It's not a regular repository because I never needed a set type myself, but it should work. Like another commenter said, the cpu usage statistics in the Java program are most likely due to Java threads you didn't start yourself, e.g. the garbage collector. If your code involved creation and disposal of a lot of Objects, Go is at a serious disadvantage compared to the JVM. But that can be mitigated with a little effort and will probably disappear in due time.
• dschiptsov 13y ago
  Of course Java is the best solution for any problem, who could dare to think otherwise. It is mature, stable, incorporates millions of man hours (of solid mediocrity) and there are no shortage in coders and believers. http://chrisdone.com/posts/dijkstra-haskell-java http://chrisdone.com/posts/dijkstra-haskell-java
  • zvrba 13y ago
    Java of today is not the same as Java from 2001.
    • sixthloginorso 13y ago
      Dijkstra's argument was more about Haskell than Java... well, except the trash talk about Java's origins, you can't change those.
  • sixthloginorso 13y ago
    It has a state-of-the-art Virtual Machine, rich concurrency facilities (why does everyone forget this?), reasonable type safety, great tooling, and it operates within a diverse ecosystem of languages using the same infrastructure. But yeah, I have always liked the argument of throwing a curve ball at the kids who were already programming in imperative languages. It also levels the playing field and those who hadn't had any prior experience tend to perform better without feeling so inadequate next to their peers.
    • dschiptsov 13y ago
      Rich concurrency facilities based on pthreads and murexes provided by an OS, so no miracles here, just the same broken by design stuff.
      • sixthloginorso 13y ago
        Care to expand? I still find that Java's are some of the best concurrency libraries you'll find, among imperative languages or otherwise.
• tetha 13y ago
  I still smile when people get surprised by the performance of java. A bunch of people remember the loud people yelling "Oh Java is really slow and sluggish" while whispering "as long as you compare it to C++ with arbitrary optimization time, in a good use case". Truth is, java can be darned fast if you want it to be.
  • frou_dh 13y ago
    Java-based GUI applications often being ugly and sluggish perhaps unfairly tainted the reputation of the language and VM.
    • pjmlp 13y ago
      Mostly because they were developed by programmers that failed to understand how to proper use Swing. It is incredible how, regardless of programming language and UI toolkit, people still take the easy root and do heavy work on the UI thread. And don't make proper use of widgets customization capabilities.
      • frou_dh 13y ago
        C# with the WinForms API is the only desktop GUI programming I've done and I found both the process and results very pleasant. IIRC I was fairly well behaved and used the "BackgroundWorker" in a few places :-)
  • gizzlon 13y ago
    Truth is, java can be darned fast if you want it to be Yes, I'm not a Java programmer, but I'm convinced it can be very fast. But throw a rock and you're bound to hit an insanely slow Java GUI application or a web service that needs 10 times as many servers as any sane implementation would use (and cost X million of my tax-paying money.. fucking consultants :)
• maxk42 13y ago
  Anecdotally, I think that I'm noticing a trend wherein people coming from a strong Java or C++ background (or other strongly OO languages) object to Go vociferously (typically citing generics and a couple other pet peeves) and people coming from dynamic languages (or other languages lacking generics) seem to have no problem with it. I think it may be a matter of which paradigm you're approaching Go from.
  • RivieraKid 13y ago
    Possibly.I regulary use both static and dynamic languages and lack of generics was one of my biggest complaints. If it's a static language, I want generics. If the language is dynamic I don't really care (although some dyn. languages have generics).
    • maxk42 13y ago
      I thought it was a pain in the ass until I realized golang really does have a sort of dynamic parameter: func test(myVar interface{}) will accept any type at all. You can then use Go's type switch or a call to reflect.TypeOf() to invoke different behavior based on the parameter's type. To my way of thinking, it's pretty simple.
• stiff 13y ago
  I think there is more to learn here about engineering mistakes than about Go: - Why pick Go for this project in the first place? Those days the biggest productivity difference that arises from language choice comes from the availability of libraries, and it does not take much research to see that Go wasn't particularly targeted at numeric computing and that library support for those kinds of things is very poor. There is a number of mature platforms for this class of problems, SciPy, MatLab/Octave, C/C++ with various BLAS-derived libraries etc. - The bit on poor performance is unconvincing because the source of the difference has not been identified. The speculations about Go and Java that follow are so poorly backed by any evidence and so wild they should have been cut out from the article. It's clear that the author has no clue what really happens in either case, and he proceeds to draw conclusions anyway. This kind of "magical" thinking about black boxes one doesn't understand is unfortunately all too common across software engineering. - One place where I agree with the author is that Go's zoo of builtin data structures is really, really poor compared to Java. I mean compare: http://golang.org/pkg/container/ http://golang.org/pkg/container/ http://docs.oracle.com/javase/tutorial/collections/interfaces/index.html http://docs.oracle.com/javase/tutorial/collections/interface... http://docs.oracle.com/javase/tutorial/collections/implementations/index.html http://docs.oracle.com/javase/tutorial/collections/implement...
  • pron 13y ago
    ... and those don't even include Java's long list of concurrent collections.
    • jwn 13y ago
      Or the other Collection implementations offered by https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/.
      • jbooth 13y ago
        Or the ability to write collections in the first place, as enabled by generics. You can't even write a collection in Go unless you're dealing with interface{} or unsafe.Pointer and casting a lot. I really like the language, enough to use it and work around the lack of generics, but that's a glaring weakness. They need some way to enable container classes.
• SigmundA 13y ago
  What struck me is how naive the author is when he notices multi-core usage in a single threaded java program and proclaims: I still do not know what is going on inside the JRE as the program runs, but I am truly amazed by its capabilities! Yeah it's magic, it multithreaded my code, or um I don't know the garbage collector maybe?
• Almaviva 13y ago
  Am I the only one who thinks writing my own Set data structure (based on a map under the hood) isn't crazy at all?
  • frou_dh 13y ago
    If you're not the only one then you can all meet up in a month and each point out bugs in the other n-1 implementations.
    • Almaviva 13y ago
      Does a set do so much that you'd be worried about doing it wrong? Not to say having it in a common mature library wouldn't be an advantage, but it's something I'd be pretty sure I could implement and get right the first time. I'd be more worried about having two programmers write two implementations in the same project with subtly different interfaces, and having different parts of the code use each one. This is a cost and maintenance problem, but that's also a social and communication problem common to all projects.
      • frou_dh 13y ago
        Yeah, I was exaggerating a bit, but yes I think there could be room for bugs depending on what more involved operations are offered beyond basic membership tests. Anyway, have you seen the map[T]struct{} idiom for Go? Decent enough for the basic case.
  • mediocregopher 13y ago
    Nope, I posted this gist in a comment on the parent already: https://gist.github.com/mediocregopher/8319986 https://gist.github.com/mediocregopher/8319986
• zeroDivisible 13y ago
  Disclaimer: I use Java professionally on a daily basis and am learning Go in my free time. I totally agree with all the points which most of you make. Firstly, you should almost never choose a language / technology which you want to learn when you are being given paid contract task to accomplish. It might be different at your full-time position, when picking new tool (after agreeing with the rest of the team or people making decisions) might really be a viable choice, giving you an edge in the end. Beside that - if you're being paid by the hour, if you had been able to find a client who is willing to pay you for you to learn new stuff - stick to them as them as long as possible. Most of the clients with whom I had been dealing with would just fire me or terminate the contract. As for the performance - and I'm not defending Go here - with discrepancies that big, I'd just assume that I don't know language and all of it's quirks and it's just me not using it properly. I know that you might had spent time profiling and optimising stuff, but sometimes the overall design of your program might be violating some of the rules of given language, punishing you with performance issues in the end. (check http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ and the difference from first iteration to the last one, when people knowing each framework tested started pushing their favourite toys to give them an edge with misc optimisations) From the two language which you had tested, Java was a way better choice here - no amount of hype around a language should win over mature libraries which were just suited for your job. PS: and yes, I'd love to see generics in Go and can't understand any of the reasons for no.
• mratzloff 13y ago
  A Go templating project was posted here the other day: gotgo[0]. I haven't had a chance to use it yet, but it may alleviate some small amount of pain. As for poor performance, that is almost certainly a result of rampant object creation, rather than reuse. Not sure how much of his program was concurrent, how sophisticated it was, etc. Ultimately if the data set fit in memory, Python would probably be the appropriate choice for this kind of computation. [0] https://github.com/droundy/gotgo https://github.com/droundy/gotgo
  • pjmlp 13y ago
    > A Go templating project was posted here the other day: gotgo[0]. I haven't had a chance to use it yet, but it may alleviate some small amount of pain. Replicating the C++ code generation tools of the mid-90's when templates were started to be discussed at ANSI/ISO.
• _pmf_ 13y ago
  > However, considering the fact that statistics instances are write-only, I hoped that Go could help me make the computations parallel easily[1]. I'm actually dizzy from shaking my head too much while reading this.
• bwilliams 13y ago
  $GOPATH is my biggest issue with Go. I'd much rather have some sort of config file than have Go determine anything from my project path.
  • baq 13y ago
    i had my reservations too, but then somebody told me that GOPATH is like a virtualenv for python and then everything was nice again.
    • bwilliams 13y ago
      I'm not a Python user so I can't really compare. I still don't agree with it since it forces longer paths to get to your project, and I wouldn't really call it isolated.
• claystu 13y ago
  This is the kind of article we need more of on Hacker News. The author chose a newer language to build a real project in and then gave us an evaluation of how that language worked as a tool. This is far superior to the typical benchmark-game blogs that try to compare a few languages using only a small test program.
• corresation 13y ago
  "The general attitude in Go community towards generics seems to have degenerated into one consisting of a mix of disgust and condescension, unfortunately." I think this attempts to make the practical state of generics in Go into some sort of religious disagreement, which is unfortunate, as that isn't the case whatsoever. Whenever the topic of generics come up, the prevailing sentiment is that they would be great, but that the Go creators have some implementation difficulties and some competing goals that make it impractical at this time. I don't believe I've ever seen anyone of consequence in the Go community treat generics as anything other than "would be really nice". It is a gap in Go and is widely treated as one. Go absolutely needs more robust collection types, however. Total agreement on that.
  • fauigerzigerk 13y ago
    It's not a religious disagreement between the Go team and those asking for it. The Go team has simply stopped talking about it. But the reactions by the community to people bringing up generics on golang-nuts has become outright hostile.
    • corresation 13y ago
      That is more about group decorum than any technical debate. Generics have been discussed to death regarding Go, and there is a long and complex history of the choices and realities in Go. So it is understandable that people can get a little irritated when someone stumbles in and declares that maybe Go should add generics, usually then decorating their claims with lots of exaggerated hysterics (most recently that Go is an "embarrassment" because it lacks generics. Quite the accolades for the people who work long and hard on it).
      • fauigerzigerk 13y ago
        Refusing to debate the issue is not understandable at all, especially because the Go team has not rejected generics on principle. The most popular response to any language debate seems to be "it's not a problem in practice", implying all critics just "stumble in" and don't know what they're talking about.
• whizzkid 13y ago
  I still think that the way you are criticising the author is nonsense. I totally agree that programmers need to use the right tool for the job but; Most of the programmers will not know the core implementations of a programming language when they started using it.(even after a couple of years) This leaves them only one choice to decide if it can replace their primarily preferred language or not. Trying out the language. If it gives a bad taste from the beginning, doesn't ease the implementation, or better performance, then programming language won't have much chance, will not get attention and growing community. This is why Ruby got a popular community with the help of Rails framework. Developers found it very very easy to develop apps, it was very much readable code, and you save lots of time in order to get the app up and running. This advantages just made people ignore all the disadvantages of the language. (concurrency, being hell slow, etc.) As much as i want to try out Golang one day,code examples on internet doesn't blow my mind like "wow, how smart that is!!"
• puppetmaster3 13y ago
  You get a D in programming. (get it?)
  • eonil 13y ago
    Unfortunately, D's coroutine support isn't stable like Go's one. It has unclear stack size limit, it was simply impossible to me to make a robust D program which uses coroutine. (please correct me if I am wrong.)
    • puppetmaster3 13y ago
      When I code, my goal is not to find a problem that I can apply a solution on.
• midas007 13y ago
  I'm really missing Erlang's awesome binary structure bit-parsing/matching/twiddling. IMHO golang is extremely orthogonal, that it tries to live to an ideal instead of being most practical (ie generics). btw, folks should give Elixir a shot (pun intended).
• platz 13y ago
  I thought Haskell did not have issues with circular data type construction with its 'tying the knot' http://www.haskell.org/haskellwiki/Tying_the_Knot http://www.haskell.org/haskellwiki/Tying_the_Knot
• yanatan16 13y ago
  This guy needs to take a hard look at interfaces. Go didn't abandon generics, they just told everyone that interfaces are a better solution. You can write your code once as long as its formulated for interfaces. As for sets, why not use a custom data structure like a balanced binary tree (such as a red-black tree)?
  • xordon 13y ago
    BitSets have efficient set operations, eg: set intersection => bitwise AND, etc. see also: https://github.com/kisielk/bigset/blob/master/bigset.go https://github.com/kisielk/bigset/blob/master/bigset.go
• acqq 13y ago
  Note that the different readers in this discussion point out that the whole "magic" of article writer's Java implementation being so much faster is most probably the only thing that can run in parallel when you write the single-threaded program: the JVM's garbage collector. Which in turns means that the most of the "computation" performed is actually the creation and collection of the always new objects, which people who ignore the lower-level aspects of their programs consider being "zero-cost." Which is not.
• sigmaml 13y ago
  Author of the blog post here. Thank you all for your insightful comments and critiques. A few points. -> Several people have suggested that JVM's mature GC may be using other cores, resulting in the > 370% CPU utilisation. I admit that I do not understand the internals of OpenJDK's GC. However, I would like to point out that 100% of the roughly 1,200,000,000 statistics results instances created during one run are not released until the program terminates. They are all stored in statistics results containers until the very end of the run. However, see below. - From a processing perspective, other than the manipulation of containers and bit sets, almost all of the remaining processing is numeric. It is full of integers and doubles getting added, subtracted, multiplied, divided, square roots calculated, etc., as part of various statistical computations. - Where I needed sets was in preparing the several million working sets over which processing iterations occur. Working sets are prepared based on user's query criteria, several thresholds for filtering elements under a variety of constraints, etc. From a garbage perspective, these working sets are the biggest garbage generated during a run. - Go's numeric performance is certainly very good. I have had good experiences with it in other projects. - It is true that I could not identify the causes to which the performance differences between the Go version and the Java one could be attributed. Was I being naive? Am I incompetent? Possible. As I concluded, this behaviour may be obvious to more informed people, but it surprised _me_, and, that is what I admitted.
  • zhenjl 13y ago
    Did you by chance profile the Go program to see where the hot spots are?
• bdamm 13y ago
  In the comments he reveals that he didn't use channels. I think that's proof that he was writing Java code in Go syntax, which is not going to work out very well.
• deleted 13y ago
  [deleted]
• nice1 13y ago
  It sounds like this guy tried to program in java using Golang. This sort of thing usually fails.
• asdasf 13y ago
  His dismissal of haskell is rather misinformed. Haskell has no such problems with cyclic data structures. And this: >Except that abstracting things into functions that take the `old' graph as input, and answer the `new' graph as output are not very convenient or easy. Is just crazy. Yes, it is very convenient and easy: http://hackage.haskell.org/package/mtl-2.0.1.0/docs/Control-Monad-State-Lazy.html http://hackage.haskell.org/package/mtl-2.0.1.0/docs/Control-...