handsonscala VS spring-fu

I recommend people go through Hands-on Scala, by Li Haoyi, a fantastic developer in the Scala community.

You can have a look at https://www.handsonscala.com/ and see if that's for you!

his book, https://www.handsonscala.com/

Hands-on Scala Programming

is there a great resource, book or library‍ on classic Algorithms and Data Structures in Scala, e.g. similar in scope and quality to Sedgewick Algorithms in Java https://algs4.cs.princeton.edu/home/ I found a very helpful section on algorithms implementation in /u/lihaoyi superb Hand-On Scala Programming book , but unfortunately it's only a few pages (p.107-121). And most other books provide algorithms just an illustration for some neat language feature. The thing is, to get a job as Scala developer these days (in competitive firms) one needs to be a competitive programmer, master of Leetcode, and Scala doesn't seem to have strong ecosystem in that regard as Java, Python or C++. Edit: in DIY spirit and as a learning exercise i'm thinking of translating Sedgewick Algorithms from Java to idiomatic functional Scala, if anyone wants to join this effort or aware of similar ones please let me know Edit 2 (in regards to comments on 'reinventing the wheel' below): if Scala is so great as a language and functional programming flagship, where are all the libraries of functionally implemented algorithms replacing conventional CLRS style imperative/mutable implementations?

handsonscala is a great read for programming in general using scala. Especially if you're the practical kind of learner.

I will toot the author's horn for him. He has a great series of Scala posts on his blog [1] and his book Hands-On Scala Programming [2] is a great introduction to building real applications with Scala so that any experienced developer can understand and extend them.

I work at a small company that has been using Scala for 7 years. Some of the prior employees clearly enjoyed playing with advanced language features and writing libraries for the most general possible case even when that made it hard to understand how they were used for the 2 actual cases we needed to address in our application code. Akka, Cats, and Shapeless were all over the place.

Those earlier employees have churned off to other places and I have successively simplified the code they wrote that is still useful, while encouraging the use of no more language power than necessary in new development. Hands-On Scala Programming is the book I give new hires as a language introduction that shows the sort of style to be preferred. It's much more like super-powered Python than like Haskell.

I have written C, JavaScript, Python, and Scala for money. When I started on Scala I had never written Java nor used any JVM language. I have come to really appreciate the rich ecosystem of JVM libraries, the instrumentation and profiling tools I get, and many aspects of the Scala language and standard library. I love Scala's collections and miss their power and ease when I'm writing Python. (Which I still do for certain scripting tasks and for accessing Python-ecosystem libraries.)

[1] https://www.lihaoyi.com/

[2] https://www.handsonscala.com/

Also, many scala folks are not happy with sbt. There's a new build tool on the block Mill - https://github.com/com-lihaoyi/mill - by Li Haoyi . He's a scala master and he's written a _great_ intro to scala https://www.handsonscala.com/

I tried using wkhtmltopdf for rendering my book https://www.handsonscala.com/ to pdf, but in general I found it pretty buggy and unreliable. Lines of text would get split between pages, some CSS like flexbox didnt render properly, font sizes and page scaling was sometimes off (e.g. a big image on a page would make everything else shrink), etc. In general it "worked", but it didn't work well.

I ended up swapping in Google's Puppeteer library to render my PDFs, and despite needing a bit of plumbing to get my Scala build script talking to the node.js runtime, in the end it worked much better. Things looked the same in puppeteer PDF as they did in the browser, which is something I could never quite achieve with wkhtmltopdf

The point isn't that one should reinvent the way that Tomcat is started, but that Spring Boot (by default) is using action at a distance and runtime reflection which have serious downsides if you want to understand what's actually going on because you're a) new to the technology, or b) have to debug some weird edge case.

The alternative is using explicit, reflection-less code - which you can do even with Spring, although it's experimental: https://github.com/spring-projects-experimental/spring-fu

Bean Definition -> Still needed although experimental projects like Spring Fu might remove their need in the future. Technically, there is nothing to stop you from registering beans functionally right now but the verbosity is likely to make that approach less optimal.

Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place.

I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected.

I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem.

I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc.

Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things.

There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring.

This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently.

It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing.

Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.

> And that is a problem how? Stick to one style.

Switching an API from "a result or nothing" to "a result or an error message" happens all the time, and switching in the other direction is only slightly less frequent. And of course most programs have some APIs where one is appropriate and some where the other is. So consistency is valuable.

> https://github.com/spring-projects-experimental/spring-fu/tr...

Still reflection-based.

> There's nothing magical about it.

It's magical to anyone thinking in the language - it breaks the rules of the language, so you can't reason about what it does.

> Kotlin is an unmaintainable soup of features

Are you sure you're not confusing Kotlin with Scala?

> For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches

And that is a problem how? Stick to one style.

> In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot)

https://github.com/spring-projects-experimental/spring-fu/tr...

> and magical compile-time manipulation (Kapt)

There's nothing magical about it.

SpringFu (from Spring team): https://github.com/spring-projects-experimental/spring-fu/tree/main/jafu

It's mentioned in the article, even though the examples are written in Kotlin spring-fu supports a java-based dsl.

Longer term : getting rid of kotlin-reflect in Spring Framework by performing Kotlin reflection ahead-of-time and continuing to mature https://github.com/spring-projects-experimental/spring-fu for a more DSL-ish way of configuring Spring Boot are my favorite topics.

There is already a very close collaboration between Kotlin and Spring teams. I think leveraging more multiplatform capabilities and more DSL à la KoFu from https://github.com/spring-projects-experimental/spring-fu could increase Koltin usage on server side long term.

There's a next stage after annotations. The current thinking is to replace annotations with function calls. It makes more sense if you use Kotlin because Java is a bit verbose when you do this and in Kotlin you get to create nice DSLs. This cuts down on use of reflection and AOP magic that spring relies on and also enables native compilation. It also makes it easier to debug and it makes it much easier to understand what is going on at the price of surprisingly little verbosity. Kofu and Jafu are basically still experimental but work quite nicely https://github.com/spring-projects-experimental/spring-fu/tr...

Another trend is native compilation. Spring native just went into beta (uses the Graal compiler). That still relies on reflection but they re-engineered the internals to be more native friendly.

Spring Boot basically added the notion of autoconfiguring libraries that simply by being on the classpath self configure in a sane way. It's one of those things that makes the experience a bit more ruby on rails like. Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid).

Compared to XML configuration, Spring has come a long way. Separating code and configuration is still a good idea with Spring but indeed not strictly enforced. @Configuration classes can take the place of XML and if you use the bean dsl, that's basically the equivalent of using XML. Only it's type checked at compile time and a bit more readable.