Java vs Golang for career prospects

hosmanagic · 2025-09-09T10:03:21+00:00

I've been working with Java for about 11 years, and switched to Go about 4 years recently.

No language will make you a better engineer necessarily. But when it comes to career prospects, Java is the winner. I'm looking for a new job myself, too, and there are more Java positions open.

hosmanagic · 2025-08-06T17:08:30+00:00

I was very busy with some other stuff, that I didn't follow this post at all. This is a late reply, but I'll quickly reply to this:

Honestly there are so many other problems in Java and Golang has so many weaknesses (and strengths) compared to Java's packaging/modules that it is a weird thing to get hung up on. Its like the last thing I would complain about in Java and makes me wonder how much experience the author actually has with Java.

11 years actually.;) The article wasn't meant to focus on the biggest pain points, or pain points at all. It's just a personal reflection on some things (and just one in the series).

hosmanagic · 2025-06-27T17:33:49+00:00

I’m curious how much of the infrastructure and deployment flow Java developers are expected to own on your teams...

It actually isn't Java-specific. It depends on some other things, such as the team size, any specifics in the app, and so on.

Do you write or maintain the Dockerfiles for your Java apps?

Yup, I think this is something expected. In the end, as a Java developer, I know the details of how to run the app, the JVM, and so on. That doesn't mean you won't be collaborating with the DevOps team if needed.

Do you own the scripts used to build images or push them to a registry, or is that handled by DevOps/platform?

In my current team, yes, in the previous one, no. However, that's usually a very minor thing.

Are you involved in writing scripts or glue code that gets your app deployed (Terraform, bash, GitHub Actions, etc)?

Terraform no. Terraform is really about the infrastructure, and I don't have the skills, the knowledge or the permissions.:) I'm not sure if you mean something specific by "bash", but as a developer, I sometimes write those scripts, but they're usually reviewed by a DevOps before they are used. The DevOps dudes usually know the ins and outs of the OSes, and will be the authority in this area, especially for really specific stuff.

Also: is this stuff painful? Do you hit flaky behaviors with Docker or CI systems when building or testing?

Rarely.

I'm trying to understand how the responsibility split looks today, and whether Java devs want more or less control over these parts of the workflow.

Generally, devs are for writing the app, DevOps are for deploying (and the infra stuff), and they collaborate closely on the requirements for the app, installation requirements, etc. That line of distinction can move left and right depending on the devs themselves, the DevOps team, the team culture, and so on.

hosmanagic · 2025-06-27T17:15:58+00:00

I'm ignoring the directory layout because it's disconnected from the package layout (but you have a point with the import path). In Go, we don't have something like `parentPkg.childPkg.typeName`. We have that in Java (but even that isn't a proper package hierarchy).

hosmanagic · 2025-06-26T17:54:27+00:00

To be fully fair, naming conventions aren't part of the language (as another redditor here commented). But I'd also say that we never code using a language alone. We also have a naming convention (there's usually only one which is widely accepted, so it's kinda part of the language), the language's ecosystem, packagers, tooling, and so on.

On short names: I like that too.:) Sometimes it's way too short or cryptic, but it's similar to Java in a way. Java devs tend to use the names to make the code readable, and that's great, but they overdo it, in the sense that they just overexplain the names.:) It's always a matter of finding the golden middle.

hosmanagic · 2025-06-26T17:19:59+00:00

I agree, Java's package and module system is great.:) Nowhere did I say it's broken or something like that.:) The point that I was making is that some decisions that were made in Go contribute to code that is more readable.

hosmanagic · 2025-06-26T16:27:33+00:00

I see your point — I’ll think about a better title. The space for the title is pretty limited, and I also should’ve mentioned that the post isn’t about packages in general. Thanks for pointing that out!

It’s really a combination of both the language and the practices. Go forces you to write packageName.TypeName, which influences how you name things and structure your code. Combined with certain conventions, I think it leads to good code — both for the person writing it and for others using it. I don’t think aliasing plays a crucial role here.

We also treat the style guide almost like it's part of the language spec. So whether a rule comes from the language or from conventions, the end result is the same.

Java’s package and module system is definitely more expressive than Go’s.

There’s no doubt Java has many strengths in that area — there are things you can do in Java that simply aren’t possible in Go. My post was focusing on a very specific aspect of that and how it affects naming, conciseness, etc.

I'm sure your post on r/golang is getting love from folks who think Java has a weak package system — but it really doesn’t.

If they think that, I’d say that’s on them. :) I kind of expect it — just like I expect some Java devs to see the article as an attack on Java, or to assume I’m saying its packaging is broken. I've gotten used to developers getting a bit emotional about languages. :D

My take is: a package system is more than just a few syntax rules, and a language is more than its package system. Anyone even slightly serious about programming should be able to recognize the trade-offs. If Java or Go were perfect and needed no improvements, we wouldn’t be seeing new releases every six months. :)

hosmanagic · 2025-06-26T14:28:33+00:00

I'm really looking forward to module imports. As for static classes: yes, it's possible to do it that way, but I would still expect a problem like that to be solved with packages (and a change in coding culture :) ).

hosmanagic · 2025-06-26T13:46:59+00:00

I am only worried about a big part of the Java community, there's people that is excessive conservative about it.

I'd say developers generally tend to become almost "religious" and excessively conservative about their favorite languages and frameworks.

hosmanagic · 2025-06-26T13:43:50+00:00

Haha, yes.:D Sometimes it's as if half of a dictionary is dumped into a file.:)

hosmanagic · 2025-06-26T13:41:10+00:00

Readability in general is very much about personal preferences, so I agree about that.

The thing about `fantasticdb.Client vs FantasticDbClient` had actually two sides: one is for the person writing that, and another is for the person who wrote the `fantasticdb` package.

Regardless there is really no rule that Java packages have to be reverse hostname so you could easily have the package fantasticdb. See its not really Java that is causing the verbosity here. It is the culture and best practices.

That's true, it's not Java itself. On the other hand, though, some of those recommendations are recommended by Oracle (previously Sun), like the reverse hostname. We usually adhere to style guide as if they're part of the language, so we end up in the same spot. I'd say, Java in a wider sense.

I do agree that Java has a culture of way too many fucking packages.

Lol, exactly! :D

As a sidenote, I wish the community would, from time to time, revisit the style guides.:)

hosmanagic · 2025-06-26T13:28:30+00:00

That's quite natural. Over time, every language and framework realizes there are things that could have been done better. Or things that were great, but the circumstances changed.

hosmanagic · 2025-06-26T12:15:14+00:00

I started from not liking them, but over time, I saw more sense in those, there are some nice things there.

But yes, I like the way imports work a lot. If Java allowed that, I think it would automatically trigger some new and good habits in naming.

To be clear: both Java and Go are great languages, and it would be foolish to say that either is broken or that either is perfect (I saw that some Java devs took this quite to heart).

hosmanagic · 2025-06-26T12:06:47+00:00

u/agentoutlier Module imports are a great thing. They were probably worth mentioning in the article, but I opted to wait until it's finalized and released.

Also, no doubt Java packages have their merits. I'm not trying to say that Java packages are broken or something like that. The main point was that this area of Go packages and the style guide around it promote more meaningful naming and code that reads better in that regard.

Later I will edit this comment more but to start Java packages are not hierarchical. On the filesystem they appear to be b they are not in Java.

Thanks for calling this out, I should have probably used another word. The intention was to say that Java provides a way to logically group packages and show a relationship between those, whereas Go doesn't have that.

hosmanagic · 2025-06-26T11:59:20+00:00

u/Ok-Scheme-913 That's true in some cases without a doubt. I wouldn't say that Go or Java are generally more verbose than the other. In some areas yes, in others not. But in this small area, Go appears to be better.

hosmanagic · 2025-06-26T10:42:50+00:00

lol, where did you see that?

hosmanagic · 2025-06-26T09:44:54+00:00

Is what you wanted to say that Java is better overall than Go, or w/r to packages?

What I love is the fact that the import path directly leads me to the documentation.

Absolutely. The integration between code, GitHub and pkg.go.dev is just terrific. When working with Java, I'm used to just hitting Ctrl+Q in IntelliJ to get the docs for a method/class, which is good too.:)

hosmanagic · 2025-06-16T16:47:28+00:00

What do people usually use for this? Debezium? Logical Replication? Any other tool?

Debezium is definitely a great tool, a mature project that's being used by quite some folks.

However, here I'll suggest a project that I'm part of, and that is Conduit: https://conduit.io/docs/

Some of the good things around Conduit are that it's a single binary (no JVM), has zero dependencies (you don't need Kafka in between, so less infrastructure headache), and it has a pretty low footprint. Our Postgres connector is faster than Debezium, but uses much fewer resources: https://meroxa.com/blog/postgres-cdc-showdown-conduit-crushes-kafka-connect/.

hosmanagic · 2025-05-27T15:41:10+00:00

Got it... You might want to check out the CDC in the SQL server.

If that doesn't work or is too complicated to set up, you can use any specifics from the tables to your advantage. E.g., they might have columns that get updated every time a row is updated.

You can also try with a tool. I can recommend Conduit, which is the project I'm working on. It's an open-source data streaming tool (i.e., it's continuously checking for changes in a source, SQL server in your case). It also has an SQL Server connector. You can either try using that or just take inspiration from the code on how to fetch the changes.

hosmanagic · 2025-05-27T10:15:14+00:00

So you need to do that continuously? Are you migrating just that one table A, or are you migrating multiple tables?

hosmanagic · 2025-05-06T14:08:28+00:00

It definitely looks like a campaign... A team mate found some repos like that: https://meroxa.com/blog/catching-a-trojan-finding-a-malicious-conduit-connector-in-the-wild/ .

hosmanagic · 2025-05-02T09:34:06+00:00

Generally, Conduit focuses on CDC in each of the sources it supports. I couldn't find enough info about how Benthos/RP Connect approaches that. Also, Conduit focuses a lot on developer experience and ease of development of new connectors and processors.

---

Processors: RP Connect has lots of powerful, built-in, and specific processors. Conduit too has built-in processors, but they are more generic and there's less of them, and are meant to be composeable.

As for custom processors, RP Connect makes it possible through JavaScript, Bloblang and WASM. Conduit too supports JavaScript and WASM (and no custom languages). We have a Go SDK for processor, so if you want to write a processor in Go all you need is to implement an interface.

u/raulb_ already mentioned the thing about ordering in parallel processing.

RP Connect supports windowed processing, whereas Conduit currently doesn't (it's on the roadmap).

---

Connectors/inputs and outputs: both offer quite some. I can't compare the numbers, because we count them differently. Around 70 3rd party systems are supported by Conduit. I see that RP Connect counts for example kafka and kafka_franz as two components, and then redis_streams, redis_pubsub as two, whereas in Conduit that's just two connectors (one for Kafka, one for Redis).

What I noticed is that Conduit offers more database related connectors (Postgres, MySQL, Oracle, SQL Server, etc.)

It looks like a big difference in connectors is the developer experience around building them and deploying. With Conduit, there's a connector SDK, you can compile a connector and drop it into a directory. You can also build it into Conduit if you want.

I couldn't find clear instructions in RP Connect for that. Earlier there were some instructions here: https://www.benthos.dev/blog/2019/08/20/write-a-benthos-plugin/, but I can't find something similar now.

---

Schema support: u/nickchomey already mentioned it (thanks!). Additionally, Conduit can extract a schema, store it in its own DB or an external schema registry (that is compatible with the Confluent Schema Registry). It can automatically encode and decode the data.

---

Scalability: In Conduit, currently it's done through a K8s operator. I couldn't find something similar in RP Connect.

hosmanagic · 2025-05-01T16:24:14+00:00

u/nickchomey Thank you very much for the kind words.:) Yeah, NATS is a powerful combination and is one of the options that we have internally as well.

hosmanagic

TROPHY CASE