Erg: a statically typed language that is Python compatible

Scala is a quite "deep" language as it's very powerful (actually it's one of the most powerful languages out there). That can be "overwhelming" to someone just starting out I guess. But regardless some FUD written here and there on the interwebs Scala is not a complicated language. At least if you don't make it so.

Scala was made specifically with the intend to teach people programming. From the ground up.

You don't need to understand monads to understand "Hello World", like in Haskell where printing to the console is an "advanced topic" :-). You can't mess up even the most trivial programs with memory leaks and undefined behavior like in C/C++. You can start out with simple, down to earth code without any friction and slowly build up more understanding for more advanced topics as you go. No need to understand "the monkey holding the jungle" and all that at once.

This is something in which Scala is more or less similar to Python or JavaScript. Actually it's even more amenable to people learning programming from the ground up than the former 'cause it has a very simple "evaluation by substitution" model of operation by default. Everything is an expression, and immutable at first, with makes reasoning about programs as easy as putting numbers into math or physics formulas; something that most people practiced in school for many years already!

To have a smooth start with the language I would recommend having a look at `scala-cli`¹ (for a decent CLI experience, and to be able to bootstrap IDE projects quickly²) and `Metals`³ (as an IDE). (There are also other tooling options like the JetBrains' Scala IDEA plugin, or ENSIME for Emacs fans, but both are less suitable to explore the language in a first step I would say).

Next, no matter what people said you don't need to "fear" SBT⁴ - the default Scala build tool. It's something that looks quite scary to many at first contact but it just works most of the time without any hassle. Especially for simpler projects it's actually brain-dead simple!

Most of the time you just add `libraryDependencies` to your build file by copy'n'pasting a single line form the README of some chosen lib. That's not more complicated than say using Gradle, or pip. Also you almost never have to write your own build tasks as there are SBT plugins for more or less everything one ever would need. Those plugins bring along the desired tasks. Already nicely integrated into your build tool.

(There's also Mill as a build tool which claims that it's "simpler" than SBT. But imho it's actually more fuss for simple projects than SBT where you can just define your dependencies and a Scala runtime version, each with a single line in the `build.sbt` file, and be done. Given that most projects use SBT by default one gets in touch with it anyway quite quickly).

SBT is actually quite powerful (conceptually it's to some extend similar to Google's Bazel); but one can safely ignore all the advanced topics most of the time. At least as long as you don't need to set up a complicated multi-module build with lots of very special requirements yourself. But that's nothing someone just started out would do anyway I guess.

As you can see on its home-page SBT also offers a feature to bootstrap projects form templates with a single command (and there are thousands⁵ of templates). That's something that's really very handy! Especially when playing around with some unknown framework and/or trying out the language.

As people coming form Python are often in the field of data science Scala's notebook support shouldn't go unmentioned. There's a Jupyter compatible Scala kernel out there called Almond⁶. It also integrates the scripting features of the Ammonite REPL⁷. (That REPL is in fact also part of the `scala-cli` tool that was mentioned above). Additionally to that there is a different notebook implementation called Polynote⁸ made especially for Scala (even it's actually a polyglot notebook integrating also Python by default).

But Scala has even a broader surface area: It supports compiling to JavaScript⁹ or to "native code" (through LLVM)¹⁰.

The later option didn't reach version 1.0 by the time of writing but it still may be superior to Graal native images in some cases (at least it had better performance at some point, almost being en par with the JVM; something Graal struggles with still afaik). The JS support on the other hand's side is production ready for a long time by now, and beats something like TypeScript on every axis imho. Especially if one is tired of React's idiosyncrasies something like the Laminar¹¹ JS framework could be a breeze of fresh air!

As seen Scala has a broad area of applications. Even some quite "exotic" like hardware development! For example the Chisel¹² HDL framework is very popular in the RISC-V space. But you have in the HW-dev corner also Scala stuff at the bleeding edge of research like SPATIAL¹³.

Last but not least I think I need to also mention the elephant in the room—which is of course the (pure) functional programming space—where Scala is effectively one of the leading drawcards. With libs / frameworks like the Typelevel¹⁴ ecosystem (with e.g. Cats¹⁵, Cats-Effect¹⁶, Spire¹⁷) or all the great stuff around ZIO¹⁸ ⁽¹⁹⁾ Scala has been even influential in the Haskell world.

Given all that, you can probably see the biggest "issue" with Scala now, too: It's a completely unopinionated language without "guardrails". Whether you like / need to do low-level imperative programming, Lisp-like functional programming, object-oriented design, declarative programming based on (e)DSLs, Haskell-like FP, or anything in between, Scala makes it possible. But it doesn't force anything. You, as the person in charge, are responsible to find the right "style" for your application, needs, and skills. Scala as such does not offer any hand-holding in that regard (frameworks do of course still). That's something that makes the language look "complicated" for some people. Even the language as such isn't complicated, only very flexible.

That said (oh, this got way to long I see), I want to stress that the language is in fact quite simple (given all its power), as it has only a few basic rules. Everything else follows from those as the basic build blocks where chosen with a great deal of tact.

No matter your skill level or previous experiences with other languages you can start writing Scala right away. You can just ignore more or less everything that does not make sense at the given moment. You're not forced to learn and use any particular programming paradigm. Go with what you know already. It works just fine in Scala.

The other great thing about learning Scala is: With time even the most advanced and exciting topics in programming will become understandable (and therefore useful). All that embedded in one coherent language framework.

With a solid Scala understanding almost all features in other languages become obvious. Which, like I said, works also the other way around: You can take your current knowledge and easily apply it to Scala. Just don't listen to any Zealots telling you "you need to do things this or that way". (But don't get me wrong here. Of course purely functional programming is the only valid way to write Scala. Just saying… ;-)).

Have fun!

___

¹ https://scala-cli.virtuslab.org/

² https://scala-cli.virtuslab.org/docs/cookbooks/vscode/

³ https://scalameta.org/metals/

⁴ https://www.scala-sbt.org/

⁵ https://github.com/search?o=desc&p=1&q=g8&s=stars&type=Repos...

⁶ https://almond.sh/

⁷ https://ammonite.io/

⁸ https://polynote.org/latest/

⁹ https://www.scala-js.org/

¹⁰ https://scala-native.readthedocs.io/en/latest/

¹¹ https://laminar.dev/

¹² https://www.chisel-lang.org/

¹³ https://spatial-lang.org/

¹⁴ https://typelevel.org/

¹⁵ https://typelevel.org/cats/

¹⁶ https://typelevel.org/cats-effect/

¹⁷ https://typelevel.org/spire/

¹⁸ https://zio.dev/

¹⁹ https://zio.dev/resources/#zio-ecosystem

    (import os)
    (import [os.path :as op])
    (with [f (open (op.join dir_name file_name) "w")]
        (.write f "..."))

A code block is *not* the same as a paragraph. It is the same as a part/chapter/section/subsection/subsubsection. (Think about it.) In formal writing, these are practically always clearly indicated by not just semantic whitespace but also by semantic headers with particular semantic styling as well as semantic numbering. In addition, if you you write these programatically in for example Markdown or LaTeX, you might have semantic whitespace in the markup language but you definitely will have semantic non-whitespace symbols in the markup language.

Next Quote:

    for (i = 1; i 

    for i in 1..11 {
        println!("{}", i);
    }
    println!("{}", i);

    for in in 1..11
        println!("{}", i);
        println!("{}", i);