Other people I showed it to felt it was more on the horrifying side, but like I said, it's subjective.
if you want you language to apply a standard discipline, then use Python
There were already several 1M+ Perl LoC code bases by the end of the 1990s, as Perl use exploded at places like Amazon.
One key driver of Raku's design was making it easy to write large, clean, readable code bases, and easy to enforce coding policies if and when a dev team leader chose to.
(Of course, as with any PL, you can write messy unreadable code -- and you can even write articles and record videos that make it seem like a given PL is only for Gremlins. But it's so easy to write clean readable code, why wouldn't you do that instead?)
> type hint ... is never enough if it isn't guaranteed by a compiler or at runtime
Indeed. Type hints are a band aid.
Raku doesn't do hints. Raku does static first gradual typing.[1]
The "static first" means static typing is the foundation.
The "gradual typing" means you don't have to explicitly specify types, but if you do types, they're always enforced.
Enforcement is at compile time if the compiler's static analysis is good enough, and otherwise at run time at the latest.
For example, in the Gremlins article only one example uses a static type (`Int`). But user code can and routinely does include types, and they are enforced. For example:
sub double(Int $x) { $x * 2 }
double '42'
SORRY! Error while compiling ...
Calling double(Str) will never work with declared signature (Int $x)
(Int $x)
I know what you mean, but to be usefully pedantic, the CS meaning of "weak typing" can be fully consistent with excellent typing discipline. Let me demonstrate with Raku:
sub date-range(Date $from, Date $to) { $from..$to }
say date-range '2000-01-01', '2023-08-21';
But it passes and works at run time if the function declaration is changed to:
sub date-range(Date() $from, Date() $to) { $from..$to }
The changed declaration works because I've changed the function to be weakly typed, and the `Date` type happens to declare an ISO 8601 date string format coercion.
But what if you wanted to insist that the argument is of a particular type, not one that just so happens to have a `Date` coercion? You can tighten things up...
sub date-range(Date(Str) $from, Date(Str) $to) { $from..$to }
* The compiler may reject the code at compile time for failing to type check; and, if it doesn't:
* The compiler will reject the code at run time for failing to type check unless it's either a `Date`, or a `Str` that successfully coerces to a `Date`.
The problem with Perl (or, I assume, Raku) in production is that the responsible way to read it is like reading every single footnote in an annotated edition of Shakespeare. It sucks the joy out of it, and joy is the point. Production Perl is joyless and therefore pointless, unless you're some kind of prodigy who understands every obscure political reference and every 16th century pun without any help.
Why? Are you assuming a very particular kind of surprise here?
"Oh, I can replace these five lines with a single builtin." is a surprise, and so is seeing that someone else already did so.
e
|
|
|
-r ------------- r
|
|
|
-e(Don't kill me fanatics)
Here is what I guess makes it hard to read for me: There are many terse keywords (fn, mut) and symbols (&, [], ->) along with some things that look like Java annotations and are equally hard to understand without knowing the language. Array slices look easy enough to understand [a..b] but surprise: b is actually exclusive? The definition of arrays is the most weird one I have ever encountered [u8; n]. To me Rust looks much like C++ with a twist and people rightfully complain about C++ often :)
The documentation about language and libraries was solid for my cases and most of the time it seemed enough to ignore most of the tiny key words and symbols without losing much understanding of what the code intends to do. If I were given the choice I'd probably still prefer Rust's weird syntax with added safety over the clarity of C which offers no safety at all (not talking about obfuscated code contests here).
But would you put C++ next to Perl in terms of difficulty reading? I wouldn't have thought they were particularly close. (In terms of normal code at least, not the implementations of ultra-generic templates.)
And regarding design principles, I think the comparison is clearly on point. These are languages where the motto is basically "if you can't do it (if you can do it but it's perceived too long that also counts) then the language needs to be horizontally extended to account for this use case".
My vague impression was that Rust is still a (significant) simplification over C++. (Ada is a funny case because it seems to be deliberately designed to be hard to read and hard to write, overall a pain in the arse, in the spirit of "if you never reach flow, you will always be very focused", I guess.)
That's how I stay alert in every language. :D
Rust feels like an industrial version of Perl to me.
Keep in mind, this is just what I value in a language. The perfect programming language to me is one that is expressive while also being easy to read. I think Python is nice in that regard, and probably why it's so popular to this day. But there's always room for improvement!