Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
typedload
Python library to load dynamically typed data into statically typed data structures (by davidatsurge)
-
-
-
-
-
-
-
-
-
-
scala-cli
Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!)
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
https://github.com/erg-lang/erg/blob/726b7b80fcf06c6c4099b62...
Using a 69 as your language's logo? I actually don't think it has been done in a serious-seeming project before.
Mypy can work really well in many cases, but we seem to get bitten by bugs on a daily/weekly basis. There are >1,000 currently open on Github [0], so it doesn't take much effort to hit one. And having the type-checker tell you that something's not valid when it actually is is a real turn-off...means that we end up with code that's riddled with "# type: ignore", which kind of defeats the point.
Pylance (the VSCode built-in linter, based on Pyright I believe) tends to do a better job than Mypy, but not as easy to integrate into CI. It's a real shame that the Python ecosystem doesn't have anything nearly as robust as TypeScript.
[0] https://github.com/python/mypy/issues?q=is%3Aopen+is%3Aissue...
It'd not fully solve your issue, but have you ever seen https://github.com/py2many/py2many ?
No shortage of options, e.g. Dg, Mochi, Coconut, and Hebigo (based on Hissp[1]).
[1]: https://github.com/gilch/hissp
These aren't just some third-party bolted on. The type annotation syntax is built into the language[5] and standard library[6][7].
I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. Maybe some day they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it.
[1]: https://github.com/microsoft/pyright
Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy.
Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python libraries.
Actually come to think of it that might be the easiest way to write fast KiCad 6 plugins.. I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways. Problem is that Python would likely be too slow. Nimporter could be perfect. It looks really simple to setup.
Erg looks fun for small programs. Though Erg's syntax choices seem less Pythonic than I'd expected. Interesting though, some of the idioms seem handy.
Though Nim definitely can be described as a statically typed Python-compatible language! I haven't used them but https://github.com/Pebaz/nimporter https://github.com/yglukhov/nimpy both seem great. Nimporter in particular looks fantastic for writing fast python libraries.
Actually come to think of it that might be the easiest way to write fast KiCad 6 plugins.. I really want to try making a native KiCad autorouter. But I don't want to figure out the C++ plugin setup and since KiCad 6 the Python APIs seem better documented and supported anyways. Problem is that Python would likely be too slow. Nimporter could be perfect. It looks really simple to setup.
I read more about your repo, and it looks like typedload only does Python lists/dicts -> typed python objects(like named tuples, data classes, attrs classes, etc). Ie, the benchmarks don't include the time required to parse the JSON.
So I modified the benchmarking code to include loading JSON[0], and your library still came out on top!
But, it turns out I was wrong about pydantic using serde under the hood. Pydantic version 2 will. And the maintainer aims for it to be about 10x faster [1] than version 1.
Nonetheless, this was definitely a surprise for me, and if I ever go back to using Python, I'll definitely check your library out!
I'm curious, why do you think pydantic took off and your library didn't? It looks like your library is both faster and easier to use to me.
[0] https://github.com/davidatsurge/typedload/pull/1/files?diff=...
> If you see code without empty lines separating different steps, that's pretty badly written Python.
You're describing literally all of the Python I've ever seen. Look at Flask, for example[1].
Furthermore, without brackets, adding newlines in a code block forces me to then add more newlines between blocks (which Flask also does!)
I would rather just have easy-to-scan, clear characters that demarcate a code block.
1. https://github.com/pallets/flask/blob/main/src/flask/templat...
Some tips and remarks for starters:
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/
