Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will always claim success.
Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we've PROBABLY gone too far and are unfair now). When hype waves don't work out, this industry is pretty quick about discarding them.
This teenage dynamic carries over into adulthood. Academia is a bunch of young adults chasing tenure, by publishing papers arguing that the existing batch of tenured professors are washed up and got it all wrong. And also "rediscovering" the older research that was discarded by the previous generation.
Software development is a bunch of a junior devs working on bug tickets. Frustrated by the tech debt they inherited, and convinced that tech debt comes from the tech rather from the organization. It's just that in comparison to academia, technology has the generational lifespan of fruit flies. So we spin through the cycle a lot faster than other walks of life.
There were failures with Ada as well as I recall. Statically typed. Ahead of it's time. But in some critical use cases, it failed. It also cost a lot to maintain. Compilers/IDE's were super expensive. Yet there were cases of undefined behavior that you still had to (hopefully) catch in a peer review.
This was the case of the Arianne 5 rocket explosion caused by software written in statically typed Ada. It's worth a read through:
https://itsfoss.com/a-floating-point-error-that-caused-a-dam...
Java and the log4j mess are similar. It's a statically typed language, but a poorly reviewed code base. The static typing didn't catch the security hole. And it's cost the US millions of dollars so far to fix it.
Static typing may be nice and all, but it sure as hell ain't a silver bullet.
This is a ridiculous statement and just really devalues everything you are saying. How is a vulnerability in a library that is completely orthogonal to typing relevant in this discussion. Static typing never claimed to cure programmer stupidity.
Also when I say static typing I mean languages with good type systems, as much as people like to say typescript is bad because it's based on javascript, at least null errors are impossible if you are using strict mode unlike Java and Go where any variable could potentially be null and the compiler wont tell you if you have unhandled null cases.
> Static typing is net 0 cost. We don't need to be "honest" static typing is obviously not free you need to think of types. The real revelation was that the cost of dynamic languages far exceeds the cost of a statically typed language.
And my point is the static typed languages we do have didn't save us anything in terms of cost.
I recommend maybe you read the hackernews posting guidelines before you post again.
I'd bet this lasts for as long as static typing remains fast and comprehensible to the average dev just trying to get something done. I suspect language designers and library builders will add more typing foo until builds are either slow or the code becomes a mess of factories, traits, monads, functors, and other constructs - ushering in a new wave of dynamically typed languages which "just get out of your way".
Java, C++ and similar are terrible benchmark for it. Before, types were almost for do taxonomy, with limited help to actually write CORRECT code, and more important, MODELING the domain was very verbose and with limited advantages!.
Against that, no static types makes more sense. With o without the end result, result-wise was kinda the same, only that without you remove a lot of noise on the codebase.
Only after a bit of the ML/oCalm/Haskell/etc type-system get in, and NULL removal becomes truly feasible, and some of the failures of error-prone software and how WRONG JS,C++ and for some extend, Java become more and more evident, then modern static types start to leverage a greater return of investment.
It also come together with other improvements in tooling (that make more enjoyable type inference on IDEs, for example), composability, iterators/generators, etc and you get a very nice toolset.
This is where everyone is converging, in some way or another.
This is why hybrid typing is so prevalent nowadays, as you don’t need to satisfy any internal need of the compiler, but you can still keep the documentation of models and interfaces that static typing gives, where desired. Performance is usually also a no-factor nowadays unless you have high demands.
On top of this, the only reason JavaScript grew so large was that there was literally no other way to ship code to a user. IE6 was the universe. Nobody wrote code like this by choice. And those unfortunate souls that did still have scars from it. Remember this was also before CI checking every PR for correctness became as common as it is today.
Because of all this, there will not be any “swing of the pendulum” back to the crazy era of untyped PHP, JavaScript without TS or python without mypy. This is something that is here to stay.
Rust?
A lot of people say Rust improve the game (I'm one of them). I have coded in +12 langs all my life,. Rust totally remove tons of issues (for me) that were present in the past just before shipping and even after.
And I port the same project. The kind of issues I get of the Rust codebase are a fraction of what I has.
--- And I think many studies show it?
Rust is a special case because its main contribution is to use typing rules to solve a harmful problem that's well-known and particular to C (or C++).
It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.
I am well aware of clojure.spec, and it, as well as many other techniques employed in development, are probably among the reasons why types don't actually seem to have a big relative impact on correctness.
Static typing of course not new, but migrations usually happen to relatively new languages: Go, Rust, TypeScript. I haven't seen reports recently of any large migrations to Ada, Pascal or even C++ or other old (20yo+) language.
> MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped
MongoDB is still used in new projects but it is not longer getting a lot of up-votes on HN. It is somewhat similar to PHP - HN doesn't like it but the language is still widely used.
Things are quietly rewritten in Java and C# all the time. I’m sure it happens with C++ as well since the more recent quality of life improvements have landed in that language.
It creates a kind of "self-fulfilling prophecy". "We can only find Java and C# programmers, so everything needs to be and upgraded to Java or C#. Since everything is in Java or C#, we have no choice but to keep using it. Since everything is written in Java or C#, then those are the languages I better learn." It's very hard for other languages to penetrate that bubble.
Ada, and even more so for C++, will hold on relative to the code previously written with them. But clearly, so many programmers will "hedge their bets", with also learning Java or C#.
Pascal/Object Pascal/Delphi, from back in the 1980s, was a "problem" for which big players (like AT&T, Microsoft, Sun, etc...) have arguably pushed a lot of hate and disinformation towards. There is a good argument to say that these days it's really more for independents and mavericks. Way more for Pascal programmers who managed to get themselves into positions of power, that are calling the shots or can influence what gets used.
Delphi/Embarcadero would have made the language extinct because of their short-sightedness, charging outrageous prices for its IDE/compiler to the enterprise, and developing little to no Object Pascal talent, if not for the open source projects of Free Pascal/Lazarus and PascalABC. Interestingly, a few changes in the past or future, and Object Pascal could/can be a contender. It is a viable alternative to Java or C#, but doesn't have the corporate push.
Except COBOL. We've never seen it but it's a punchline.
Now regarding number one . . .
Don't take the above as a statement that C++ is a great language. I'm interested in rust and ADA (just to name a few that keep coming up) which might or might not be better for my needs. I'm a C++ expert though, so I know what the limits are.
I try to model my domain in C++'s types. it isn't easy, but even avoiding int and bool helps a lot to ensure my code doesn't make stupid mistakes. Haskell would give me more power, but I'm moving my C++ in that direction.
It's true that one can write unit tests to firm up dynamically-typed code, but doing so is not only a slog, it makes changes more fragile and deployments a lot scarier. If you aren't perfect the first time you write the tests, instead of a build failing you get restart loops, dead threads, and in the worst cases data corruption from improper silent type coercion.
HN never stops delivering new funny insults about this language :-)
For us, Golang turned out to be the optimal balance between (probably imaginary) strictness of C++ and "everything allowed until 2AM PD call" philosophy of Python.
Even for simpler things like scripts and little auxiliary services Python is bad, because these little things tend to grow and get more complex.
This is not about being objectively better but only about preference. So that's not a "truth".
Sure people might prefer static over dynamic, but until we have hard evidence that one is actually better than the other, this is only preference which is heavily influenced by the current moment we are in.
Having said all that, I've worked with both and lean a lot more towards typed languages now (more than I did previously). But this is not an uncomfortable truth, because it's not objectively true.
There are edge cases that can be argued all day, but if some large codebase is going to be maintained long term it is difficult for me to see how types could be a handicap. Even if a coder doesn't really engage with the type system "properly", as little as capturing information that was already obvious anyway will reduce the bug count.
There are good reasons to expect typed languages to do well.
(sorry, I can't say that with a straight-face)
It could work though! And I don't just mean like Visual Studio's Edit-and-Continue feature...
Consider a language feature that lets you annotate a local/parameter/field's ("thing") type as "Hindley–Milner-esque" which tells the compiler to invert the thing's typing rules from prescriptive to descriptive (i.e. to mostly stop complaining and make the thing behave more like a JavaScript `object`, so the compiler only complains about 100% provably wrong usage of that thing).
Another "feature" of PHP/JS dev that I want to see in compiled projects is a way to run a project-with--build-errors by adding a toggle that instructs the compiler to stub-out all functions/members that contain build errors (even syntax errors!), this way we can do quick ad-hoc testing without needing the entire project to build. Think about the times when you your boss asks you to make 1 or 2 "minor" alterations for an unrelated feature and you don't think it's worth making a whole new git branch-andworktree for, but you can't test it right-away because of unrelated breaking changes you've already made.
Just some ideas...
---------------
Unrelated additional comment: I'm looking forward to when all programming languages fully support generalized ADTs. So many issues with data-modelling can be solved with ADTs and GADTs, but yet thanks to OOP's legacy from the 1990s we still have to shoehorn simple and clear models into inappropriate applications of inheritance. I want my intersection-types, damnit.
What if you pass it a float and that's converted to an integer?
For at least this one case, many people (including myself) believe it's a success. Whether the tooling for Sorbet or mypy ever reaches that point, there are compelling reasons to believe in the success of the model.
The question I would have is what would take for this adoption to reverse? Where is the dissatisfaction with the model? The rationale for Typescript and Sorbet was precisely long-term maintenance and codebases at scale.
To add to the list, there's also Clojure spec and Elixir spec. All of these tools have a similar philosophy across very different problem domains. All of them have enthusiasm and the model of type annotations for dynamic languages is decades old.
To reference another one of the author's points: people are slow learners in software engineering. The continued reinvention of this concept decade after decade shows its utility, both theoretical and practical.
It is [1].
Over 60% of Javascript developers use it somewhere, and over 1/3rd of all developers use it for something. Almost all widely used npm modules have @types annotations as well. Outside of node, it's arguably the most ubiquitous voluntary extension of the JS ecosystem ever.
[1] https://redmonk.com/jgovernor/2019/05/07/typescriptexploding...
Common among JS developers != common among programmers != common among professionals in the software industry
Not sure if you're a troll, but as I pointed out, as of 2019 over 1/3rd of all developers in the software industry were using it. It's higher now.
That's common. Find me another technology used by more developers in the software industry.
Additionally for things like static typing, the larger the company the more risk-averse people tend to be within the company so things that give a feeling of safety like type-safety are going to be a much easier sell.
I like Typescript. The Typescript enthusiasts are also glib about what a pain it can be to teach. This is not a minor tradeoff.