Hacker News Reader

Comment by otoburb | Hacker News Reader

>>"In reality, gradual typing ends up giving you the worst of both dynamic and static typing: you get the uncertainty and lack of safety (in dynamically typed contexts) of dynamic typing, and the cost of trying to fit your ideas into a statically typed type system. I also found that the use of gradual typing didn't actually make me more productive compared to using static typing."

The Elixir team didn’t get that memo because they are actively in the process of researching and working on a gradual type implementation.[1]

[1] https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...

View on HN

Pursuing gradual typing makes sense when you've got an established dynamic language and want to incorporate typing into it (forget Elixir, let's just look at the massive success of TypeScript). But as OP's recommendation says - "for new languages", gradual typing has lots of costs and fewer benefits.

To put it in other terms: my informal impression is that the dynamic "features" of TypeScript are used grudgingly; the community strongly pushes towards strictness, eliminating anys, preferring well-typed libraries, and so on. There's little appetite to - in a single project, unless absolutely required - mix-and-match dynamism with staticness, which is the thing that gradual typing gets you. Rather, it feels like we're migrating from dynamic to static and gradual typing is just how we're doing the migration. But in the case of a new language, why not just start at the destination?

I wish Python was further down this path— I experimented with adding annotations and the mypy checker to a bunch of code at my company, and it seemed hopeless. Most libraries didn't have annotations at all, or there were annotations being maintained by a third party in a separate pypi package, but the annotations were out of sync with the main project and thus blew up in weird ways.

I feel for the people trying to develop these gradual systems but it's truly a herculean task, especially in the Python community that is now understandably so extremely shy about major breaking changes.

I might be missing something, but the appeal of gradual typing to me is that I can mostly type functions, providing safe input/output boundaries, and avoid having to type every single variable (unless I have to do so for performance reasons, as I do in Common Lisp).

This approach is comfortable to me both in Erlang and in Common Lisp, I see it as a balance between safety/performances and development speed (and I'm saying that as someone using Go for all professional development and being really happy with its full static typing).

> avoid having to type every single variable

Most static languages don't make you type every single variable anymore. Java, C++, Rust, C#, and many others let you make the compiler infer types where reasonably possible. That's still full static typing.

My Python and Rust have about the same kinds of explicit type annotations in roughly the same places. My C++ has a little bit more, just because `Foo obj{a}` is more idiomatic than `auto foo = Foo{a}`.

You can do that with type inference and a strong, static type system.

I think the author's recommendation has some needed context:

> Recommendation: either make your language statically typed or dynamically typed (preferably statically typed, but that's a different topic), as gradual typing just doesn't make sense for new languages.

The "for new languages" part is really important. Gradual typing makes a lot of sense when you are trying to retrofit some amount of static checking onto an existing enormous corpus of dynamically typed code. That's the case for TypeScript with JavaScript and Elixir with Elixir and Erlang.

What about Julia?

Julia isn't gradually typed. It's strongly but dynamically typed.

Oh yeah, as far as I know Elixir has a lot of calling back and forth with Erlang code. So that makes for a super tricky type system problem.

I think the macros make it even harder. Elixir appears to be done almost all with macros -- there are lots of little "compilers" to Erlang/BEAM.

Raku (formerly known as Perl 6 and a radically different language than Perl 5) uses gradual typing on purpose. It's a cool language that has a lot of advanced ideas, but has basically been in either the design or beta stage for like two decades.

>for like two decades.

IOW, Raku is a gradual type of language.

Other puns are not as good as this pun

You're right about this applying to new languages. I've added a note to the article to (hopefully) make this more clear.

Well, there's no memo (real or as a manner of speaking). It's just this person's preference.

I think gradual typing is a nice concept, and his arguments against it amount to "gradual typing is not stating typing", which is like the whole point. E.g. he goes on how the compiler can't do some optimizations on functions using gradual typing, but, well, it isn't supposed to anyway.

The benefit of gradual typing is that you can make your program fully dynamic (e.g. for quick exploration), and if you want more assurances and optimizations make it fully static, or if you just want that for specific parts, do them static. And you have the option to go for any of those 3 things from the start.

The problem about the whole "it's faster (productivity wise) than static typing" has, as far as I know, never actually been proven (certainly not through repeated studies).

Having worked with both dynamically and statically typed languages extensively, I never felt I was _more_ productive in a dynamically (or gradually) typed language compared to one that was just statically typed. For very basic programs you may spend a bit more time typing in a statically typed language due to having to add type annotations, but typing isn't what I spend most of my time on, so it's not a big deal.

In addition, that work you need to (potentially) pay upfront will help you a lot in the long term, so I suspect that for anything but the most basic programs static typing leads to better productivity over time.

I think it's unfair to criticise the lack of studies for that specific question without acknowledging that there are exceedingly few studies that show a benefit for static typing despite the fact that a huge number of people feel that there must be an effect.

IIRC there was a study that looked at the proportion of Github issues labeled as bugs, by language. Clojure came in with the lowest proportion. I overall prefer static typing, depending on what I'm doing, but I think avoiding ubiquitous mutable state is a lot more important than typing.

>The problem about the whole "it's faster (productivity wise) than static typing" has, as far as I know, never actually been proven (certainly not through repeated studies).

Neither has the opposite, so there's that.

There's an ACM paper too ("An Experiment About Static and Dynamic Type Systems", 2010) which found higher productivity for the same code quality with dynamic typing. Of course a few papers here and there, pro or against, are as good as none. It's hardly a well studied area.

Besides, one or the other proven better doesn't mean much, just like you liking eggs over easy vs scrambled eggs doesn't depend on some study. If it works for you, and you're more productive with dynamic typing or static typing, use that.

Even if a study "proved" that one kind is "more productive" based on some statistics from measuring some group, or that it has "less bugs" most people when given a choice would still use what they prefer and makes them, as individuals, more productive and happy coding.

>Having worked with both dynamically and statically typed languages extensively, I never felt I was _more_ productive in a dynamically (or gradually) typed language compared to one that was just statically typed.

Depends on the type of program, the type of programming (e.g. imperative/declarive/functional/logical/OO or some combination and so on), the program's scale, the team size, and other aspects, including individual aptitude and preference, not to mention the language and its semantics beyond dynamic/static (and the ecosystem too). I'd certainly be way more producting using dynamic numpy than some C equivalent, even if as a lib it had feature parity.

>In addition, that work you need to (potentially) pay upfront will help you a lot in the long term, so I suspect that for anything but the most basic programs static typing leads to better productivity over time.

There are problems where upfront work is not a benefit, e.g. if it means getting behind in building your MVP or getting behind a competitor adding new features faster while you "perfect it", and your early stage startup loses steam. Also for things where the overhead of upfront might put you off from even attempting them. It can also be a problem to have big upfront costs for exploratory programming and searching into the problem space for your design/solution.

What you can do is the opposite, integrate a “dynamic” type into a statically-types language, like C# does: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

This lets you use dynamic typing when you want, and enables more seamless interoperability with dynamically-typed languages.

Is it not literally the same on a type system level? Of course it could be very different from a user-perspective, as the ratio of `dynamic` will be very low in case of C#.

It’s not the same, because with “dynamic” the client code decides that it wants to use a specific object dynamically rather than statically, whereas with gradual typing it’s the object/class that decides that it now has (or hasn’t) type annotations. Aside from that, the default is reversed.

A sibling addresses the nuance expressed in “for new languages”. But even if the original author’s opinion was that gradual typing is always bad, why does that mean we should dismiss the Elixir team’s efforts?

I have opinions about Elixir, mostly around aesthetics (for context, I started programming in Python, not Ruby), but that doesn’t mean my opinions are objectively more valid than those of a genius like José Valim.

I’ve actually found Elixir to be very well-designed and internally consistent, and after two years using it, it’s obvious to me that José and team are very thoughtful and deliberative. I don’t think they want to introduce gradual typing because it’s trendy.

Reply on news.ycombinator.com