4 ms·

I think Go is a pretty good choice for getting something out the door quickly, without getting in the way too much. The other week, I was working on two APIs:

I think Go is a pretty good choice for getting something out the door quickly, without getting in the way too much. The other week, I was working on two APIs: one for a team that uses Java primarily and another where I was free to pick the technology as needed and was looking in the direction of making it easy to deploy, even without containers, where I picked Go. With Go's standard library (and a few packages here or there), I had something up and running within a few days and it mostly just worked. Things that I wanted to do were just an additional method away, which, while not as sophisticated as the various convention over configuration options out there, kept everything very discoverable and observable. With Java, I had to setup a Spring Boot project and its security configuration mechanism (SecurityFilterChain, WebSecurityFilterConfig and lots of Filter implementations) and ran into issues where calculating file checksums for uploaded files broke because Files.exists() returned that files exist for ones with UTF-8 symbols in the name, whereas internally FileUtils.checksumCRC32() used file.isFile() which returned false. Then, I also needed -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 and for another mechanism had to look into JCE briefly, as well as configuring Maven to push packages to Nexus, as well as how to disable Spring Boot trying to connect to PostgreSQL and RabbitMQ while bringing up the app context for tests, or to connect to a special instance for tests (and hopefully eventually figure out how to automate a separate schema per CI run). Oh also deciding between OkHttp and Apache HttpComponents. Oh and also adding Apache Tika to the project, yet realizing that I can't add tika-parsers-standard due to some related dependencies. Now, this isn't a completely fair comparison because the APIs didn't need to do 1:1 the same things and I could have chosen not to go with Spring Boot, but it's so entrenched that it's most likely the majority of projects that you'll see out there (I also like Dropwizard, but I haven't seen many people use it at all). That might sour some people's perception of using that language professionally: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/ There are things about Go that are annoying, but it not having all of those levels of abstraction that you need to think about was comparably nicer. Plus, not needing to think about JDK versions and instead just getting a single file that you can ship. Oh, and on a related note, projects like Wails are also really nice (I tried Tauri, the builds were too long and the Electron bundles are a bit too big for my needs in some other projects): https://wails.io/ https://wails.io/ I like many of the languages out there (even Java and ones like .NET) but the projects and ecosystems around them can make them harder to use sometimes.

oftenwrong 2y ago
You were certainly bitten by the Java ecosystem, but I would agree that you hold some responsibility. Adopting Spring Boot so casually is really quite questionable. It's essentially opting to build your application within a giant, bonkers codebase. In the golang community there is a held value of using the standard library and tools, which is helped those being very good. I would suggest that Java is a better experience if you follow that same approach. If you want to serve HTTP, use the jdk.httpserver module. If you want to make HTTP requests, use java.net.http. If you want to interact with the filesystem, use java.nio.file. To build, use the included tools in the JDK. When it comes to cases where a third party dependency is warranted, such as use cases for Tika, you will have to deal with some questionable design decisions, but it's much easier when you have just a few libraries that you use by hand, and no insane framework trying to stitch everything together for you. For getting those dependencies, you are going to be acquiring them from public maven repositories, but I would suggest using Coursier or Maven Resolver instead of actually using Maven.
- KronisLV 2y ago
  > Adopting Spring Boot so casually is really quite questionable. The thing is, you don't always get that choice, at least in a way that wouldn't generate much opposition. If Spring Boot is what people use in most of the projects, opting for something else would generate lots of questions about that "inconsistency", especially as a part of the same team/project where services already exist that are written with it. Same as not opting for ASP.NET with .NET, Laravel with PHP, Django with Python, Ruby on Rails, Express.js with Node.js and so on. Same as for picking .NET in a "Java shop" or Java in a ".NET shop" or even wanting to use Vue when most other projects are made with React etc. I'm not saying that Spring Boot is always the right choice (god no, honestly everything from Dropwizard to the likes of Javalin and Quarkus etc. have their use cases), just that you'd have to be able to make that choice yourself in the first place, which isn't always the case. Same for Tika and other dependencies, which are often necessary evils: if you need to handle files and get their MIME types, will you just estimate what a file could be by looking at its extension, or do you actually want to look at the contents? And if you look at the contents, will you attempt the lazier approach ("Huh, this is an MS Office container type, no idea what's inside of it") or will you actually look for something more accurate ("Oh hey, this is an MS Office container type, with a Word document inside of it")? Then it becomes, do you want to spend the time reinventing that yourself or just have it done by the end of the day with an external dependency? Not that Go is immune from that, you'd still probably want to just use https://github.com/gabriel-vasile/mimetype https://github.com/gabriel-vasile/mimetype instead of building your own. Aside from that, it's nice that Go isn't so "enterprise" oriented (yet?) and that the standard library is so strong (whereas Java only got a built in server around JDK 21 IIRC). Edit: oh, also on my silly little list of jagged edges of Java, there's also the whole JUL, Log4j, Apache Commons Logging, Logback and SLF4J situation, whereas Go just has https://pkg.go.dev/log https://pkg.go.dev/log and it's nice. Not a horrible indictment or anything, I still use Java more or less daily, alongside other languages.

oftenwrong 2y ago

You were certainly bitten by the Java ecosystem, but I would agree that you hold some responsibility. Adopting Spring Boot so casually is really quite questionable. It's essentially opting to build your application within a giant, bonkers codebase. In the golang community there is a held value of using the standard library and tools, which is helped those being very good. I would suggest that Java is a better experience if you follow that same approach. If you want to serve HTTP, use the jdk.httpserver module. If you want to make HTTP requests, use java.net.http. If you want to interact with the filesystem, use java.nio.file. To build, use the included tools in the JDK. When it comes to cases where a third party dependency is warranted, such as use cases for Tika, you will have to deal with some questionable design decisions, but it's much easier when you have just a few libraries that you use by hand, and no insane framework trying to stitch everything together for you. For getting those dependencies, you are going to be acquiring them from public maven repositories, but I would suggest using Coursier or Maven Resolver instead of actually using Maven.

KronisLV 2y ago
> Adopting Spring Boot so casually is really quite questionable. The thing is, you don't always get that choice, at least in a way that wouldn't generate much opposition. If Spring Boot is what people use in most of the projects, opting for something else would generate lots of questions about that "inconsistency", especially as a part of the same team/project where services already exist that are written with it. Same as not opting for ASP.NET with .NET, Laravel with PHP, Django with Python, Ruby on Rails, Express.js with Node.js and so on. Same as for picking .NET in a "Java shop" or Java in a ".NET shop" or even wanting to use Vue when most other projects are made with React etc. I'm not saying that Spring Boot is always the right choice (god no, honestly everything from Dropwizard to the likes of Javalin and Quarkus etc. have their use cases), just that you'd have to be able to make that choice yourself in the first place, which isn't always the case. Same for Tika and other dependencies, which are often necessary evils: if you need to handle files and get their MIME types, will you just estimate what a file could be by looking at its extension, or do you actually want to look at the contents? And if you look at the contents, will you attempt the lazier approach ("Huh, this is an MS Office container type, no idea what's inside of it") or will you actually look for something more accurate ("Oh hey, this is an MS Office container type, with a Word document inside of it")? Then it becomes, do you want to spend the time reinventing that yourself or just have it done by the end of the day with an external dependency? Not that Go is immune from that, you'd still probably want to just use https://github.com/gabriel-vasile/mimetype https://github.com/gabriel-vasile/mimetype instead of building your own. Aside from that, it's nice that Go isn't so "enterprise" oriented (yet?) and that the standard library is so strong (whereas Java only got a built in server around JDK 21 IIRC). Edit: oh, also on my silly little list of jagged edges of Java, there's also the whole JUL, Log4j, Apache Commons Logging, Logback and SLF4J situation, whereas Go just has https://pkg.go.dev/log https://pkg.go.dev/log and it's nice. Not a horrible indictment or anything, I still use Java more or less daily, alongside other languages.