4 ms·

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

by 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
      > If it relied on a JVM or Python/Ruby interpreter being present, at the correct version, it never would have gotten as popular, As far as I know, it's not hard to ship a JVM runner with the installer of your program, so this should be a non-issue.
      - thayne 4y ago
        And using a "virtual environment" with a specific version of the interpreter is a common workflow for python, and sometimes ruby
        jpgvm 4y ago
        Yeah but Ruby and Python aren't relocatable so it's hard to ship a self-contained interpreter with the program itself. This is due to their reliance on system paths among other things. You can trivially ship a self-contained JVM that is completely isolated within a single directory.
    - thayne 4y ago
      If it were created today rust might be a good option, although in the early days of rust, it probably wasn't mature enough. Although, it does require some amount of memory management, but to a lesser degree than c/c++. > Go offers a nice balance between performance and platform agnosticism I don't disagree with this. It's too bad the language itself has major problems (which I won't get into here). > I'm on the opinion that a DSL is better The two aren't mutually exclusive. What I want is a DSL embedded in a full programming language, like chef's dsl in ruby. > You want your infrastructure declarations to be easily readable and supportable. Absolutely. > 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 It's possible to write terrible and unreadable HCL too. I know because I've written some. > In any case, there's cdktf now, you can mix and match terraform with cdktf. Unfortunately, I haven't had a chance to look too deeply into it yet, although I definitely want to.
      - 4y ago
tragomaskhalos 4y ago
Sorry yes you were talking about transitioning from an existing Java situation and you're right, for the spaces that Java typically operates in I don't imagine there is much advantage in considering a switch to Go; it's as much an ecosystem factor as anything, the Java world has had a long time to mature, and while I dislike many aspects of it (assemblages of classes communicating in spooky hard-to-grok ways via oodles of config) it is at least battle-hardened.
- jpgvm 4y ago
  To address your last point I think that style of Java has fallen out of favour in recent years. It's still around, there is a lot of existing J2EE codebases but it's successor - Quarkus has done away with the vast majority of the config mess. I can't speak to how well it manages that transition though as I was never a big J2EE guy. The other old offender, Spring, developed a new convention over configuration distribution called Spring Boot which requires minimal configuration and has pretty much displaced the old way of doing things entirely. It's been around for years as the default option at this point. The way I see Java is that it moves slowly but tends to happily assimilate the best ideas from other languages, runtimes and frameworks and over time sheds it's warts (Java 8 era sun.internal.*, old Date/Time APIs, etc). Not everyone seems to have an up to date opinion of Java because the last time they touched it was J2EE days or worse yet in university.

by jpgvm 4y ago

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
    > If it relied on a JVM or Python/Ruby interpreter being present, at the correct version, it never would have gotten as popular, As far as I know, it's not hard to ship a JVM runner with the installer of your program, so this should be a non-issue.
    - thayne 4y ago
      And using a "virtual environment" with a specific version of the interpreter is a common workflow for python, and sometimes ruby
      - jpgvm 4y ago
        Yeah but Ruby and Python aren't relocatable so it's hard to ship a self-contained interpreter with the program itself. This is due to their reliance on system paths among other things. You can trivially ship a self-contained JVM that is completely isolated within a single directory.
  - thayne 4y ago
    If it were created today rust might be a good option, although in the early days of rust, it probably wasn't mature enough. Although, it does require some amount of memory management, but to a lesser degree than c/c++. > Go offers a nice balance between performance and platform agnosticism I don't disagree with this. It's too bad the language itself has major problems (which I won't get into here). > I'm on the opinion that a DSL is better The two aren't mutually exclusive. What I want is a DSL embedded in a full programming language, like chef's dsl in ruby. > You want your infrastructure declarations to be easily readable and supportable. Absolutely. > 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 It's possible to write terrible and unreadable HCL too. I know because I've written some. > In any case, there's cdktf now, you can mix and match terraform with cdktf. Unfortunately, I haven't had a chance to look too deeply into it yet, although I definitely want to.
    - 4y ago

tragomaskhalos 4y ago

Sorry yes you were talking about transitioning from an existing Java situation and you're right, for the spaces that Java typically operates in I don't imagine there is much advantage in considering a switch to Go; it's as much an ecosystem factor as anything, the Java world has had a long time to mature, and while I dislike many aspects of it (assemblages of classes communicating in spooky hard-to-grok ways via oodles of config) it is at least battle-hardened.

jpgvm 4y ago
To address your last point I think that style of Java has fallen out of favour in recent years. It's still around, there is a lot of existing J2EE codebases but it's successor - Quarkus has done away with the vast majority of the config mess. I can't speak to how well it manages that transition though as I was never a big J2EE guy. The other old offender, Spring, developed a new convention over configuration distribution called Spring Boot which requires minimal configuration and has pretty much displaced the old way of doing things entirely. It's been around for years as the default option at this point. The way I see Java is that it moves slowly but tends to happily assimilate the best ideas from other languages, runtimes and frameworks and over time sheds it's warts (Java 8 era sun.internal.*, old Date/Time APIs, etc). Not everyone seems to have an up to date opinion of Java because the last time they touched it was J2EE days or worse yet in university.