5 ms·

Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at

• klibertp 12y ago
  I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...
  • swasheck 12y ago
    Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.
    • Derbasti 12y ago
      It's corporate infrastructure that is the nightmare, not the fragmentation.
  • gejjaxxita 12y ago
    The drop in performance isn't just while learning. I worked somewhere where I had to regularly use TCL, Java, PHP, C++ and Python - each was the most suitable tool for the job (at the time the tool was written anyway) but the constant context switching caused a real and permanent performance hit.
    • klibertp 12y ago
      > but the constant context switching caused a real and permanent performance hit Maybe context switches were too frequent? Or the opposite, too rare, which could lead to repeating the learning overhead each time? Personally I didn't notice any slowdown due to switching between languages and technologies - other then at the beginning, when I was learning them.
      • nostrademons 12y ago
        For me, it's the infrastructure & best practices that's the biggest cost. There are degrees of language learning. I went through a "everyone should be a polyglot programmer" phase when I had about 3-4 years of experience, because I was then proficient - not expert - at about a half dozen languages. At that point, I knew the syntax and semantics of all of them, the common standard library calls that I needed for everyday programming, and most importantly, I could mentally map between constructs in my head. So I'd be like "This is a 'for x in collection' loop in Python, a 'for (String x : collection)' in Java 5, a 'for (var x, i = 0; x = collection[i++];)' in Javascript', a 'map (\x -> ...) collection' in Haskell". I'm coming up on 10 years of experience now, and I try to limit the number of programming languages I work with pretty dramatically now. What's changed is that I now think of a language as an ecosystem and a culture, rather than a set of things I type into a computer. The typing is automatic; instead I'm thinking of the level of "Well, if I use Mockito and JUnit for my unit testing, here's how I have to set up my Dagger modules, and I can use Providers there to give me a dependency graph of ListenableFutures that will let me kick off a whole cascade of RPCs when a request comes in, all without having to manually manage the sequence of events." And all of those libraries have gotchas and best practices that I've internalized, which I think need to page out if I start working with another ecosystem. (This was perhaps a bad example because I'm actually much more fluent with Python and Javascript than Java now - but then, maybe that makes it a good example, because it shows how much tacit knowledge is important even for a simple forum comment, let alone a working system.) So I can't really judge your level of expertise over the Internet. But I'll caution you that views on this can flip-flop as you gain more experience. It's important to really learn one language well before judging that everybody should be able to use multiple languages with equal proficiency. "Learning them" is a continuous process, and there're tips and tricks that are very specific to each language that you continue learning even decades in. [1] http://www.reddit.com/r/haskell/comments/cguuj/a_haskell_webserver_in_ascii_art/ http://www.reddit.com/r/haskell/comments/cguuj/a_haskell_web...
• _yosefk 12y ago
  First of all - yes they're "just tools" and that's pretty much what I said - Go is for servers and it won't "rule them all", and I wouldn't write the obvious if it weren't for the massive Go hype. Another angle though - a language comes at a massive cost of vocabulary (builtins and libraries) which dwarfs the cost of learning a new grammar (easy compared to natural languages though a cost in itself). A language suited for a narrow niche will still replicate a lot of libraries, tools etc. Whoever pays the costs, too many languages in one's toolbox, be it a person, a company or society as a whole, is not necessarily a net gain. So if Java could have gotten goroutines without having to make a whole new language... would Go be a good idea? (I don't know the answer and maybe it's practically irrelevant but it's an interesting question I think.)
  • klibertp 12y ago
    > So if Java could have gotten goroutines without having to make a whole new language... would Go be a good idea? http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/ http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/ "We’ll start at the end: Quasar and Pulsar are two new open-source libraries in Java and Clojure respectively that add Erlang-like actor-model (and Go-like coroutine/channel) programs to the JVM."