https://kotlinlang.org logo
Join SlackCommunities
Powered by
If anything, Kotlin is more approachable than Java...
# random
y
If anything, Kotlin is more approachable than Java (which is already taught in universities).
p
I know this is a popular opinion but I disagree with this too.
I think Kotlin makes no sense without Java.
For me, it is really a Java 2.0 rather than a new language.
Maybe it's just the stdlib for JVM though.. I haven't tried other Kotlin platforms
h
It's a better Groovy
y
True, you can't really be good in Kotlin without understanding the Java ecosystem.
I avoided Java like the plague because of memes a decade back and Kotlin was my first real introduction into JVM.
p
@Hong I suspect this too although I am not a Groovy expert
y
I dunno, it werks for me
h
i want a more expressive language w/ lambda support. groovy was close but never worked out for me.
btw, i also use kotlin native for Swift programming so it solves 2 needs for me.
p
Yeah, while people are busy hating on Java, we are busy building huge projects in Java + Kotlin. I am obviously very biased but I just don't see any ecosystem that would come even close to JVM.
y
Isn't Kotlin native still super slow?
h
it compiles to native codes after all. i'm not using it for UI, just shared libs for android and iOS
y
Yeah after I entered Kotlin and the JVM space, it all made sense. The standard libs are a lifesaver and more relevant in production than any other language I touched.
h
JVM is battle tested and proven to work and scale
y
Scales very well, only like 2x slower than C++. All my code is sustainable and I get expected results.
None of the global var hell that comes with python or other dynamic langs tbh
m
really?
y
For me, I just intuitively understand my project's structure a lot better with Kotlin. Probably because I've been working in it for so long now.
p
One of the big benefits for enterprise is how slowly JVM evolves. I am really worried about the future now that we are hopping on this super fast release schedule. I think it's a bad idea.
➕ 3
m
I feel like I’m constantly battling global variable hell (only we call it “the Spring Context”), I am surprised far more often than I want with surprise results (some standard library 1) mutated my object 2) isn’t thread safe). I’m constantly debugging framework methods that don’t do what their docs say.
y
Oh I use Spring too, the annotations can get quite frustrating sometimes.
p
I use Spring Boot and have had no issues regarding global state.
m
Name two beans the same name in different parts of your code base - one will be silently overwritten with no message.
y
I haven't had any big issues yet, but all I've done is enable security, login, account sign up, and some of the instant messaging.
p
Yeah, I mean Spring has its gotchas .. but you learn these things as you go.
y
@Michael Happened to me before! Took me like 2 hours to figure it out.
p
How about that 
@Transactional
is ignored if you call the method from the class where it is defined..
m
Yeah, doesn’t happen to much around security, etc;
p
It's all documented
y
I chose Spring because it's well documented. So a lot of these issues I run into are questions on stackexchange
m
but if you bring in spring batch, where every step requires 5 beans, every job 3 + steps * 5-
you start to really wish there was, you know, scoping of namespace in the context.
p
umm.. I just use the 
JobBuilderFactory
not everything has to be a 
@Bean
in my case only the 
Job
is a 
@Bean
m
I’m trying to use fewer - but then you have to know that if your writer isn’t a bean, you have to call 
afterPropertiesSet
on it.
p
you can wire the jobs manually, it's much better than polluting your context with all the beans
y
That's kind of cool actually. Is having a 
JobBuilderFactory
the preferred way of handling bean creation?
m
And you loose easy access to the jobExecutionContext, etc.
p
Honestly, I have no idea what's the preferred way because most of the info about Spring Batch I could find uses XML.
👆🏼 1
m
My jobs are all returned through the JobBuilderFactory, and my steps through StepBuilderFactory, but the return values themselves are beans; and so are many of the components of the steps (so that they can be `@StepScope`d
And it’s usually some 
fooWriter
or 
fooListener
that would get the naming conflict.
p
Yeah, we used to do it the same way but there is not a lot of reasons why it has to be this way.
y
Well at least Spring looks better on your resume than whatever the new hip web framework is at the moment.
I put Spring on my LinkedIn and I started getting a lot of recruiters bugging me.
m
hah! I’m less woried about my resume than my sanity.
When Rich Hickey says that clojure is a language for “cranky, tired, old programmers” I get all 😍
y
Hahaha, maybe it's a mid life crisis lang.
p
used to loved clojure
Kotlin is more practical for me though..
m
the barrier to entry on kotlin is really low.
My resistant coworkers have gotten productive pretty quick.
y
I have never seen a sad programmer working in Kotlin.
p
oh.. there was one guy the other day
claiming he has chronic depression and that seeing 
fun
all over the place made his condition worse
🤨 2
y
lmfao
p
he seriously asked for the keyword to be renamed or a way to replace it with something in IntelliJ
y
Reminds me of the slave/master hissy fit
tbh I always preferred 
func
but it literally doesn't matter.
h
lol... anyone from java background -> kotlin would find it enjoyable 😉
🎉 2
p
I find 
override fun
and 
suspend fun
combinations a bit disappointing
h
the bar is pretty low
p
suspending fun doesn’t sound like a good idea
y
Reminds me of that "no fun allowed" meme.
p
😢
l
Too much 
fun
would make it the normality, and you'd end up bored of 
fun
. That's why you need to 
suspend fun
to keep interest in 
fun
, and be even happier when it resumes!
2 Views
Open in Slack
PreviousNext
Powered by