8 ms·

What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a ne

• _Codemonkeyism 9y ago
  Developers have the gain, company suffers, developers move on for higher salary with more skills, CTO is in it, doesn't fullfil his duty towards the company or investors, CEO has no clue and doesn't manage the CTO. The story I see over and over again as a startup CEO consultant.
  • nspattak 9y ago
    So if I get your argument correctly: Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool. The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working on sth small instead on working on the company's products. This skill is highly valued and the developers leave for an other company while the original one struggles to continue. Do you think that it may be the case that the problem in all these is not within the developers or tool? Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?
    • _Codemonkeyism 9y ago
      "Developers learn a new language that is faster to develop, safer and faster to run than existing solutions" Most often only in the eye of the developers with no proper evaluation. "Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?" Yes.
      • nspattak 9y ago
        Well, the "in the eye of ... with no proper evaluation" argument can be had for a lot of other aspects of software development and product management, doesn't it?
    • acdha 9y ago
      > Developers learn a new language that is faster to develop, safer and faster to run than existing solutions Would that it was that simple. Most of the time I've seen this it's been more like “writing new code is fun, fixing a bad design in our current code is too much like work” without factoring in the cost of rewriting, testing, optimizing all of the code which wasn't a problem relative to simply replacing the hotspot which was. Yes, sometimes a codebase is so bad that there's nothing of value to be preserved but that's pretty rare and unless it's some turd from an acquisition or consultants the odds are extremely high that the broken business culture responsible for the first bad codebase will cause just as many problems the next time around. That does happen but in my experience it's far less common than fanboyism or poor architectural/analytic skills — things like spending months rewriting a Python program in Go for a single-digit percentage gain because someone on HN said the magic pixie dust would make it faster and nobody checked whether it was I/O bound, spending most of its time in OpenSSL, etc. I've seen people propose rewriting code in C rather than optimize a database query because Real Programmers use hard things like C whereas SQL is beneath them. (I wish I was making that up) To be clear: I'm not saying that Go isn't a perfectly fine choice, only that our field is more prone to fads than we like to admit and most of the things which cause bugs or make people wait are decisions higher in the stack.
      • nspattak 9y ago
        I understand the situations you are describing and I still have the impression that the main problem behind this is inadequate leadership (and probably at several layers...). There are more than enough Real Programmers or lacking soft eng who are not experienced or knowledgeable enough to know when to use C/python/go/sql/etc but again for me the problem is either whover hired them and whoever is managing them. I also more than agree with the last sentence.
  • bn__ 9y ago
    And without developers there would be no product at all and no "work" for either CEOs or consultants. This Ayn Rand thing becomes more and more attractive every day...
  • sidlls 9y ago
    Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody else on the team has experience with, and which isn't used anywhere else in the company, and to solve a problem that is perfectly well solved (in both development time and performance) with the language and tooling we already use. As far as I can tell this engineer just wants to stick "built stuff in X" on his resume. He doesn't have a good reason to not use our existing stack. If I were the manager I'd demand more technical justification.
    • dmoy 9y ago
      To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.
    • criddell 9y ago
      I'm a senior engineer and I'm also the person that wants to use the shiny new thing. I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.
      • sidlls 9y ago
        The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.
    • richardknop 9y ago
      But this also might be a problem of a company not providing any improvement / career prospects for your programmers. If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc). You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it. I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be. You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things. It's like that analogy I have heard over and over again. CFO asking CTO: What happens if we invest in developing / training our people and they leave? CEO replies: What happens if we don't and they stay?
• fellowmartian 9y ago
  Using a compiled language is not a premature optimization if you're not sacrificing expressiveness. With that said, Go is not the best choice. Like, for anything.
  • hasenj 9y ago
    What would you choose instead?
    • wolco 9y ago
      For a website? PHP or Ruby. If you feel you have low level needs move to rust. If you want microservices use node. Go is a compromise of everything.
      • ssijak 9y ago
        Those languages that you mentioned compromise on much more than go.
      • plexicle 9y ago
        That is.. backwards in almost every way.
    • fellowmartian 9y ago
      Depends. If we're talking about high performance, yet expressive language without a steep learning curve, I say Swift. The only major drawback right now is lack of pure Swift AWS SDK. And unfortunately, AWS team has no plans to write one, yet.
      • didibus 9y ago
        I think any of the JVM languages like Java, Kotlin, Clojure, Scala, Eta, etc. The JVM as far as I know is still the runtime king, faster then Go.
    • lmm 9y ago
      The most general answer is OCaml, though in practice I'd probably use something else depending on the details. For most cases there's a better pick than OCaml, but I don't think OCaml is ever a worse choice than Go.
• crdoconnor 9y ago
  >they're generally a premature optimization This example actually seems to be the opposite of an optimization. There's 50% more code to maintain and there appears to be almost no appreciable benefit to compensate for that.
  • dx034 9y ago
    LOC is a bad measure for the complexity of code. Quite the opposite, expressive code can be faster to understand and easier to maintain than the same functions with half the code size. In any case, switching to a compiled language and static types should bring some benefit, in addition to the gain in speed.
    • crdoconnor 9y ago
      IME 95% of the time SLOC approximates code complexity just fine. Just because you can write horrendous 'clever' one liners in perl does not mean that most code out in the wild is like that. I certainly don't think the same author writing the same app in two different languages will be writing like that. Zero mention was made of bugs caught or customer-noticeable speed improvements so I'm inclined to think that there was actually no benefit to having static typing.
  • benhoyt 9y ago
    No, there was no appreciable user benefit, and that was intended. To respond to others: it wasn't a "premature" optimization, because it wasn't any kind of optimization. The sole benefit in this case was for me to learn Go programming -- and I noted that in the article title and intro. :-)
  • monktastic1 9y ago
    > There's 50% more code to maintain Given that Go is similarly verbose to Python, probably 100% more code.
• hasenj 9y ago
  Writing in a fast compiled language is not premature optimization. Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance. Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. Writing in a slow interpreted language is more like premature "deoptimization" (if that's a word).
  • crdoconnor 9y ago
    >Writing in a fast compiled language is not premature optimization. If the fast compiled language is equally expressive and equally fast to write then no. Those things are rarely (if ever) the case, though. It's certainly not true in this case. Go appears to be about 30% less expressive.
    • boomlinde 9y ago
      Another way to look at it is that Go expresses additional things that you can't express with Python.
      • erik_seaberg 9y ago
        In Go it's impossible to make for...range support user-defined types, and you have to write out every loop the hard way (and rewrite any loop that was using a builtin type). In Python you just define __iter__. That's what's meant by expressive, you can write what you mean instead of having to explain yet again how it should be implemented.
        • boomlinde 9y ago
          Of course they're different on that level of detail. In go, if you want programmable iteration behavior, you would create a channel that is fed values by a coroutine. Then you can range over it. It's not a new type, but that distinction seems a bit picky. What I am talking about is the static type system. You can't express that in Python, despite how much more convenient some of its features are.
• rjammala 9y ago
  How about this: once you write code in Go and test it well, you can deploy it and forget about it unless there is a hardware issue? I recently ported some C++ code to Go which processes 8 Billion events per day flawlessly.
  • joshuamorton 9y ago
    I feel like this is true for any language though. Once you write a well designed, well tested, and feature complete piece of software, you can deploy it and forget about it unless the server it's running on breaks. Go isn't special in that regard, unless there's something that makes Go easier to write, test, or deploy, which might be the case, but you haven't supported that.
    • rjammala 9y ago
      Our team was able to develop/deploy about 20 Microservices in Go in the past year or so which is really awesome. I can say this after having worked with several other languages.
      • abiox 9y ago
        how much of this would you attribute to the stdlib and popular libraries, vs the language itself?
        • rjammala 9y ago
          Strong stdlib definitely helps but the language itself is so refreshingly simple and very efficient.
    • plexicle 9y ago
      Any language that compiles to a static binary, sure.
      • joshuamorton 9y ago
• dwhabcdefg 9y ago
  I ported a Groovy/Grails app to Java/SpringMVC once. My technical motivations were more about moving away from Hibernate. Arguably there were plenty of reasons for leaving it as it was, though -- if I had known enough to be able to solve certain data access complexities back then, Grails was in many ways a better fit for the problem. The experience in a (more-or-less) functional language wouldn't have hurt any either. The business motivation was simple: Java/SpringMVC programmers are (or were then) far more plentiful, so adding/replacing tech resources was made much simpler.