Dean Wampler

Congratulations! Thanks for asking lots of great questions. Good luck with Scala.

-- Dean

Off hand, I can't think of a good resource that compares the features of the two languages like that. It would be great to have! Java has been evolving more quickly the last so many years, which is great. The language team even admits they've borrowed ideas from Scala and other languages. Adding lambdas in Java 8 was a massive step forward, IMHO.

Java still has quite a ways to go to be at feature parity with Scala, although that's not a goal for Java. The Java community works harder than the Scala community to retain backwards compatibility unless breakage is absolutely unavoidable. Brian Goetz, the language architect, has handled this masterfully. The Scala community, on the other hand, is more tolerant of changes (well, most of us are ;).

Hence, Java has some idiosyncrasies due to its history, in the type system and how you use types, in the limited form in pattern matching (case expressions) vs. Scala's, and other things that reflect backwards compatibility constraints. That said, a lot of organizations have decided that Java is a better fit for their needs. I respect that, even though it's not what I would do ;)

-- Dean

It could cause surprises. If you didn't put a return type on the method signature and you forgot the "=", it would infer `Unit` as the return type, even if the body ends with a non-Unit expression. You would probably find that error eventually, but it's annoying and the compilation errors could be mystifying, since the bug is a single missing character, "=".

For me, procedure syntax was a good example of a well-intentioned "convenience" that caused more harm than good, because you don't need a special syntax (you can write `def foo(...):Unit = {...}` to do the same thing) and having this syntax 1) was yet another way to do things instead of having one way to do them and 2) it caused surprises.

So you're right, this is one of several simplifications to the language with several benefits. Here's the full list of dropped features: https://dotty.epfl.ch/docs/Dropped%20Features/index.html

-- Dean

While I hope all of you will buy my book ;^) here are some references you might find useful:

My book page has links to more information: http://programming-scala.com

My short summary of changes: https://deanwampler.github.io/scala3-highlights.html

My blog series about Scala 3: https://medium.com/scala-3

The official Scala 3 documentation: https://www.scala-lang.org/download/scala3.html

-- Dean

Hi, Mohammed,

Thanks for the best wishes! It's good to consider the career implications when choosing languages. Scala developers are in short supply, so the demand tends to be good. However, even learning a language just to provide a broader perspective is a good career skill. I've started learning Go recently, since Domino Data Lab uses Kubernetes, for example. There are ideas I like in Go, as well as things I don't like ;)

What Scala will teach you (and the reason I started learning it back in 2007!) is how to do functional programming, while providing OOP for its strengths. I like FP because it provides greater rigor, so fewer bugs, and it leads to more concise code. That's why I continue to prefer Scala over Java.

So, pick a language to learn every now and then for exploring new approaches, but also pick one occasionally because it's popular in the industry you are in or want to be in, like Go, for Kubernetes and other systems programming, and Python, for Data Science.

-- Dean

Hi, Gayathri,

The JVM ecosystem doesn't have the breadth of data science tools that exist in the Python ecosystem, so most people use Python for Data Science. There are some notable data tools with Java/Scala APIs, like Spark and TensorFlow's Java API. I would love work on this problem myself, if I had the time.

There is one cool approach, https://github.com/shadaj/scalapy makes it possible to call Python APIs directly from Scala. I haven't tried it enough to investigate potential performance issues, etc. It's also still fairly new. However, for teams that want to work in Scala, it might be a great solution.

-- Dean

Hi, Alex,

If you are working on a Scala3 code base only, then definitely just learn extension methods, givens, etc. Unfortunately, most people will work with mixed Scala 2 and 3 code bases for a while, so you have to understand both forms. They interoperate well, fortunately. I provide in-depth coverage of both forms in the book, for this reason.

I don't recall that you need to use implicits a lot when writing Spark apps, even though it uses them in the implementation. So that might make things easier.

Therefore, I think I would learn about extension methods, etc. first, because I think the new idioms are better at showing good uses for these powerful capabilities. Then you might need to learn the syntax for Scala 2 equivalents, but hopefully the core ideas of why they are useful will already be familiar.

-- Dean

Hi, Peter.

Scala is quite flexible for everything from "scripts" (although JVM startup time is an issue) to compiled services, like typical Java apps. I don't think Scala 3 features changed this very much, except for small tweaks in how Scala scripts work.

If you really wanted to do as much as possible with one language and its ecosystem, you can cover a lot of ground with Scala. If you're willing to use multiple languages or pick one that's best for the majority of the tasks you do, then a few alternatives would be:

1. Python - Cross-platform portable scripting tasks for which bash is typically used. Also most data science work.
2. Go - Systems programming from small apps that go beyond what bash is capable of to full-fledged, compiled services. Especially interesting if you're working a lot with Kubernetes.
3. Typescript - If you mostly writing front-end/web stuff.

The size and performance of your apps play a role. If you're comfortable with Python and Flask, and you don't have heavy production requirements for scalability, observability, etc., etc., then why switch? Even if you have those requirements, maybe you can push a preferred tool set as far as necessary.

Hope that helps...

-- Dean

Oh, I forgot about that book! I have it on my reading list ;) Thanks for mentioning it.

-- Dean

I like the concept of BDD, but I strongly dislike the verbosity of BDD DSLs, along with the idiosyncrasies of their DSLs and the difficulty remembering them. Those DSLs are fine for the original intent of BDD, to communicate with stakeholders, but for tests that developers read and write, I prefer native idioms of the language with a helper library where needed. You already know the language and you can be concise.

ScalaCheck is used for property based testing, which I think is the strongest approach we have to correctness, besides what the types can enforce.

Suppose you write a type to encapsulate currency. Presumably it must obey accounting rules for addition and subtraction, multiplication by percentages (e.g., for computing taxes), have strict rules for rounding off to a desired number of decimal places, etc. These are properties. Tools like ScalaCheck (or the original framework in Haskell, called QuickCheck) make it easier to verify these properties.

Here are a resources that explain property-based testing:

https://increment.com/testing/in-praise-of-property-based-testing/
https://medium.com/criteo-engineering/introduction-to-property-based-testing-f5236229d237

I didn't spend a lot of time on this topic. The language itself was a lot to cover! I briefly discuss the choices in the "tools" chapter.

I used MUnit (https://scalameta.org/munit/) because it's very lightweight. I've decided I dislike all the dialects the better known tools provide. Also, MUnit was available for early builds of Scala 3 ("Dotty") before ScalaTest supported it, so that helped when I started the 3rd Edition. MUnit also integrates with ScalaCheck, which is a requirement for me.

At work (Domino Data Lab), we use ScalaTest.

This is for the import wild card only. (For type wild cards, '?' will now be used!)

They decided that since most languages use '*', why not Scala? So, yes, that does feel more like Java ;) The rare case when you want to import a '*' method is supported by doing "import foo.bar.`*`".

So, Scala 3 stills uses '_' for placeholders, but different characters for wildcards.

-- Dean

I feel your pain. This is so common and so damaging when people lack the maturity and perspective of what's best for the whole team and project. I mentioned that Scala attracts FP advocates. Sometimes they try to hard to live on the edge, causing problems for their colleagues.

I hope my book is pragmatic enough to help people avoid those mistakes. I did try to discuss pros and cons of many constructs and programming styles, such as "category theory".

-- Dean

Brian Goetz, who is Java's amazing language architect (amazing because of his brilliant balancing of backwards compatibility vs. the need to evolve), once joked that Scala is the laboratory for new features in Java. That's not too far off ;)

It certainly will make Scala easier to embrace for Python people. It also makes Scala even more concise without the braces. That's why I decided I like the new syntax and use it for my Scala 3 projects. I was opposed to it at the beginning. I think it will also appeal to instructors teaching programming and computer science, who like the clean, simple syntax of Python.

I'm not sure I would recommend converting a legacy code base over, although the compiler can do some code rewriting for you! At the very least, I wouldn't mix the two syntaxes in the same code base, but standardize on one or the other.

All that said, I think it will be the default syntax everyone uses within a few years.

-- Dean