About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day.
Now, Nvidia and Google ruined everything. Python is the ML language, so every package likely depends somehow on tensorflow or some GPU acceleration. This is a problem because every damn version of ' insert tf/pytorch/Jax/cuda/etc ml package here' only works with that exact version configuration ONLY ( and honestly, it probably doesn't actually work anyway). So, if you have an idea of using two packages together that aren't already in a package - be prepared to spend the next month trying in despair to get that to work (and probably ultimately give up).
It's insane to me that the workflow of today necessitates (in python anyway) setting up multiple docker containers to talk to each other, simply because python packages seem to have no problem making breaking changes every freaking week.
I went from loving Python to hating it with a seething rage.
Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed.
God, I hate Python so much now.
https://docs.scala-lang.org/scala3/book/scala-for-python-dev...
Sorry for that quite random comment, but SCNR.
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://github.com/search?o=desc&p=1&q=g8&s=stars&type=Repos...
⁸ https://polynote.org/latest/
¹⁰ https://scala-native.readthedocs.io/en/latest/
¹² https://www.chisel-lang.org/
¹⁵ https://typelevel.org/cats/
¹⁶ https://typelevel.org/cats-effect/
There's a reason that package dependency keeps getting rewritten in python. People think they can make it better, but some of the problem is actually just the developer choices by people making the packages. Probably the price paid for having too many people using the language who aren't actual software developers.
"Hey, this variable is probably of this type. Now go on, run the code and launch a debugger the same way you would if there was no hint just to make sure it's correct. Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities."
Don't get me wrong, type hints are cool but they're just a toy compared to proper static typing.
This is literally what mypy does.
There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system).
Like yes if you aren't validating the type hints you aren't getting the value, but if you are, you don't need to run the code! I get most of my python errors at compile time, and you can too. I promise.
Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread use, and nothing from core python, which is a huge hole IMO.
Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing!
This supports my argument!
> one of which , just like mypy, uses gradual typing!
This is like arguing that because your scooter also has a petrol engine, it’s as fast and efficient as an F1 car. My argument was that MyPy doesn’t compete with the capabilities of modern statically typed languages. TS might also technically be gradually typed, but most devs I know just go straight to fully typed TS, because working in a mix/gradual environment is painful and the community uptake of strict types is far higher.
I can name dozens that python has that Java doesn't. My point is that if you include cpp or java or golang the statement becomes false. Python's type system is actually generally speaking more robust than those (cpp is comparable, but I don't think python's is worse).
So I'm asking, be specific what capabilities does mypy lack that cpp or java or golang provide? Keep in mind, mypy supports literal types, limited dependent types, dynamic-duck typing (protocols), limited contract types, and more. Java doesn't, go doesn't. Cpp supports some of those but it requires arcane incantations.
that must require some advanced usage of mypy then, because my experience was that even the most simple example got the finger from mypy that would have very obviously worked in Java
mkdir alpha
echo 'beta = True' > alpha/models.py
echo 'from .models import beta' > alpha/__init__.py
echo 'import alpha; print(alpha.beta)' > doit.py
mypy --strict doit.py
# doit.py:1: error: Module has no attribute "beta"
And indeed[0] that's the case. It makes perfect sense that the abstract machine of typed python does not allow everything that the abstract machine of untyped python does, and java would error on trying to use a private class or method just the same.
[0]: https://mypy.readthedocs.io/en/latest/command_line.html#cmdo...
The point of a sound static type system is that you get a guaranty that your program is type-safe even in case not everything is "hinted properly".
With the linter approach on the other hands side it won't get better than what a dynamic language offers anyway: To be (more or less) sure everything is like intended all you can do is to run your program and pray… You can't upfront rule out for sure all kinds of errors like when using a proper static language.
Of course an external tool could model and check against a proper type system, in theory. So that's indeed not the point.
A proper static type system comes with a formal definition and (math-like) proves of soundness (and progress). This will give you the guaranty that a well typed program is sound.
A "linter" can't give you that guaranty. All it can do is to say "LGTM"; but your program could still crash or bug-out in some other way at runtime. That's quite a big difference imho.
Linters are more like automated tests: They may tell you something is wrong, but they don't give any guaranties that things are actually right. A proper static type system OTOH gives such guaranties.
For example I would consider TypeScript being only a very funky linter—as it does not model a sound type system. My understanding is that mypy and friends are not different. All those linters produce not only way to much false positives, no, they also produce false negatives (meaning that they let unsound programs pass; something that can not happen with a formally verified type system).
As an anecdote, I got bitten by that when trying TS (and it was a very sad experience): When playing around with TS for the first time I did not know that TypeScript is barely a linter. I was really very excited about all those things you can do with proper structural types there! I was coming from Scala 2 which has only very limited support (based on JVM reflection) for this kind of types¹. But I always loved the "objects as hash-maps" concept of JS… So I've written some small REST client for one of our back-end services in TS. Everything nicely typed, no escape hatches used. Someone also told me I have to use "stric mode" which will "catch all type errors". That looked a bit odd, but OK JS was not made to be typed in the first place. Everything looked great than. As someone coming form the purely functional Scala camp (where things work when they compile :-D), and encouraged by all those people praising TS for its "powerful type system", I've put the same amount of confidence as in Scala into the typed code I've written in TS. By this I mean you don't need to double check whether things are correct if the typer says they're correct. It's enough to check the logic of your program. You don't have to try out "manually" (this includes written tests!) every line of code. Up to than everything looked good. So I've pushed things and started to do end-to-end test. That was when I fell out of my dress. My code produced runtime errors which where actually "impossible"! The TS "type-checker" said things are such and such but at runtime they were different (which I found out only after some deep debugging sessions as this was something I did not expect in any way)! I think I've wasted one and a half day debugging this shit only to find out that TS "types" are actually worthless. If I have to try out any and every line of code manual anyway what's the point of TS? I could have written this thing in pure JS (where I have to also check any and every line manually), but it would have been much easier without "wrestling" with that quite useless "type system"… :-(
The point is: A dynamic language remains a dynamic language even if you use some linter! Without true guaranties you can't have much additional confidence in your code without testing just everything—even the parts that were already "tested" by our "type system". Actually it's even worse than without a linter if you don't know about its shortcomings and make the mistake to blindly trust such a tool; like you can do in case of a sound type system (modulo the very seldom cases of compiler bugs).
I hope I could make it now more understandable what I mean by "proper static type system".
___
¹ Things improved in Scala 3 though.
I'm pretty sure the mypy and typescript devs would disagree here. The typescript and mypy abstract machines aren't any less sound than Java or c++.
All four are abstract machines that make fundamentally similar guarantees. Cpp and Java can still encounter classcast exceptions and segfaults.
And, like, you still need tests in functional languages. Specifically, I don't think I've encountered anything like
> My code produced runtime errors which where actually "impossible"! The TS "type-checker" said things are such and such but at runtime they were different
Without either explicitly subverting the type system, or dealing with some kind of untyped deserialization along an api boundary, which you absolutely need to test in any language.
I only wanted to point out once more that a proper static type system is of more use than some bolted on linter. (And add the point about type inference).
I don't disagree, but that's not an argument I ever put forth! (and I actually sort of disagree a little bit, mypy has/is getting a bunch of really cool powerful features that put it in the realm of "as cool as" those languages: PEPs 544, 586, 591, 647 (this is a weak form of contract types!), 675 (~constexpr string type), 646 (variadic generic/numeric dependent types!))
Kinda silly that this is optional tooling that came from the community to solve a problem in the original implementation.
Sure, having a community and general inertia, because Python is simply good enough and no alternative has a killer feature, is certainly something you can rely on. It's okay to ask for more, though.
Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good.
Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.
After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its handy to to let uints wrap as sometimes thats what you want. I figured all new languages would do similar things.
There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.
How can you know if you don't have a verified formal description of your language's semantics?
It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting.
Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
> Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN.
Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
But defining some things in a contradicting manner would make up a buggy spec, I guess.
Regarding the int example, funny enough I made a comment about that just before here:
How so?
When or where?
I would say it's always a bug in a program—except when (mis)using ints as bit-fields in very special circumstances.
Simply, as more or less every computation in the real world is build around the concept of whole numbers, and not around the idea of overflowing two-complement bit-fields.
The later is so exotic that there is afik almost no proper use for it (the only exception being as a very low level building block to enable computers do actually useful calculations).
In C/C++ it's "only" UB for signed ints.
For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer).
Such divergent definitions make the whole mess of course even bigger, that's not the point.
This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik.
Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here?
But at least SO is confining my knowledge:
https://stackoverflow.com/questions/16188263/is-signed-integ...
>There should be type hints.
So, is it one or the other?
Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages.
If you name a language, with high probability Python will be better in something unless it is about performance.
What I don't like: no type hints in many libraries, some libraries are not type-hint friendly, lot of unnecessary dynmamic features (like being able to patch modules in runtime) and absolutely no caring about performance and being able to compile into machine code.
> trying to figure out what some dynamically typed code is doing
There should be type hints.