Buzz: A lightweight statically typed scripting language

Also, my only concern in the future is that I have to download 10+ different runtimes to my machine to be able to co-operate with others. But I guess Docker solves this.

All languages are both statically typed and dynamically typed. Or, if you want to be precise: statically checked and dynamically checked. Static vs dynamic refers to whether a check is performed before the program is run or when the program is run.

It's upsetting that even people who write languages use this nonsense taxonomy to describe what they do.

----

As a consequence, your enthusiasm... sort of comes from the place of not understanding something. My guess is that you are happy to see that there are type annotations in the language and they seem to be mandatory (? -- I haven't explored the language in detail enough to tell, but usually if the type annotation precedes an identifier in the grammar is not possible to make it optional).

What I think you (or the language's author) might be happy about is that there aren't built-in mechanisms in the language to convert between different types (or interpret the data stored in a variable in different ways). Such mechanisms exist to various degree in languages programmers don't normally call "dynamically typed" (even though, like I wrote before, this taxonomy is nonsense). For example, in C, everything is and integer in the end of the day, which makes a lot of implicit conversions possible. Or, for example, it's possible in Haskell to overload string literals making them something other than strings (eg. SQL prepared statements) making the meaning of the program depend on an annotation / compiler argument.

There are instances where it's genuinely convenient to have the language guess the type of data and there are instances where it leads to frustrating and difficult to discover bugs. Since a language has to make a decision for all such cases it's difficult to find a good middle ground. Below are some examples of when implicit type conversion is convenient:

* When everything in the language can be "printed" and operations involving strings implicitly convert everything to string. Alternatives involve complicated mechanisms of defining printing methods for various objects, while still not being able to write generic code that prints any inputted objects. Or creating automatic methods that print "something" about the object that usually ends up being useless (eg. the memory address of the chunk of memory occupied by the object). And so on.

* Reading user's input, especially interactively. If I had to spell out the types of arguments I pass down to Unix "find" command every time I use it, I'd have invented a language that would allow me not to do that and would've guessed the types from a more concise input.

* Arithmetic involving different flavors of numbers. Imagine there are languages where it's a tradition to define a special sub-type of some integral type for indexing of every array type the program uses. Imagine now that these types usually cannot be converted between each other. You probably haven't worked with a language like that, but if you want to see how you might like it, you could try Ada.

A language can be designed once and then interpreters and compilers (and transpilers) can be made available for it.

Python is a classic example: it's most commonly interpreted, but can be compiled when performance matters.

C is usually compiled, but tcc offers the option to directly run it from source (-run).

History has given us both compilers and interpreters for various dialects of BASIC since the 80s.

Honestly I can't imagine why a language designer should decide upfront if the result of their study will be interpreted or compiled. And I have no idea what choices should they make to characterize it as a "scripting" language.