Hacker News Reader

Comment by sorokod | Hacker News Reader

"Just write this...." adds an annotation

One of the many issues with Spring is that abstractions it provides are extremely leaky [1]. It leaks frequently and when it does, an engineer is faced with the need to comprehend a pile of technology[2] that was supposed to be abstracted away in the first place.

- [1] https://en.wikipedia.org/wiki/Leaky_abstraction

- [2] https://github.com/spring-projects/spring-ai

View on HN

I think about this occasionally trying to rationalize it. I see similar patterns in other things like R and Julia where they design something in the environment to seem like a composable tool, and maybe it is but only within two or three specific compositions and then the way the environment is described sure seems to imply some kind of universality but it just doesn't work. Some even seem to keep patching every leak (maybe Spring means Spring a leak? Haha) and there's a sunk cost fallacy thing with an immense documentation page.

There is similarity between Spring and "Buy now, pay later" schemes. You do often get a working feature quickly while having the price of evolving and maintaining that feature spread over some future.

This is the best I can do for rationalizing Spring.

In what ways are the abstractions leaky? @Tool or @GetMapping make no demands on how to implement “this is a tool” or “this is a GET REST endpoint.” That they’re coupled with Spring (or rather, Spring is the only implementation for the semantics of these annotations) doesn’t constitute a leaky abstraction.

This is fair. I think the complaint is that Spring is _beautiful_ in up to medium sized demos, but in any sufficiently large application you always seem to need to dig in and figure out what Spring is doing inside those annotations and do something unspeakable involving the giant stack of factory factory context thread local bean counter manager handler method proxy managers etc.

Also Spring is a kind of franchise or brand, and the individual projects under the umbrella vary a lot in quality.

Just about any tool will require a bunch of work at some point in the scale. Some front-load that, and some make it easy to get started but then you hit a point where you need to peek under the covers. Personally I prefer the latter, though I'm sure there's a lot of Stockholm syndrome involved in how I feel about Spring. And Spring's popularity means you're probably not the only one to hit any given problem.

This is a rational attitude but my experience is that engineers do not get to "the latter" at their leasure. What typically happens is that peeking under the covers is forced on them along with a tight timeline.

The precise semantics usually aren’t that well specified, and debugging is difficult when something goes wrong. Annotation-based frameworks are generally more difficult to reason about than libraries you only call in to. One reason is that with frameworks you don’t know very well which parts of the framework code are all involved in calling your code, whereas with libraries the answer usually is “the parts you call in to”.

Spring has more “synergy” in a sense than using a bunch of separate libraries, but because of that it’s also a big ball of mud that your code sits on top of, but isn’t on top of it in the sense of being in control.

I've been actively working with Spring since about 2008. About 3-4 times a year, I cuss and curse some strange side effects that occur during refactorings. And in some areas we've painted ourselves into a corner.

But all in all, it's a great set of frameworks in the enterprise Java/Kotlin space. I'd say it's that synergy, which makes it worth the while.

I'm curious, though. Is the use of dependency injection part of the portfolio of criticisms towards Spring?

Reply on news.ycombinator.com