Probably works OK for a small project with a close knit team of skilled contributors where there's some well defined structure and everyone has sufficient high level understanding of that structure to know what kinds of dependencies are or are not healthy to have.

But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change, if shared memory makes it easy for folks to add direct dependencies between data structures of different components that shouldn't be coupled.

> But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change

You are describing the "microservice architecture" that I currently loathe at my day job. Fans of microservices would accurately say "well that's not proper microservices; that's a distributed monolith" but my point is that choosing microservices does not enforce any kind of architectural quality at all. It just means that all of your mistakes are now eternally enshrined thanks to Hyrum's Law, rather than being private/unpublished functions that are easy to refactor using "Find All References" and unit tests.

> through some kind of well defined interfaces

Every compiled language has the concept of "interfaces", and can load even compiled modules/assemblies if you insist on them being built separately.

The compiler will enforce interface compliance much better than hitting untyped JSON endpoints over a network.

Video games are very successfully built by huge teams as monoliths. As are some big open source projects like Linux and PostgreSQL.

I love the idea that I can compile all my functionality including HTML templates, javascript, and CSS into a single albeit huge Golang binary.

I have never done this yet.

But I love the idea of it.

You can already do this with Deno Compile

https://deno.com/blog/deno-compile-executable-programs

But that uses Javascript and Typescript, and I don't know those.

I guess I need to learn Javascript at some point.

This is what I'm doing with my side project! A set of personal smart picture frames for me and my partner. One executable does:

- the uploader API

- the uploader UI

- the frame API

- the frame UI

UIs are SSG'd with solid-js and solid-start then served with gin.

It's really fun.

I loved uberjars back when I was writing Scala. I don't miss much about the JVM, but I really miss having a single executable I could just upload and run without having to pay attention to the environment on the host machine.

That's essentially the role docker serves now. Everything you need to run in 1 single image.

Yeah, but building a docker image tends to be a lot heavier weight and slower, in my experience, than uploading a single jar

Heavier weight? Yes. Slower? Should be the same performance. Unless you are on a non-linux host, then there is no docker penalty.

The only time I can think where a JVM might be faster is if you have a multi-tenant setup. In that case, the JVM can be more effective with the GC vs having multiple JVMs running.

I didn't mean the application is less performant (indeed, it might be even more performant since there are more things we can tweak), but that the overall build + upload process is noticeably slower. I remember it taking <1 minute to rebuild + deploy an uberjar in 2016, and on an application of similar complexity today it takes somewhere between 3-15 minutes. Admittedly, this is a different company, language, and setup, so there are a lot of other potential differences.

Yeah, it'll be unrelated to docker.

Uberjars are (typically) extracting all the classes from jar dependencies and combining them into a single jar. That's all gzip compression work.

Container layers are simply saved off filesystem modifications. If you use something like Jib to build your image, then the actual deployable should actually be a lot smaller than what you could do with an uber jar. That's because Jib will put your dependencies in one layer and your application jar in another. Assuming you work like most everyone, then that means the only thing that usually gets transferred is your application code. Dependencies only get sent if you change them or the base image.

Great nick!