Some things are very easy to do in loosly typed languages - just as letting a function take a string or int, and then parsing that string into an int if a string was passed in. In a loosly typed language you can just call something like if typeof(input) but in a strongly typed language you often need a lot more boiler plate and extra wrapper types to say the function can only take an int or string - for instance in rust you might need to wrap them in a enum first or some how create a trait and implement that for each types.

This is quite a bit of extra upfront cost some of the time that really rubs people that are used to loosly typed languages the wrong way. So they think it is slow to work with types. But what they never seem to count is the countless hours you save knowing that when you read a value from something and pass it to a function that wants only an int, that the value is an int and you dont end up getting 2 + "2" = "22" and other suprising bugs in your program. Which results in less time debugging and writing tests for weird cases the compiler does not allow.

But all that extra time if often not counted as that is dissociated from the original problem at hand. And they are already used to this cost - people often notice a new cost, but don’t notice a possibly bigger saving else where.

I agree, but I imagine dynamic type fans would say they don’t understand why explicitly stating types can be helpful.

It can be nice not to have to worry about types when you are doing exploratory programming. For example, I once started by writing a function that did a computation and then returned another function constructed from the result of that computation, and then realized that I’d actually like to attach some metadata to that function. In Python, that is super-easy: you just add a new attribute to the object and you’re done. At some point I wanted to tag it with an attribute that was itself a function, and that was easy as well. Eventually I got to the point where I was tagging it with a zillion functions and realized that I was being silly and replaced it with a proper class with methods. If I’d known in advance that this is where I was going to end up then I would have started with the class, but it was only after messing around that I got a solid notion of what the shape of the thing I was constructing should be, and it helped that I was able to mess around with things in arbitrary ways until I figured out what I really wanted without the language getting in my way at intermediate points.

Just to be clear, I am not saying that this is the only or best way to program, just that there are situations where having this level of flexibility available in the language can be incredibly freeing.

And don’t get me wrong, I also love types for two reasons. First, because they let you create a machine-checked specification of what your code is doing, and the more powerful the type system, the better you can do at capturing important invariants in the types. Second, because powerful type systems enable their own kind of exploratory programming where instead of experimenting with code until it does what you want you instead experiment with the types until they express how you want your program to behave, after which writing the implementation is often very straightforward because it is so heavily constrained by the types (and the compiler will tell you when you screwed up).

From some of my own conversations with people they don’t find it useful as a solo dev because they have to read the docs for dependencies even with types, and they only ever have to deal with their own code which they know we’ll enough that they see types as a waste of time.

The way I read it, he wasn’t suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.

Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.

Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.

But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.

Though I mostly abhor OOP, it taken in small doses can be good

Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.

Can you give any examples of such “otherwise valid programs”? Because a lot of times static typing also has ways to do everything dynamic typing can but it is just more difficult or (obviously) won’t have the benefits of static typing.

Rust does this too. In practice you just bump the lock file in rust and rebuild. It can be a bit rebuild heavy, but it’s not too bad with a proper cache.

I really prefer rust’s approach. The function signature is the contract. It makes it much easier to debug compared to overly generic pure functional code or c++ templates where everything is auto and perfect forwarded.

The only time in rust where this isn’t true is with async functions. That’s because the compiler adds a ton of sugar to make it easier to write.

Which I personally think is a good decision, although I like the clean looking syntax of Haskell, it’s often not obvious what the function takes (which is why most are type annotating their function)

But Rusts type annotations have non the less its limitations, when excessively using traitbounds (but I hope that will be soon better with impl everywhere (see e.g. https://smallcultfollowing.com/babysteps/blog/2022/09/22/rust-2024-the-year-of-everywhere/))

Nothing is going to be the best at everything. Been programming for a long time and it’s a general truism that every cool new thing comes with a real trade off. I just haven’t found Rust’s yet.

Maybe I get lucky and the trade off is just all the weird community drama.

yeah it has a really good blend of features, I think that it could have saved quite a few large companies a lot of money, as well, like facebook who keep re programming stuff, with D they could have used the same language and they would have very rarely re programmed anything, and when they did they would have been able to re use some code. so I am quite surprised it didnt catch on, but it did have a few problems, one being it got relatively popular too quick before it could mature. GC problems, and being too experimental, a very good language is hidden behind a lot of features.

It really is an awesome language! I actually dont use it at work, but I’ve been learning it.

• May I ask how your company uses it at work (not saying give exact company details, but a high level)?
• Do you use it for web apps or Android?
• Are any of your Devs migrating to it from Java?
• Why are you moving to it from .NET?

Typescript has many shortcomings. About every language does. But it’s an undeniable very strong benefit that you can code the front and backend with it easily. It runs everywhere. It’s reasonably fast, for aws lambdas I found it had really good cold start time. I suspect because node is built on V8 which is highly optimized to get code running asap.

That accessibility and versatility makes it in my opinion the best general purpose language right now.