This is still insanity, but the insanity comes from Java EE rather than the apps themselves.
One can debug.PrintStack(), instead.
In Node, I remember wrapping Promisesromises into objects that had a stack for pushing messages onto them, so that the creator of a Promise could mark the calling site, and creating another Promise within that promise would pick up the chain of call site names and append to it, etc. Logging that chain when a Promise fails proved to be very useful.
Sounds complicated. I don't use Node much (nor recently, for that matter), but when I write f/end JS I capture the chain of function calls by creating a new exception (or using whatever exception was thrown), and sending the `.stack` field to a globally-scope function which can then do whatever it wants with it.
Will that not work in Node?
Sometimes a function or method is called very many times so trying to log them all is useless. But at the same time it can be the case that there are multiple callers of the said function. Then looking at a stack we can log just the case of some specific call-chain calling that function.
Replace Java with star and that statement still holds true (for some people).
Hence the statement that you can write FORTRAN in any language.
https://blog.codinghorror.com/you-can-write-fortran-in-any-l...
wonder if you read the article linked in my above comment before downvoting, and noted who it is by.
this is who it is by:
https://en.m.wikipedia.org/wiki/Jeff_Atwood
, aka the co-founder of StackOverflow, a q&a site which you have probably used zillions of times, if you are a dev of any kind at all. He is also the cofounder of StackExchange.
>In June 2021, Prosus acquired Stack Overflow for $1.8 billion, its first complete acquisition in the area of educational technology.[11]
so he should know something about what he said, right? unlike you.
You ever achieved anything like that?
goes on to suggest rolling your own buggy, slow, informally specified implementation of half of a stack trace printer
DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap implementations.
DI does not require any framework and I would argue you can’t write modular code without it. Most likely you are doing DI even in your manually written code.
DI requires that the deps come from outside, not that it's dynamically created. The opposite is that dependencies are created inside the unit. DI is about which part of the code owns the dependency. With DI it's some parent component, without DI it's the component itself.
DI with magic can simplify the management of component lifecycles, but it's entirely possible to do it without.
This is also the most common/preferred way Spring et alia implements their "framework-aided" DI, so that you can write unit tests easily without bootstrapping a Spring context (and it is just well-designed vanilla Java code).
Let's take the case of an object which represents a simple CRUD web service that needs to talk to a database to get some data. Here is what it looks like without dependency injection:
func NewService(databaseHostname, databaseLoginSecret string) (WebService, error) {
databaseConn, err := databse.NewConn(databaseHostname, databaseLoginSecret)
if err != nil {
return WebService{}, fmt.Errorf("Failed to create database conn for WebService: %w", err)
}
return WebService{
databaseConn: databaseConn
}, nil
}
func NewService(databaseConn DatabaseConn) WebService {
return WebService{
databaseConn: databaseConn
}
}
Ideally then there is a place in your application, possibly in `main()`, where all of the base services are initialized, in the required order, and references are passed between them as needed. This can include "factory" style objects if some of these need to be initialized on-demand.
Yes, but the point is 1) you don't have to write it yourself and 2) it does 'the right thing' even if your junior dev straight out of BS CS wouldn't know how to write it.
There are, of course, caveats and not all frameworks are created equal and any tool can be misused. But I find DI very useful. Personally I'd recommend Uber's Fx framework and underlying dig library.
Is it that people who like this kind of stuff write microservices for deployment on Kubernetes clusters?
I can't speak for the ecosystem / developers though; there are plenty of examples where e.g. HTTP request handlers are wrapped in several onion layers of middleware itself. But, there's also an emphasis on keeping things simple and lightweight.
What kind of middleware are you thinking of when you mention things getting bogged down?
Then you go on to explain how to recreate them by hand.
Please don't do this either. Read the stuff you want to log as additional attributes in your slog handler from the context, which you ultimately pass to `slog.*Context`
DI is necessary in every language that doesn't rely solely on global singletons. Passing dependencies as arguments to a function is DI.
What may not be necessary, are IOC containers automatically create objects and satisfy their dependencies.
One of the reason people needed a DI framework in Java is crazy "enterprise" configurability requirements and Java EE-based standards that required you to implement a class with a default no-argument constructor. If you're using a web framework like Jooby, Http4k, Ktor or Vert.x, you do not need a DI framework (source: we've written many modern Kotlin applications without a DI framework and we've had zero issues with that).
Of course, all of our non-toy Go applications are using dependency injection as well. Unless the code reviewer messes up, we won't let anyone configure behavior through globals and singletons.
No, it's so that you can have something else manage the lifetime and disposal of your services instead of doing this yourself. You don't have to be writing crazy enterprisey code to have the need for this.
I agree DI is simple, but 100% disagree that you can achieve this through a hand-rolled library without sinking a ton of wasted time.
I'd add that this is a last resort; errors should be handled and resolved as close to where they occur as possible. Having them bubble up to a central error handler implies you don't really want to do anything with it.
Exceptions pretty much make this the sane/default behavior, with rust-like ADTs with syntax sugar being close.
So instead of a stacktrace, you are - tracing the stack? Am I understanding correctly?
Because it just sounds like a manual version of stacktraces
Because it is. I don't understand it either.
This is like saying "I won't use source generators because it generates code I would normally write myself"
Like, yea no shit. THAT'S the point.
I made the switch to Go a few years ago. For those who are on a similar journey as the author, or the author himself, I suggest spending time with the Go standard library and tools written by Rob Pike and Russ Cox to get a handle on idiomatic Go.
It’s clear the author still thinks in Java, not go. Saying Context ctx for example instead of ctx context.Context. Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work.
I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.
Edit:
Regarding stack traces, it turns out you don’t need them. I strongly suggest a top level error handler in Go combined with a custom error struct that records the file and line the error was first seen in your code. Then wrap the error as many times as you want to annotate additional lines as the error is handled up to the top level, but only that first point in our own code is what actually matters nearly all of the time.