5 ms·

There is really no reason to go from Java to Go. Go may win out in the early days of a program for resource usage and perceived complexity but by the time your

by jpgvm 4y ago

There is really no reason to go from Java to Go. Go may win out in the early days of a program for resource usage and perceived complexity but by the time your team has cooked up some frankenstien of an application framework and tried to standardize logging, metrics, etc you would have been better off in JVM land from the start. At least then you can pick battle-tested and supported frameworks. Python, Ruby, JS/TS -> Go is a weird one though. I can understand why when people make that transition they think Go is the best thing since sliced bread. It's by far one of the easiest languages to learn, it's miles faster than what they are coming from and the tooling is way less shit than those interpreted languages. However all of those languages represent a very very low bar. I think if the same people could be convinced to try Kotlin (or even modern Java) they would be a) surprised how easy it is these days and b) finally understand that it's ecosystem and tooling that really matters at the end of the day. Though I have to say Go existing is by and large a good thing even if I don't like it. It helps get people off things like Typescript which are absolute garbage-tier onto something half-reasonable. When they grow out of Go they generally end up somewhere better, just takes a few years.

tragomaskhalos 4y ago
One area where Go has quickly established a niche is in tooling, for example Terraform. Here the benefits of being able to run a single (non-containerised) binary vs having to fret about what version of Java your punters happen to have installed in compelling no?
- jpgvm 4y ago
  Yeah that is fair. By and large such tools remain smaller codebases so it's flaws aren't as apparent either. My personal preference for such tools is Rust but it's admittedly a harder sell. Comment above is mostly addressing the server software use case with larger teams and 100KLOC+ (either one or many programs). I don't think anyone was using Java much in the CLI niche. It was dominated mostly by Python and Ruby (and Perl before that) before Go came along. I do think Go represents an improvement on that status quo.
  - sofixa 4y ago
    > By and large such tools remain smaller codebase so it's flaws aren't as apparent either. Kubernetes, Docker, Terraform and their respective ecosystems really aren't what one would call a smaller codebase.
    - jpgvm 4y ago
      Hence the "by and large" qualifier. There are certainly exceptions.
    - thayne 4y ago
      I often wish terraform wasn't written in go. Usually while making a patch to it, or reading the source code. Though not as much as I wish that terraform had used an existing "real" programming language rather than creating HCL.
      - sofixa 4y ago
        Terraform not written in Go wouldn't have existed. If it relied on a JVM or Python/Ruby interpreter being present, at the correct version, it never would have gotten as popular, and if it were statistically compiled C/C++ it would have never gotten as far and as quickly. Go offers a nice balance between performance and platform agnosticism, features like parallelism without it being too complex to write. Manual memory management would have been a useless obstacle wasting developer time for little real gain. Fighting the language to have parallel execution, easy crosscompile, etc. why? As for HCL, I'm on the opinion that a DSL is better. It's even in the name, Infra as Code, not with code. You want your infrastructure declarations to be easily readable and supportable. Anyone who has used Terraform can read any HCL; your Python code doing the same could be terrible and unreadable by anyone not already on your team. Too much flexibility for something as critical can end badly, imho. In any case, there's cdktf now, you can mix and match terraform with cdktf. Disclaimer: I work at Hashicorp, opinions my own and have stayed the same since before joining
        azth 4y ago
- Groxx 4y ago
  I'm not fond of Go, but yeah - it has completely replaced Python for my command-line-tool building and I'm much happier with it. It's almost enjoyable for that. A lot of things about Go work out well in practice when there's a human watching it that can just slaughter the process if it starts going off the rails, and the trivial distribution and excellent startup performance make it almost perfect for CLIs. Small code works fairly well, and the sometimes-quite-yolo stdlib gets you to "works on my machine" for 99% of your needs quickly and that's often good enough for ad-hoc tooling (and when it isn't: just delete that non-UTF-8-named file, sheesh). For large stuff? No please. The type system is far too weak, and the runtime has too many sharp corners. About the only thing I like about it for this is that runtime reflection is very tightly restricted, which prevents some of the worst insanity you see in Java.

by jpgvm 4y ago

tragomaskhalos 4y ago

One area where Go has quickly established a niche is in tooling, for example Terraform. Here the benefits of being able to run a single (non-containerised) binary vs having to fret about what version of Java your punters happen to have installed in compelling no?

jpgvm 4y ago
Yeah that is fair. By and large such tools remain smaller codebases so it's flaws aren't as apparent either. My personal preference for such tools is Rust but it's admittedly a harder sell. Comment above is mostly addressing the server software use case with larger teams and 100KLOC+ (either one or many programs). I don't think anyone was using Java much in the CLI niche. It was dominated mostly by Python and Ruby (and Perl before that) before Go came along. I do think Go represents an improvement on that status quo.
- sofixa 4y ago
  > By and large such tools remain smaller codebase so it's flaws aren't as apparent either. Kubernetes, Docker, Terraform and their respective ecosystems really aren't what one would call a smaller codebase.
  - jpgvm 4y ago
    Hence the "by and large" qualifier. There are certainly exceptions.
  - thayne 4y ago
    I often wish terraform wasn't written in go. Usually while making a patch to it, or reading the source code. Though not as much as I wish that terraform had used an existing "real" programming language rather than creating HCL.
    - sofixa 4y ago
      Terraform not written in Go wouldn't have existed. If it relied on a JVM or Python/Ruby interpreter being present, at the correct version, it never would have gotten as popular, and if it were statistically compiled C/C++ it would have never gotten as far and as quickly. Go offers a nice balance between performance and platform agnosticism, features like parallelism without it being too complex to write. Manual memory management would have been a useless obstacle wasting developer time for little real gain. Fighting the language to have parallel execution, easy crosscompile, etc. why? As for HCL, I'm on the opinion that a DSL is better. It's even in the name, Infra as Code, not with code. You want your infrastructure declarations to be easily readable and supportable. Anyone who has used Terraform can read any HCL; your Python code doing the same could be terrible and unreadable by anyone not already on your team. Too much flexibility for something as critical can end badly, imho. In any case, there's cdktf now, you can mix and match terraform with cdktf. Disclaimer: I work at Hashicorp, opinions my own and have stayed the same since before joining
      - azth 4y ago
Groxx 4y ago
I'm not fond of Go, but yeah - it has completely replaced Python for my command-line-tool building and I'm much happier with it. It's almost enjoyable for that. A lot of things about Go work out well in practice when there's a human watching it that can just slaughter the process if it starts going off the rails, and the trivial distribution and excellent startup performance make it almost perfect for CLIs. Small code works fairly well, and the sometimes-quite-yolo stdlib gets you to "works on my machine" for 99% of your needs quickly and that's often good enough for ad-hoc tooling (and when it isn't: just delete that non-UTF-8-named file, sheesh). For large stuff? No please. The type system is far too weak, and the runtime has too many sharp corners. About the only thing I like about it for this is that runtime reflection is very tightly restricted, which prevents some of the worst insanity you see in Java.