[taeric]

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping.

I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to an entity will be dangerous. Static or dynamic. Especially if they are persisted anywhere, as at that point it is all too easy to get static guarantees that aren't reflecting actual data.

[cageface]

This is a false equivalence.

You need all the help you can get maintaining large codebases and static typing is a huge help.

[taeric]

What did I make an equivalence between? Large codebases are hard, period. That is all I am saying. Having worked on 100k LOC systems in static and in dynamic, I will not claim either has a benefit. That is just hard.

Static analysis is, of course, good. If that is static typing or otherwise. So is running the code making sure it does what you want when running.

What is not a huge help, is a byzantine type hierarchy that nobody understands. Which is all too familiar to me from any codebase I have worked on with folks that dived straight into the type system before they knew what they were doing in the system.

Many strong type proponents have moved to the categories view. If you know the category type of what you are doing, the idea is that that will prevent bugs. But... that hasn't been my experience. Often it just hides what is actually happening behind another layer of jargon. Jargon that is not native to the problem being solved.

[rwalle]

"I will not claim either has benefit"

I bet that if you did a survey of developers who have worked on projects of this scale, 90% would disagree with your opinion.

[taeric]

Then do said survey? Find empirical evidence and share it.

My experience, sadly, is the louder a dev on the team is about either dynamic or static typing, the more likely that dev's code is something nobody else in the team wants to work with.

[random314]

Here is one sample point for your survey.

Static is better than dynamic for large projects, in my experience.

[taeric]

You should have more than one point of data. How many software systems? How old were they? How many contributors? How many bugs in each? Were any of them green field?

[super_flanker]

+1

[rendaw]

The equivalence you're making is that dynamically-typed large code bases are just as difficult to get into as statically-typed large code bases.

[taeric]

This implies that "difficulty" is a totally ordered set. Which... I find highly unlikely. Things can be very difficult in amazingly unique ways.

[scrollaway]

Large codebases tend to be harder than smaller ones within one language. But language to language, static typing is such a significant help that it makes a large difference.

I’ve been writing in python for 18 years, and yet I can far more quickly get into a large typescript codebase than a python one of equivalent size.

[taeric]

Amusingly, I hate python.

Static typing is a tool I like. I don't think we have evidence that it is an obvious win. And I've bounced off of several typescript code bases hard. To the point that I currently hate typescript. Despite being impressed with some of its capabilities.

Which is again to say ymmv. Bad code is bad with or without static types.

[kumarvvr]

> any system of 100k LOC will be hard to get into

To get a gut feeling of the system, i.e., to understand the 10000 foot view of a 100k LOC system, is orders of magnitude easier with statically typed languages than dynamic languages.

And that is mostly because those 100k LOC are done by probably dozens of developers and that leads to different styles, approaches, conventions, etc.

A statically typed language would remove a lot of those headaches, because it does force a semblance of structure, that can be easy to reason with.

A language like Python is awesome for a micro-services architecture though.

[taeric]

I call bs in this. To get a 10000 foot view of a codebase, you lean on diagrams and other lies of documentation. Note that I don't mean malicious lies. I mean simplifications and other happy path discussions of how things work.

This is no different from any system. Want to know how your car works? Start with a simplified diagram and gradually add more details.

Cars and other equipment are an amusing case study. What is the strongly typed version of a car schematics? Why does it look so different from what we think the idealized software should look like?

[reissbaker]

Anecdotal but — I've worked on many-million-LOC codebases in Ruby with large teams (pre-Sorbet and other type checkers, at Airbnb), and many-million-LOC codebases in typechecker-checked Python with large teams (Instagram). The typechecker-checked Python was way easier to reason about and refactor.

[albertopv]

Dynamic languages large code based are, in my 14yo experience, much much harder. Today no one a serious project with javascritpt, AFAIK everybody use typescript. Why?

[ReflectedImage]

JavaScript is a badly designed language. It was created on the fly over several decades by browser makers. People prefer to code in absolutely anything else.

WASM will probably kill TypeScript shortly.

[hakre]

Actually it was written (so it was done) in roughly two weeks and then released. The rest is part of modern history in terms of distribution of software and backward compatibility/portability.

The two other languages you mention, TypeScript and WASM, are more part of the same platform mutually benefiting from the progress than competing each other.

[albertopv]

Actual JS is based on original one, but have been much improved. Still the lack of static typing is a liability fixed by typescript.