https://kotlinlang.org logo
Join Slack
Powered by
This is a project that 20 people have spent 2 year...
# arrow
s
This is a project that 20 people have spent 2 years working on - it's all kotlin, spring, spring-mvc, jpa, hibernate. Basically your typical enterprise java app but in Kotlin. It's well written, well tested. I've just spent 8 years doing Scala full time and this is now my first Kotlin role and I'm finding it hard to justify ditching spring, etc and doing things in a more functional way. Arrow is just one part of that. No one uses any of that stuff in Scala land.
d
Spring is consistently first-in-class as far as a one stop shop for enterprise JVM applications. That's why I hate it 😂
Reflection is Spring's strength and its weakness. It allows you to do lots of stuff pretty painlessly, but it also leaves you lost and flailing if you happen to get something wrong.
s
@Transaction is pretty useful
As is the config support
d
transaction { /* do your thing */ }
is better 😉
s
Where does transaction get its datasource from
d
probably a receiver param... I'm pseudocoding
s
Do you shove it in a global var or ...
d
nooooooooooooo
s
Receiver param means passing it down the call stack
d
Yep, there's still a need for DI
TBH I've been hoping to see something with the caliber of Spring using all the power of modern type checkers to eliminate runtime overhead and push runtime errors to build time
But someone's got to invest the time and invent it first... 😕
s
I'll invent it next week
In the meantime...
Spring DI is the best way to do it... is not the answer I wanted loool
d
The weakness of 
@Transaction
is that some runtime engine must identify the method reflectively, wrap it in a dynamic proxy that handles transaction management, and then hand the proxy to the consumer, at boot time
s
It's not a weakness if you don't care about that
If you see what I mean
If I try that argument I'll be met with so what
Especially when it's working well in current projects
d
Yes, "all that stuff just works so what if it's complicated" is a compelling argument.
s
It all works and loads of people use it no bother exactly
I think it's bloat and too magical and I never missed it for one second in scala land
d
I would say, you're tied to a container, and that has baggage. You sacrifice some understanding of what happens and some ability to reason about your code (roughly corresponding to "safety" - I should probably formalize this argument better lol) for convenience.
Yeah, "magic" is the key here
Stream of consciousness warning because this is brand new in my head, I haven't had enough coffee and I've never written this down anywhere:
I was listening to LOTR on audiobooks this morning and they got to the elves of Lothlórien talking about how "magic" was a meaningless word to them; it's just a craft that Elves happen to know how to do - and that got me thinking about how too often we use abstractions in software to defer our thinking about how something happens, rather than enhance it.
"If I use @Transaction, Spring will wrap this code in a transaction"
vs something like 
fun <R,A> transaction(suspend f: (R) -> A): (R) -> IO<A>
which tells you from its signature alone about what it's doing and won't let you get away with anything stupid
like marking a method @Transactional on a non-injected bean
3 Views
Open in Slack
PreviousNext
Powered by