6 ms·

Meanwhile the place I work writes all microservices in go and all of my team's (DevOps) tools are also written in go...

• BoorishBears 6y ago
  I explicitly added the "ps" to avoid the situation where all the replies are fairly empty comment saying "Well we use it!" I get that you can use it for real work, I'm not saying you can't. I'm saying, even by design to some degree, it's not particularly enabling compared to other languages. That's meant to be a strength if anything, but I did not find the tradeoff of simplicity was able to overcome the additional effort it took to deal with what was missing There's an implicit ymmv here of course, because I'm not saying no one can find Go useful, I can see how in certain worlds with certain teams with certain priorities it'd all work out. It's just not for me.
  • murukesh_s 6y ago
    I have used Go in production. I found it roughly takes 2-3x additional time it takes to develop the same functionality in Node.js (with typescript). But it runs faster. If you want to write code that is probably not going to be thrown away it may be wise to invest the additional time in Go. However can't recommend that for building experimental code/APIs etc which are time bound and may/can get replaced (or split into micro services) in future if it becomes massively successful..
    • AlchemistCamp 6y ago
      And that's saying something give that neither Node nor TypeScript have ever had productivity as a main selling point! Imagine evaluating the time to market for an experimental back-end written in Rails, Laravel, Phoenix, etc vs Go! The difference is staggering.
      • konart 6y ago
        >Rails, Laravel, Phoenix, etc vs Go! Comparing frameworks and a language, really?
        • AlchemistCamp 6y ago
          Absolutely! There are obvious productivity differences between the languages themselves and frameworks can make it even more apparent. Different languages make writing the DSLs used in Rails-like frameworks easy, difficult or impossible. Much of my professional career was spent working on Node back-ends with a variety of frameworks and none of them were even close in terms of succinctness or productivity.
          • murukesh_s 6y ago
            Agree with that. However none of the frameworks comes closer to visual programming environments (nowadays called low code).
    • jtdev 6y ago
      Any examples of Node being faster to write than Go? Did this have anything to do with the plethora of npm packages available?
      • murukesh_s 6y ago
        Several use cases, of course more number of npm packages also easier concurrency, much more shorter syntax for async/promises, with ES6 you get closer to functional programming like map reduce etc. Also you can add or escape typing using Typescript. Single threaded architecture is a boon and good fit for web app middlewares. In golang sometimes you have to work too hard to get typings correct, concurrency is not straight forward in my view and error handling requires lot of repetitive code etc and of course lesser number of packages and difficult to hire developers.
        • jtdev 6y ago
          > "easier concurrency" In Node??? Have you actually written any Go code?
    • H1Supreme 6y ago
      This is purely anecdotal, and simply suggests you know Node.js better than Go.
      • murukesh_s 6y ago
        Could be, but it could also be that Node.js have much more libraries compared to Go, especially for databases, can escape typing if necessary using any, promise/async programming are much more easier with es6 (you can do a try catch without repeating etc)..array operations like map, reduce makes much easier to do quick and dirty functional programming etc. I can get much cleaner libraries for concurrent programming in Node.js lots of things you can do in Node.js takes roughly twice or more number of lines. Could be anecdotal, but say if I try another language such as Python I found it is more or less same as Node.js. Java is another language I can think that can slow you down. Of course the stricter typing, error handling etc can make for much more robust code in long run, but for someone who can afford to trade development time.
    • erik_seaberg 6y ago
      If I’m willing to take a productivity hit because I can’t afford the footprint of Scala/Java (or Typescript), I’d be thinking Rust. Go seems to fall somewhere in between without a clear advantage in either perf or clarity.
• AlchemistCamp 6y ago
  Go can be nice for simple domains where performance is very important. In most cases like that, I'd use Rust, though.