I Prefer Maven To SBT as Scala Build Tool

To work with scala with pleasure and effeciency, I had tried SBT, maven, gradle from time to time, but at last I stay with Maven as my main build tool for scala. Although SBT is popular in scala community, and I had put a lot of time and attention to it before, let’s say: The chapter about SBT in “Real World Scala”(incomplete), https://github.com/CSUG/real_world_scala/blob/master/02_sbt.markdown How to write a SBT 0.10+ plugin?

BiasedScala: Initializing without new

In the old days, when we want to create some instances of some classes, we have to use the new keyword, just like this: val payloadOldWay = new JsonObject(); val message = new JsonObject It’s not a big deal in the most of the time, but when Scala3 comes, the new keyword is not mandatory anymore, I think it’s a small change BUT a big step, less keystrokes matter: val payload = JsonObject() Underneatch, Scala3 compiler will take care of the old new things, this time, scala team leave simple to user and leave complexity to themselves.

BiasedScala: collection converters should be gone

Scala offers its own collection framework besides java’s collections. But most of the time, I use more java’s collection than scala’s. So that means, I have to import converters to convert to or convert from java collections or scala collections. This is annoying in my opinion. Furthermore, in Scala2.12.x and Scala2.13.x, the collection converters are different, I have write down a note for this or put two code snippets in my Dash.

BiasedScala: extension makes a right way

I get to know extension is via Kotlin, After Scala3, extension comes to scala also. Cheerful, isn’t it? extension is an elegant way to extend types and classes. I use Commons-Lang3 library a lot to process string things, Let’s say, StringUtils.isEmpty(StringUtils.trimToEmpty(..)) or StringUtils.substringBetween(StrinUtils.trimToEmpty(..), .., ..), it’s necessary for precaution, but tedious, isn’t it? With Scala 3’s extension ability, we can make this more natural and elegant: extension (s:String) { def isEmpty():Boolean = StringUtils.

BiasedScala: I like Future more than yesterday

Although we have Executor/ExecutorService, even ForkJoinPool, most of the time, I only use Scala’s Future instead. Not because others are not excellent or no good, just because I feel natural to use Future. I had said, if the syntax of a programming language is the taste of it, then I like scala’s taste and stick with it. Same same, I like Future style instead of submit(task) or execute(runnable) styles, although the underneath mechanism is almost a same.

BiasedScala: Why I Chose Scala

I have been writing Scala code for many years, since sbt 0.11.x days. I checked a project that I open sourced many years ago when I was working at Alibaba, it tells me that it was 11 years ago. What time flies… In fact, I had tried many programming languages, so choosing Scala as the main programming language brings a lot thoughts and practices. Pragmatic I set up a big picture for a team that I think I would like to build and work in many years ago:

Biased Scala: Hello World

Before Scala3, you have to declare a wrapper object for a simple hello world program: object Main{ def main(args: Array[String]) : Unit = { println("Hello, World") } } When Scala3 comes, a great change follows. If we want to delare an entry method to run a program, we only need to annotate any method you want it to be the main with @main annotation, now, our hello world program becomes a simple one-linner:

Biased Scala之Hello World

Scala3出来之前, 写个简单hello world程序要声明一个object: object Main{ def main(args: Array[String]) : Unit = { println("Hello, World") } } Scala3出来之后,有了一个革命性的改善, 那就是main方法的入口直接用@main标注一下就可以了, hello world即刻变成one-liner: @main def hello: Unit = println("Hello world!") Scala3的编译器会自动生成外围结构,对于程序员来说,那些劳神子本就不应该操心,程序员是计算机语言的用户, 对用户来说,越简单越好,越少敲几次键盘越好。 编译器搞得好,就会把简单留给用户,把复杂留给自己。 再加上Scala3废除了很傻逼的package object,用Scala3写脚本也将成为更加赏心悦目的体验。 当然, Scala2.x也不是说不能写脚本, lihaoyi搞的Ammonite(https://ammonite.io/)也还不错, 但碰上Scala3就遭遇降级了,@main直接冲突,你有我也有,哈 (好在可以各自单独跑, ammonite的脚本用amm跑, scala3的用scala3去run) 之前用Ammonite写了满满一个workspace.amm(项目),但架不住自己是IDE拉扯大的程序员出身啊, 没有了依赖的自动管理和语法的自动提示,语法再简单,用来写复杂一点儿的脚本也是小痛苦的事情,所以, Scala2.x时代, 囧最终还是宁愿新建一个dirtyWorks项目,IDE里写,IDE里跑, 实在高频的脚本,那咱就编译成jar直接java -jar xyz.jar呗,甚至于想进一步追求性能与迅速可用,那就用GraalVM的native-image编译成native的可执行文件并加到PATH里去run呗! Anyway,我觉得Scala3里第一个走对了的路就是去除package object,而且还一@main解千愁。

BiasedScala: 开篇词

因为是个人对Scala的观点与使用上的裁剪,所以, 我称之为BiasedScala, 既带有个人偏见的Scala。 BiasedScala专栏将陆续分享出一系列个人在Scala上的一些观点、喜好与实践,本就小众,全做自娱自乐。 国庆节回家, 我妈饭桌上说了一句话我挺喜欢,别人教她用各种新的方法做鱼肉做鸡肉,但所有方法试过之后,还是觉得自己的方法做出来的口味更适合自己。 其实任何事情都是如此,没有试炼过当然没有资格或者没有意义去说这个东西我不喜欢,没兴趣,只有都试过了,才会选择一个适合自己的。 计算机语言就好象给程序员的一道道菜,喜欢吃那一口儿的都有,任何事物都有两面性,Scala也是,所以,我也只是采撷那些符合自己口味的Features为我所用, 终究是一种工具,终究是到达罗马的千万条大路之一,它终究不是目的,不要忘了这一点就行。 我们了解一个语言,除了了解它的哲学,也要了解它的生态,更要了解如何用它更好的达成自己的目标,当然,最好是在动手之前搞清楚,它到底适不适合自己的场景。 工具箱里工具多也有问题,那就是不知道用啥或者来回切换的成本更高,甚至影响效率,所以,大多数时候,我们就是一招鲜吃遍天,只要尽量规避劣势,发挥优势就可以了。

BiasedScala: Preface

Since the content of this column is ONLY my own point of view, so the name BiasedScala comes. Prejudices mayb. Scala community is small, so I don’t think this column will become popular, I just would like to write it. I went back to my hometown on vacation of National Day(China). My mom prepared several dishes for dinner. When we were eating, one of the topics we talked about which is the best way of cooking chicken.