Why scala is needed




















I am assuming that if you read this book and take up Scala programming you will be writing programs that have all of these benefits. On top of this, taking up a functional programming language like Scala will help to shape how you view the concepts of data mutability, higher-order functions, and side effects, not only as new ideas but how they apply to your current coding work and designs.

Not that life is all about coding, of course. Nor does the work schedule of average software engineers involve more than half of their time spent actually writing code.

That should be reason enough to learn something new. This post is part of our ongoing exploration into what it takes to actually be a software engineer. Skip to main content. Latest Articles.

How Scala will help you grow as a Java developer. They represented the fundamental way to abstract over context, with a unified paradigm that served a great variety of use cases, among them:.

While implicits were a defining feature in Scala 2, their design has been greatly improved in Scala These capabilities are described in detail in other sections, so see the Contextual Abstraction introduction , and the section on given and using clauses for more details. You can also use Java collections classes in Scala, and to give them more functionality, Scala includes methods so you can transform them into Scala collections.

Scala can also be used in the browser with the Scala. The Scala. The following examples show some of the built-in collections methods, and there are many in addition to these. Scala idioms encourage best practices in many ways.

Case classes are primarily intended for use in domain modeling , and their parameters are immutable:. As shown in the previous section, Scala collections classes support higher-order functions, and you can pass methods not shown and anonymous functions into them:. Scala libraries for functional programming like Cats and Zio are leading-edge libraries in the FP community. Simplification comes about through dozens of changed and dropped features.

For instance, the changes from the overloaded implicit keyword in Scala 2 to the terms given and using in Scala 3 make the language more clear, especially for beginning developers. Eliminating inconsistencies is related to the dozens of dropped features , changed features , and added features in Scala 3. Scala like most compiled languages is able to run an order of magnitude faster than dynamic scripting languages, due to the static nature of the code making it easier for the compiler or JIT compiler to optimize.

Jump-to-definition, find-usages, refactorings, etc. Compile-time generation of things like JSON serializers has excellent performance , whereas runtime-reflection-based implementations tend to be extremely slow. This applies in every language, static or dynamic.

The compiler can reason about what the code can do, what the code cannot do, and easily do things like compile your Scala to high-performance Javascript in Scala.

In contrast, cross-compilers for dynamic languages like Clojure tend to have a long-list of caveats and incompatibilites. In general, having a language focused around static compilation and static analysis means the computer can help you out more in whatever you are doing: whether you are trying to find usages of a variable, renaming some method, or just trying to make your code blazing fast.

These are all things that software engineers do day-in and day-out, and it's great to have tools that are able to help automate this work as much as possible! Scala isn't the only language which has realized the multi-faceted benefits of static compilation. Even Python, the poster-child of dynamic languages, has:.

Invested in the MyPy static type checker to find bugs. Started compiling Python to high-performance C code using those types. This is a story that has played out many times in the past, and we can expect it to play out many times in the future. Fundamentally, the promise of having the computer do more work to help the programmer understand, debug, refactor, or optimize their code is too great to ignore.

But In order to realize those gains, we need a language that the computer is effectively able to statically analyze. Scala is already such a language. Perhaps the most interesting thing about Scala is that it leans heavily on inference in order to make things easy to use. While both snippets are understandable, it is clear how much work the inferred new StringFrag and new SeqFrag constructors and the inferred : String annotation are doing to keep our code clean and concise.

The top snippet feels like something you'd see in a dynamic language, while the bottom snippet feels distinctly Enterprise Java-y. These days, type-inference is becoming table stakes for compiled languages: newer typecheckers for dynamic languages like Ruby or Python use type inference heavily, and even more traditional compiled languages like Java are moving in that direction.

Scala is a language built from the ground up around type inference, which ends up being much more coherent and well-designed in Scala than in other languages bolting it on after-the-fact. Consider the following snippet, which defines an Example[T] trait with a single value, and a function exampleFor[T] that lets us grab the value for any T for which we have an example defined:. We can define examples for Int and String using the implicit syntax below:. Ditto for exampleFor[String] , so far so good.

Where this gets interesting is when you define Example s that depend on other Example s, e. Here we are defining an Example[ T, V ] , or an example of a 2-element tuple, for elements of any type for which there is already an Example defined.

We can also ask for exampleFor s of deeply nested tuples, as long as they are made of Int s, String s and 2-element tuples:. While most programming languages allow you to take an expression , "moo" and infer the type Int, String , Scala allows you to go the other direction: take the type Int, String and infer a value , "moo"!

This is tremendously useful in a whole range of different scenarios, and allows the Scala language to be as concise as dynamic languages while still preserving its statically-typed nature. For a deeper dive into how this value-inference technique works and is useful, check out this section in my book on Typeclass Inference:. Being able to specify the type of the value you want, and have your compiler automatically generate the code to provide it, is something unique to Scala.

Scala achieves this not through clever hacks or revolutionary AI, but instead through a well-defined set of rules in where your program can infer types and values. Fundamentally, this kind of flexible program-inference is the closest we can get to a holy grail of a "do what I mean" language. The last thing that Scala does well is to lean heavily on the host language for both its language semantics as well as its implementation.

Scala is typically run on the JVM, which together with the Java ecosystem provides a host of useful things that Scala doesn't need to worry about:. Consider the state of multi-threading in Ocaml, which has been "work in progress" for years:. Piggy-backing on the JVM, Scala inherited a fully-working, well-defined and battle-tested multi-threading implementation. Rather than spending person-decades on re-implementing a multithreaded memory model, threading, atomics, locks, semaphores, volatiles, etc.

These days Scala also runs in the browser via Scala. Every programming language is subject to the same pressures: for better performance, tooling, convenience, correctness, or maintainability at scale. I have already discussed why I think Scala has both a good superficial featureset, as well as a sound underlying approach.

Scala focuses on helping software engineers with their most practical challenges, with good fundamentals to ensure that it gets good mileage out of the efforts of the community. Programming languages are diverse, but in many ways they are getting less diverse over time. Consider the state of the mainstream programming languages a decade ago, circa At the time, Scala was definitely the odd one out: with inferred types for conciseness, and functional programming features like records case class es in Scala , pattern matching, and lambda functions.

The divide between the compiled languages and the interpreted languages was stark. But over time, as the industry evolved, the landscape of the same languages looks very different today, post The fact that every language is evolving should not come as a surprise to anyone, but what may be surprising is that every language is evolving towards the same place : they are all becoming JIT-compiled-ish, inferred-typed languages with functional programming features like records, pattern matching, and lambdas.

Obviously the details of this diverse set of languages vary tremendously, but the direction they are heading is clear. Newer languages like Kotlin or Swift also tend to fit the same mold.



0コメント

  • 1000 / 1000