But even if they didn’t exist, it’s a non sequitur. There are very good reasons for type systems regardless of how projects are founded.

You might not realize that Go has a very limited and awkwardly designed static type system that is the sole reason reason people prefer it for certain tasks over Python, which has both a dynamic, and by now an optional static type system.

Your final point, that types make things more complex and harder to develop is also flawed. Type systems exist to decrease the mental overhead and unload it from the programmer onto the compiler.

They might require more work upfront, but make software more solid, easier to reason about and easier to change. If you’re building a one-off that you will never change then a type less language might be of interest to you.

But it’s short sighted to think that you will be able to write it once and keep it running forever. Only managers who don’t code believe fairy tales like that. In reality many people sit down on a codebase, they fix things, and add functionality. When they do, they want to avoid bugs, they want the compiler to help them, they want LSP, they want to avoid null pointer dereference, double free, they want to be safer, and more productive.

They’d rather spend a week upfront instead of a day so that every one of the later changes takes a day instead of a week.

You get the picture.

Also, types are a spectrum. C++ has types, Objective-C has types. Those alone have enough success stories to fill tomes! But of course you’re talking about strong static type systems like Haskell, Ocaml, Scala or ML, so you should read up on Jane Street. Or Mercury. Blockchains like Cardano.

Personally I think the onus is on you to prove that types are _not_ useful. Many of us enjoy types.

Pretty much all successful indie games use typed languages. Of course, there is a mix with untyped scripts in there too. But many only depends on typed languages.

It shows how the entire industry has moved towards stronger typing. Whether it's existing languages like JavaScript and Python or new ones like Rust and Swift. The trend is undeniable.

I use Scala and Rust every day and I personally think they are better for startups because they allow you to rely more heavily on the compiler to verify things rather than having to check at runtime with unit tests. That means more time on new features and less time fixing bugs and writing tests.

[1] https://www.youtube.com/watch?v=7mTNZeiIK7E

But it is funny you chose the creator of Scala as the example. The gold plated banana cables of typing. The entire language and its endless lang mailing list discussions is a meme by now.

And his upcoming research work could be game changing. The benefits of Rust's concurrency safety without the annoying borrow checker.

1. A whole lot of programmers who didn't know how to use the language effectively in 2010. Less of an issue now the patterns are well established and industry wide the level of knowledge has increased (even Java has algebraic data types now)

2. Some idiots in the community, who have now left

3. Some rough edge cases in the Scala 2 type system; fixed in Scala 3

5. Breaking backwards compatibility with each release. This is something that businesses care a lot about.

5. AFAIK it is also solved with Scala3 with a binary compatible format.

This is a myth. Scala has had one significant compatibility break in 10+ years. Not even Java beats that. Meanwhile the likes of Python really do break compatibility every release, and businesses continue to use them.

So to get a Scala project going with several dependencies, you needed all of them to agree on a specific Scala compiler version and publish JARs built against it. If even one dependency lagged behind (and many often did), you couldn't update the compiler version for your project, locking you out of new versions of every Scala library you use.

This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous. Rust walks this tightrope steadily enough these days, and Go even makes it look easy.

Finally, even though the language didn't meaningfully break compatibility until Scala 3, the ecosystem as a whole did not respect backwards compatibility. For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn. Even the most foundational things like how to bind template elements to variables changed completely. Adding further insult, the documentation was not nearly up to the standard that would make migration productive even for those who could afford the churn.

I loved Scala but these factors burned me hard. It remains to be seen how Rust libraries will compare, but Go libraries have already proven backwards compatible to a fault, and both build dependencies from source so ABI is not an issue. I do however appreciate that Scala taught me that a beautiful language is not enough, real world usage requires responsible commitments from projects to users. It sounds like they've learned this, but a decade too late.

I think you're forgetting how long ago the issues were. It was pretty bad in the 2.7-2.9 days, but a decade ago was already into the 2.10 era.

> This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous.

I don't think that would've been worth it. Binary dependencies work great given that libraries cross-build; the real issue was back when source compatibility was broken often enough that that wasn't practical.

> For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn.

I don't think there'll be many remembering that. Lift was big, what, 15 years ago? It was already fading by the time I started Scala back in 2011.

It's the same story with any kind of merit vs trust. When you have a clean slate, you can build trust based on your merit, but once you break trust, merit alone isn't enough to win it back. In this industry in particular, far too many other options are already holding and building trust.

I truly wish Scala had indeed become the mainstream industry language instead of say Go. I hope Rust polishes off its rough edges and succeeds where Scala failed and where Go doesn't go far enough. But I don't see any future where Scala regains industry relevance, not even if both Go and Rust self-destruct as well.

Source compatibility based model would be ok if Java/Scala build systems worked like Cargo/Go/Npm and compiled dependencies from sources. However, that would make compile times orders of magnitude worse, and they were already unacceptable without it. I remember our project that had about 30k lines of Scala and 300k lines of Java took about 7-12 minutes to build from scratch (and the biggest contributor of compile time was scala). And we didn't even use advanced and slow stuff like macros or typelevel programming. I remember we were seriously looking into stuff like keeping the compiler in memory between the runs (thanks Bloop) and that made it much better although it came with it's own set of new problems.

Comparably on the same (now outdated) hardware Rustc is able to compile 500k lines of all dependencies in about 28 seconds (including linking).

Spark is a special case though - it really was just Spark, and you can't really compare that to something like Rust where as far as I know there's no equivalent. Everything else that was maintained at all put out cross-builds very quickly once the changes between versions got to be small.

This is a big issue for a language which isn't too popular since learning it is expected.

See the example of the article, where you don't have covariance in Go and the compiler fails. Same in Java where you have to cast (and add unsafety) to make the compiler accept your code.

In Scala when using immutable structure (the default) you have covariance and the compiler will happily let you call a function that takes a List[A] with a List[B] if B extends A.

Now that's true that you can do overly complex things with Scala types, but you don't have to.

Good type systems increase velocity by leaving less room for error, so that you don't have to waste half your time debugging and fixing issues that could have been easily prevented. They also provide helpful structure and an IDE experience (the right values, functions, actions, etc are actually suggested for you wherever you are) that really does speed up development a lot.

There's of course always a trade-off: bad type systems can get in your way with boilerplate that you have to wrangle. But I don't think that's the typical experience.

That's not it. I disagree with the GP, but they do have a point: coding for pay, coding for fun, and coding for your own business are all markedly different. So the question whether something works or not in one of those contexts is a valid one.

I disagree with conclusion, though. Successful products are written in whatever the authors know intersected with whatever will get the job done. If you're Chuck Moore and work on embedded stuff, you'll use Forth and will be hugely successful, running circles around your competitors who use C. The relative strengths of a static type system vs unityped language are more than offset by familiarity and experience of the authors.

The story changes a bit when your product grows and you need to hire a larger team of people to work on it. The benefits of a static analysis become more pronounced when the codebase gets bigger. However, if you somehow luck out and get a team of highly competent people, they will use whatever mechanisms are available to make your larger codebase still tractable, even if they use Lisp, PHP, or PERL.

You can bet on something that explodes (Windows Phone...) and then your product gets done in by the choice of tech. Outside of those cases, though, the tech doesn't matter that much. Whatever you do, you'll have problems. Going for a really powerful language will severely limit your choice of libraries. Going with the most common language will leave you fighting decades of accrued nonsense. Going with statically typed language (without sane macros) will lead to lots of boilerplate code and will severely limit what you can do on runtime with the code (unless you use reflection, but then you're back to untyped land). Going with unityped/untyped language will make you hunt the inter-dependencies between your modules and you'll likely become conservative with removing old code (and other forms of refactoring) as a result.

Finding a right trade-off for a tech for your product is never about a single feature of that tech. It's about a complex interplay of what you have, what you think you can get, and what you want to do.

I’d have completely failed at this project if it weren’t for type safety because refactoring anything that long lived and that much code would have been a nightmare.

So there was no risk involved like "Will I tank my future if this fails?".

What I witnessed is that makers who are willing to bet on something with real consequences dislike types as they slow down the progress and therefore the chances of success.

At this point, I’m not even sure what you are trying to prove and I’m starting to feel that whatever it is, you’re trying to prove it to yourself mostly.

Your point is pretty daft though. If was relevant to self-funded startups then it would be relevant to VC funded startups and hobby projects as well. But the fact that you’re having to dismiss all these counter examples people present demonstrates that your point is wrong and you’re simply not willing to back down from your position.

Plus there’s been a wealth of companies founded on .NET and Java technologies that are older than some people on here have been alive. So it’s not like examples don’t exist. You’re not just receptive to them.

I see a TON of open source projects (frameworks, libraries etc.) on the frontend alone that are built using TypeScript. And on the backend Golang is hugely popular and Rust is gaining a lot of traction. All in open source. Not every one of those open source projects is backed by VC money or built by consultants.

Experiment: you go and search for people who have built something on "their own time, money, and risk". Find them by what they've built. First decide whether you respect what they've made, and only then check what language they decided to use to build the thing. I predict that you'll find plenty of people who have built respectable things using typed languages.

I agree, programming is very hard. Let's go shopping.

My view is that people who don’t like strongly typed languages have either just never worked on very large codebases, or they avoid refactors due the general impracticality of it, or they have loads of unit tests to catch runtime “type mismatches” which would have just been caught by the compiler in a strongly typed language.

Choosing an untyped language vs a typed one is a trade off of less upfront work in typing things vs future analysis capabilities of your code. And for me, the upfront cost of typing things is negligible compared to the gains for the future, which in my decade+ of experience pays itself many many times over on any non trivial sized code base.

It didn't take long earlier in my career to realize that in JS, you need to be aware of the type of your variables and try and avoid any implicit type conversions.

But my memory, my individual ability to keep code in my head, to keep an API's datatypes in my head, or to keep function signatures in my head does not scale. Second, it's not reliable, and needs either tests or production errors to verify.

Untyped / weakly typed languages aren't going to go away, and if you prefer them, I'm not going to convince you otherwise. I don't mind them for smaller projects or one off scripts either, utilities. But for larger applications that multiple people are involved in (directly or indirectly, e.g. an API not maintained by myself), I prefer to have a strong type system.

That said, I don't think Go's type system isn't the best, it's kinda loose in some cases (e.g. no enum types). You can't use it to bolt down your application as tightly as e.g. Java or Scala or other such languages. That's probably by choice though, since you need to stay productive as well and not masturbate over your own type system.

Only almost every small app software house for Windows and MacOS ever, and almost evert indie game developer?

And anybody who wrote and sells of supports and makes money as FOSS, any libraries/backend tools/etc in C++ and co, so tens of thousands of projects?

If you want a high-profile story, take Figma; it's built with C++ which is a highly type-oriented language.

Anecdotally, in the last three startups I worked (including one really tiny), the code base was / is largely in Typescript, Kotlin, Python with heavy type annotations, and small bits of Rust.

What does surprise me is that adding types to your PHP code adds _runtime_ errors. With Python, type annotations are predominantly used by static typecheckers and are ignored at runtime (except from some libraries like FastAPI that use reflection to inspect the type annotations). I always assumed all dynamically typed languages that introduced explicit types worked the same way

There are static analysers for PHP too, but yeah they’re also enforced at runtime.

I think I prefer that, if there’s going to be a non-zero risk of bad types landing in production code, I’d prefer that be an error than for it to just carry on and potentially fail later in strange ways.

That said, one of the reasons cited for PHP not having generics is the performance cost of runtime enforcement. So there are a few people out there now making the case for a generic syntax that is ignored at runtime, but that can be built into static tooling. Which I can get behind—PHPs type system is really not bad at this point, but generics would be really nice.

Also, if you just annotated the same implementation that already didn’t handle nulls properly, how is it any different? Your code would just die at runtime a few lines later, with a less explicit errorz

    (t/ann hello-world-error [t/Int :-> t/Str])
    (defn hello-world-error [a] (inc a) ;#"Simplified a bit")

    (: hello (Number . -> . String))
    (define (hello num) (add1 num))

...and Typed Racket is a really powerful type system (see refinement types[4]). So, I thought it's just a matter of time for Clojure to get to that level of power and support. It should be much easier to do this to Clojure than to Ruby, given that you have a working example of how to do it well. So I'm really surprised Clojure isn't gradually typed by now, with most of the code being annotated and type-checked at compile time.

[1] https://github.com/clojure/core.typed

[2] https://github.com/typedclojure/typedclojure

[3] https://github.com/typedclojure/typedclojure/blob/main/examp...

[4] https://docs.racket-lang.org/ts-reference/Experimental_Featu...

It's a shame. I thought Clojure, as the only Lisp currently used in the industry, would benefit from the great work of Racket folks the most. After all, static typing in your pet project is much less important (or even desirable) than in a production-quality software made by a team of devs under time constraints. It's strange to see JavaScript and Python getting (widely used) gradual type systems before Clojure when the foundational work on gradual type systems was done in Lisps (Scheme and Racket).

Are those successful products you are talking about small crud apps juggling jsons over https?

Idk why r u trying to act as if using types at $DAYJOB didnt matter, lol. Those are serious businesses

I don't like generics.

On the frontend I prefer JS over TS, because of the typing overhead of TS (both in types in amount of keystrokes).

But it's strange to connect typing and successful product. Doesn't make sense to me.

It seems reasonable to assume that the 99% comprises the bulk of production software, which is solving complex problems everywhere every day.

The remaining 1% can be valuable and interesting but come down to a small fraction of real delivered code.