[byhemechi]

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so much as an error.

[mijamo]

I think it vastly depends what you're writing. Any kind of function that does not have a fixed input and output gets a lot more complex with static types. And by extension any code that depends on that also gets more complex.

I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whatever I want progressively through object access methods. In Rust I ended up with more than 500 lines of type definition for the API and it still wasn't enough so I gave up. It is a bit extreme but when you work with an API from an ERP for instance you can get very very complex and extensive types that are not in your control and not very well specified.

Another good example is how complex all ORM internal code get once they try to add static typing. The typing in the ORMs code feels like black magic because they would really really need types as code but don't have it so have to rely on a bunch of crazy generic combinators.

[knallfrosch]

> Any kind of function that does not have a fixed input and output gets a lot more complex with static types.

If you don't know what kind of data people give your function and you don't know what's supposed to happen, how can you write that function? I think many people use too strict of a type system. If your function works with any object that has a toString()->string function, then just write an in-line interface that defines it.

I actually love TypeScript here. It allows for `any` if you're prototyping, lazy or simply don't care. It allows mapped types, where the next dev can see how a type came into being - for example, Mutable<T>, Readonly<T>, Required<T>, Partial<T>. The names actually speak for themselves! And it eliminates the Java-style verbosity of creating classes and files all just for a type.

[mdx97]

> I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whatever I want progressively through object access methods. In Rust I ended up with more than 500 lines of type definition for the API and it still wasn't enough so I gave up.

You can always deserialize things as `serde_json::Value` instead of making types for everything to get similar behavior out of Rust.

[rTX5CMRXIfFG]

The perceived difficulty of static typing depends on the type system itself. For example, there was a version of Swift where it became extremely painful to work with String and Substring, or Array and ArraySlice, which you’d intuitively just pass around whenever you’re making smaller pieces of collections but which the compiler complained about during type-checking when you are substituting one type for another. They solved the problem by just defining a protocol such as StringProtocol (and just reusing Sequence for arrays I think) and using that protocol wherever parameters are passed around, so it became possible again to swap those types for each other.

So then there’s more code for the language devs to write of course, but that’s just the cost of safety, which is highly desirable if you want the technology that you are building to be attractive for use in systems where correctness is critical, which also tend to be highly valuable. As a working professional it’s in my best economic interests to have such valuable tools in my skillset.

[olivermuty]

Elixir dev here, just to put the context in place first hehe.

Couldn’t that thing be typed as the web format? A nested set of string props with either string or number types in the leaves.

Then use those types to traverse and pull into «real» types?

I like to put structured data into structs in elixir too and the above is essentially what I would do in Elixir.

I don’t know rust well enough to see if I am missing some nuance

[wofo]

Lack of proper types is what killed the joy of programming in Elixir for me (I lasted 6 months, hoping I would somehow adapt, but the experience was so miserable that I decided to move on). I simply can't understand how anyone can be productive in a big codebase without the rigor of static typing, but those people exist, so I guess there must be something about our brains that divides us in the dynamic vs static typing camps.

[toolz]

I'm firmly in the camp that it's all perception. The studies I've seen aren't what I would consider conclusive, but they certainly suggest there is very little difference in the output and bugs of dynamic vs static languages.

In my experience, static typing seemed to lend itself to poor testing, maybe some sort of belief that static types were good enough to not need tests that can prevent regressions. So from my point of view the static typing is negative value. It prevents such a low value class of bugs while seemingly incentivizing people to be lax with the most important classes of bugs.

[solidninja]

Nice to see that I'm not the only one - lasted 9 months trying to adapt to Elixir and couldn't. My background is Scala/Rust with heavy use of effect systems and reliance on writing the types out and then solving the puzzle of how to make everything fit. The tooling is pretty poor due to lack of investment compared to some of the other languages, and the debugging story is not great either. But hey, it works for some.

[d3ckard]

I believe this as well. I like dynamic typing, because it often feels to me that rigour of static typing is slowing the prototyping phase. Plus overusing types creates a lot of boilerplate. In one of the frontends I've seen adding a boolean field to a form required changing over 10 files - thank you Typescript.

On the other hand, sometimes I feel like it has a lot to do with test writing. I feel people enjoy static typing, because you can get a feedback loop catching certain things without writing any tests. If you do write tests, all the type errors get caught pretty immediately anyway, so I just don't see the benefit.

Personally, the biggest advantage of dynamic typing for me is the ability to skip formalities for a time. If I want a function that can modify any struct with field "val" in (by, let's say, setting it to zero), I can - and I don't have to do multiple definitions, I don't have to define an interface. Just a function and I am done. If I want to skip error handling for now and only code the happy path, I can - and my program will work (and crash on error, but in some cases it's ok).

As the projects get more complex and require higher safety guarantees, static typing helps in ensuring nothing got broken - but nothing beats dynamic typing for prototyping.

[josephg]

I’ve swapped back and forth between static and dynamic types a few times in my career. Java and C/C++ to JavaScript (and coffeescript) to typescript and rust. The entire time (30 years at this point) I’ve felt like whatever I was doing at the time was obviously the one true way to program. I feel that now - that what I’ve been doing lately (static typing) is clearly superior. Even for throwaway JavaScript based projects at the moment the first thing I do is install typescript.

I’m spitballing on the reason - I don’t know why it’s like this. But maybe it’s because static typing encourages you to write & plan your types first. When you know the data types, all the functions kind of flow around your types and everything feels like it obviously flows from that. With dynamic typing, it’s the reverse. I find myself writing my functions first (top down or bottom up) and then backfilling what arguments and data everything needs to pass around. I run my code a lot more as I develop it to stop bugs creeping in. And because I can run my code at any time. There’s no type checker stopping me from trying things out.

[spion]

I've been on both camps, so I'm hoping I can give some insight.

Lots of statically typed languages are very strict about their types and have too many of them. You have to admit, when you're trying to build something difficult and focus on getting the business logic part of your program right, the last thing you want to be thinking about is e.g. whether you need a String, ByteString, LazyByteString or any of the other types of strings, and which library decided to accept which one. At some level its definitely useful to distinguish between those, and I'm sure a lot of libraries make sensible choices. But initially in the development of the program its just unnecessary busywork that distracts you from the important bits.

In the past, typed languages also made it a bit harder than necessary to create new types, especially in situations where you have serialization and deserialization. And finally, we had to do all this work, and for what? To be unable to prevent the most basic of errors i.e. NullPointerException? You have to admit, it was a hard sell.

A lot of things have changed, however. TypeScript makes it really easy to define types, anywhere - inline on the function in the argument, or right above it. You can pretend the type is correct at deserialization time, or you can use libraries like `zod` to both define a validator and a type in the same syntax - its up to you. Rust similarly has powerful and easy to use tools like serde - structs and enums are easy to define, and easy to attach metadata to them quickly to (de)serialize them accurately. Huge differences from the old world of getters and setters and NPEs.

When using dynamic languages, there are techniques to make things easier. There is the often mentioned testing, which does help verify a large subset of code paths. Lesser known and more subtle technique is coming up with and following a strict naming convention for properties, for example, and to keep things as consistent as you can in general. This is why you often see so much focus in code reviews about conventions, linting and so on.

Nowadays I guess it mostly depends on how good your dynamic language techniques (at the team level) are, as well as what your treshold for type system annoyances is. There are still some annoyances even in the best type systems, but its gotten way, way better.

[aerhardt]

My best programming experience ever has been in OCaml and I love the idea of Elixir, but I can't even bring myself to try it because I know I'm not going to enjoy not having types. Even something as allegedly shitty as Python's type system would do it for me. I'm aware that there are ongoing projects to add typing to Elixir and I'll keep watching out how they evolve.

[ra]

> I guess there must be something about our brains that divides us in the dynamic vs static typing camps.

I've wondered if that's a thing. It seems to be.

[swader999]

The only way I've seen it work (rarely) long term is with extensive unit tests and that takes incredible discipline.

[camgunz]

It's really hard to prototype w/ static typing. It's not really about mechanics; annotating parameters or return types, that stuff's easy. The problem is that in prototyping you're changing a lot of stuff because you don't necessarily know what the structure or types will look like, and every time you change something or rethink your taxonomy you have tons of type updates to do.

[rishav_sharan]

I just moved from typescript to javascript and for me it was just that I own the database, i own the api surfaces and as such I don't need to enforce any kind of type checking as the api schemas are sufficient for my case.

I would definitely use type safety if I had a lot of external data sources. or if there are lots of people working with me. Otherwise, I am beginning to go back to dynamic languages at least for web dev.

[hosh]

I'm currently working on a data engineering team, unborking some things on a team where all the original developers of the codebase had left. Up until then, I wrote Ruby for over 10 years, and Elixir for 3. I didn't have an opinion about JS or Typescript before this project.

Typescript does not solve the fundamental problems of JS. I'm not convinced it really solved the issues related to ingesting data from many different data sources. The data quality issues were still there.

If I were rewriting the whole thing, I'd rewrite it with Elixir (of course), if only to have a sane way of handling errors.

[MrJohz]

That's an interesting decision, because it's the reverse of one of the big complaints about Typescript: that it only works up to the API boundary, and doesn't include external data sources (unless you use libraries like Zod to combine runtime and static type checking).

For me, Typescript is more useful, the more of the codebase I "own", because it means I can be more confident that all the types reflect the true types of the runtime data, which means I can change things more confidently and quickly. Do you find that you're refactoring and changing things less with dynamic languages? For me, I think that's the number one magic feature that I miss when I use languages without explicit type systems.

[sensanaty]

I don't really write huge complex types in TS, I basically stick to just the native data objects like string, number, boolean etc., but even then I find it so useful just for the autocomplete that you get out of it.

I jumped into some code I haven't touched in half a year the other day so had 0 recollection of any of it, thankfully cause of the types I knew exactly what to pass where and what to expect back without even having to read any of the code other than the type definitions.

I love me some dynamic languages, but damn if it isn't nice to have that kinda power available to you.

[Kiro]

That only works for people with super memory. I already forgot what the code I wrote yesterday does. If you showed me code I wrote a month ago I wouldn't even know it was me who wrote it. I could never rely on just remembering API surfaces.

[mstipetic]

Every time an elixir discussion starts a vocal segment of people just starts complaining about types. Ok we get it you like types, can you leave the rest of us in peace

[lucasyvas]

To be fair, it's the author's fault this time. They brought it up at the very beginning in the third paragraph.

The author's joy will also be short-lived because static typing is coming and will likely win out if the implementation is solid.

[sph]

It's just a hype phase. Types are cool, but in the past few years they seem to be the panacea for all problems, by inexperienced engineers that have got their first taste of Rust and Typescript. As if writing in Typescript would produce less buggy, more stable or more maintainable applications than using Elixir.

I'll say types are cool again before I get routed by angry static typing zealots.

[prophesi]

Does José need to write up an elixir-lang.org blog post every other week on the status of their type system project for HN's collective memory to know it's in the works?

[keep_reading]

While you're waiting for official support in the language, just properly document functions with @spec and change them to @spec! after adding TypeCheck to your project and viola, you get powerful type checking at runtime with almost no performance impact. The error messages it produces are so beautiful.

https://github.com/Qqwy/elixir-type_check

[pleoxy]

It does slow some of us down. It's not really about terseness. I can write code that works on all primitives that might be sent down pretty easily. That code, sometimes is longer than limiting the inputs by types would be. I can also write code such that it only runs if the structure of the data is as required for that code to run, allowing for nulls or missing nested objects.

These two patterns allow you to write most code, type free, that gracefully handles anything you throw at it while always doing the right thing.

Making changes to such a system is easy and friction free.

Not many type advocates speak of the downsides of type systems, always pitching the net win and ignoring the actual cons.

When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I get that having discipline in code patterns and the required robustness is a difficult ask at some organizations and some devs. In that circumstance it's better to have a minder in a type system that enforces base the conventions for everyone.

[lolinder]

> When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I don't really see that as "fighting the type checker", I see it as the type checker doing its job and warning me of the places where my refactor broke things. The alternative isn't usually that my refactored code magically works, it's that I have to manually grep through the codebase looking for all the places where I might have broken something, and get runtime errors if I don't catch them all.

In that sense the experience of struggling to make a refactor work isn't optional—the choice you get is whether you want the compiler to assist you with it or not.

I realize there are exceptions for certain types of refactors to certain types of functions, but the vast majority of patterns I've ever seen in any codebase—static or dynamic—are patterns that are difficult to refactor without a type checker and trivial to do with one.

To be clear, there are other reasons to prefer dynamic typing, and I'm not trying to say you're wrong to prefer it, but you're not going to get very far trying to persuade a static types fan that refactoring of all things is better in the dynamic world.

[Munksgaard]

> When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I'm not sure exactly what you're saying. If your language is strongly typed, you'll get type errors no matter what. The only difference is whether the type errors happen at compile time or run time. Let's take a hypothetical example:

Let's say I have a programming language called Foo. There are two ways to run programs written in Foo, using the interpreters A and B. A and B are identical, except for that fact that on startup, A will check that the given program is well-typed (static type checking), while B defers such checks to runtime (dynamic type checking).

Given a well-typed program X, I can run X with A or B without ever encountering a type error. Now, I make some changes, like you suggest, and I attempt to run it again. If the resulting code is not well-typed, I will immediately know when trying to run it with A, but with B I have to be lucky enough to hit the specific case that isn't well-typed.

If I understand you correctly, you're saying that you can easily make changes in a dynamic language without _ever_ causing run-time type errors. If that's the case, you would have _exactly_ the same experience whether you ran your code using A or B.

[cglan]

Making code that works on all primitives and accounting for nulls/empty each time is way more difficult than using a type system.

That’s the same argument people always use. “If you account for every case and also have 30 billion unit tests you can avoid all the problems”. The reality is, people don’t. They cut corners, they forget, or they simply make mistakes.

Not only that, debugging a system without types is a terrible experience, and IDEs don’t offer nearly the same level of refactoring support for untyped languages bc it gets very hard or impossible to infer what’s going on.

If it’s a personal project or a small script, untyped languages are fine. Any other scenario you should be using types

[passion__desire]

Does the code really need to be verbose? Scala does a pretty good job. Infer once at first declaration and enforce throughout.

[jb1991]

As does swift.

[whalesalad]

static typing is a means to an end. if you can achieve the same end without static typing, good right? that is the goal of spec.

the creator of the language has a fantastic talk on this https://youtu.be/giYbq4HmfGA?si=LgSHZupSuR-kMXmj

[magicalhippo]

For me, a huge part of it is that I find static typing to make the code a lot more self-documenting.

I can easily see what is passes or returned, and if I'm unsure about the details of the type the answer is a click away, or a short web search away at worst.

Significantly reduces my mental load, allowing me to be vastly more productive.

[Dowwie]

The lack of types is hard to defend. Yet, the failed pattern match triggered at runtime becomes immediately obvious from the stack trace. You fix the pattern and move on.

The cost of this mild inconvenience is still far less than the cost of satisfying types.

This aside, I want typed elixir.

[bradrn]

> This aside, I want typed elixir.

It’s happening: https://elixir-lang.org/blog/2023/06/22/type-system-updates-...

[epiccoleman]

I love elixir, but I would also love it more with a sort of laissez-faire type system akin to TS. Glad to see they're working in that direction.

One of the best features of type systems is they make editor completions and navigation work better. Elixir's LS is pretty good, but editor support just isn't nearly as good as what you can have in a good (read: Jetbrains) IDE with a strongly typed lang like C# or Java.

[realusername]

Elixir is a bit in the middle, with the massive amount of very specific pattern matching for each function and the fact that modules are just plain collection of functions and not objects I would say it's the most static of dynamic languages.

They are working on typing it now from the blog posts I've seen and they will probably be successful because the language is well suited for that in my opinion

[peoplefromibiza]

> I really don't like not knowing what format data is in.

Which is orthogonal to what the type is

The shape of the data is much simpler to handle in Elixir than in, to name one, Java.

> a vast number of possible errors caught at compile time

if it's a vast number, usually it's because either:

- you're not familiar with the code base (and you'll make a vast number of other kinds of errors)

- you're making a huge refactory and you're used to rely on a compile-driven workflow, but there are so many alternative ways to handle them

> things go wrong in production

the usual wisdom applies here: static typing does not replace input validation, be it user provided data or function parameters

[solidninja]

Static typing can replace input validation though - if you make illegal states unrepresentable. That way you bake validation into your types e.g. using refined types: https://blog.rockthejvm.com/refined-types/ in Scala

[csan_gonzo]

I've been using Elixir for over a year now and the only thing that's missing for me is a static type system, really looking forward to this: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua... Also keeping an eye on Gleam: https://gleam.run/ .

[jwells89]

In my experience, static typing takes a different way of thinking that can take a while to get the hang of, and during that adjustment period a lot of people are going to significantly slower. I definitely felt it coming into Swift, being used to Objective-C and to a lesser extent Ruby.

Having grown accustomed to static typing, not encountering errors until runtime, or worse having errors manifest as type-related misbehavior and potentially not be immediately apparent is much more frustrating than it used to be.

[gampleman]

An important thing to realise is that "static typing" isn't just one thing. The details matter. For instance, type inference is a huge deal in making static typing not painful. Local type inference is something that pretty much all modern languages have adopted, since it makes writing out function bodies much less painful. But I think a lot of static typings bad rep comes from older languages that required lengthy annotations everywhere.

Then you of course have global inference, where you can write code as tersely as in a dynamic language, but still benefit from type checking and add annotations later as a form of documentation for readers.

It also changes the way you code. The best experiences from static typing come IMO from doing type-driven development, where you sketch out your problem first at the type level, then fill out the implementation at the value level. In dynamic languages, you can't program like that. So if you use the same mindset you will find the language limiting.

[dartos]

Static vs dynamic types are whatever.

Weak typing is what causes all sorts of issues.

With dynamic strong types, you can still have a tool like dialyzer figure out potential type issues before shipping, but weak typing means anything goes.

[threatofrain]

I think static typing (without escape hatches) slow you down when you're a library or framework author, or you're doing something high performance. The reason being that there are many trivial and non-trivial propositions which the field has ironed over but the core language/compiler team hasn't caught up yet.

I've seen a lot of authors do crazy type things to get around the type system (like typing out recursion to the n-th level by hand), and I think many open source projects are slowed down by the lack of a type wizard on their team.

[curtisblaine]

In my experience, static typing greatly slows you down when you're prototyping, at least for a short time, then it moderately speeds you up when you're productionizing and maintaining.

[liampulles]

I think loose typing helps to prototype faster, while static typing helps you write the correct/safe version faster.

But part of doing the correct version is clarifying spec, and prototyping can help with that - so it is a weakly held opinion.

[mrcwinn]

I could not disagree with this more. You are aided in prototyping by forming an early opinion on your data models. I would argue there's nothing more important in conceiving of something new than understanding the shape and relationships in your data. Typing does that.

And nothing slows a developer down more than accruing technical debt as they build. It's like having tar stuck to your shoes. You will work the fastest when you have nothing to pay back because your mental model of the application is aligned with the intention of your program.

(That said, I don't think you necessarily need a strong static type system to achieve these aims.)

[andrewstuart]

It slowed me down until I had enough experience then it sped me up.

[hahn-kev]

I actually think it's pretty similar to different automated testing camps. Some people say they build faster with TDD, and others say it slows them down.

[jacquesm]

Usually it is because people have a short term view of software, but in practice software lives for much longer than most people can imagine at the time of writing and that initial burst of productivity when working on a new system is even more present in a type-free and test-free environment.

But once that honeymoon phase is over you usually realize that types and tests were invented for a reason and beyond a certain level of complexity they are absolute must-haves if you want to have high confidence it all works as advertised and to be able to effectively refactor your code.

[weatherlight]

because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.

[artdigital]

As someone who worked with Elixir for the past couple years, and maintains multiple libraries in Elixir - nah not really. Static typing is the thing I'm missing with Elixir.

No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed.

Dialyzer is great but typespecs and pattern matching only get you so far. You'll always run into situations where the shape of data is not clear, and you have to open a REPL to do an IO.inspect somewhere

[ryanjshaw]

I'm building a static analyzer for Solidity in F# and the data shape of Solidity AST nodes overlaps frequently enough that explicitly specifying types is necessary just to get things to compile.

I can't imagine building something like this in a dynamically typed language. The way I see it, static typing is like writing inline unit tests to save yourself many, many headaches later.

[jddj]

Better type inference is faster than more ceremony, but more ceremony is faster than nothing at all, in moderately complex projects.

[mib32]

Yeah but it doesn’t matter - if someone inputs something weird you will anyhow fail with TypeError