[liampulles]

At my last job I wrote web services using Spring (Java enterprise stuff). That was how I and a lot of my colleagues first learned how to write enterprise code: via lots of annotations.

Then I discovered Go and learned a different way to make systems. At first it was strange - where was the IoC framework? How do I build up my db entities?

And then I got into the philosophy of Go: how its better to make things that are clear rather than clever, and how its better to do things with an obvious control flow. In my current Go job, we wire singletons manually, build up our http server manually, and write raw SQL. It works gangbusters.

Please lets keep Go raw and simple.

[charlie0]

You're missing the entire point of frameworks like Spring and Laravel. They are there to remove the power of choice and thereby actually create clarity and maintain speed over a long period of time.

What happens with the "I'll build everything from scratch" apps is they are oftentimes not easy to understand, different patterns end up being used, 3rd party packages get slapped on ad-hoc and over time it just becomes a frankenstein. Much better to start with a hard set of rails that follow a set of conventions you just have to learn once.

The whole "I can move faster" without a framework is just an illusion that appears at the beginning of building an app. It will quickly disappear as more devs and complex code features are requested.

[jacurtis]

Yeah this is the positive side of the double-edged sword of frameworks.

Without Spring, you would have every team rebuilding the database layer in 100 different ways. With 100 shoddy attempts at documentation.

So for better or worse, having one framework-standard way to interact with the database, modify headers, or do any number of standard tasks makes life easier even if it enshrouds the underlying system in abstraction and layering.

[liampulles]

Keeping dependencies and standards in check to keep apps maintainable is important, and I agree that if you don't start with a big framework then there is more potential for it.

I have to say it's not something I've experienced in practice, mainly because the teams I'm on take such things seriously, but YMMV.

[rudiksz]

The whole "I can move faster" with a framework is also just an illusion that appears at the beginning of building an app. It will quickly disappear as more devs who do all have a different idea about how the framework should be used put their hands on it and as more complex code features are requested that the framework does not support.

[mdavidn]

This works in Java too. Wire up classes yourself and eschew the IoC framework.

[xyzzy123]

Java as a language totally lets you do this (and it's great!) but you'll be fighting the "culture" if you work like this in a bigger org.

In enterprise you have template repos and engineering fora where teams standardise-ish how things are done. This converges on the standard patterns, Spring, Micronaut etc.

Usually, you can deviate from these patterns at team discretion but you'll get questions from EMs and frowns from devs who roll on / off your project.

[jacurtis]

That sounds nice. Except find a company today that doesn't perceive spring framework and java as synonymous.

Tbh, its not a whole lot different than where PHP is going where php is becoming synonymous with Laravel. Wordpress is probably one of the last few bastions keeping that framework from fully owning the language.