[ativzzz]

Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good.

Sometimes, it's useful to bypass these things for a prototype and you don't care if it crashes on any edge case. This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code

[whytevuhuni]

I agree with this, but I don't think dynamic types is the only solution. Something like Roc[0] strikes a better balance: it gives you a flag for development, and when enabled, all compilation errors become warnings. The compiler substitutes every function it couldn't compile with one that panics at runtime.

[0] https://www.roc-lang.org/

[duped]

But a type error isn't an edge case! It means you've written something the compiler can't understand.

> This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code

I think you've got it backwards - TS is popular because people want to use types up front, but it has to work with JS, which is so dynamic that it's impossible to write a sound type system that can even touch it.

I don't want to reply "git gud" but I really am struggling to understand how people are writing code that where it is so difficult to use type information or where changing it is so cumbersome that you think it's a barrier. And I don't see many games or performant GUIs written in dynamically typed languages, particularly outside the web. Even in very dynamic languages like Objective C, things are still well typed.

[ativzzz]

> But a type error isn't an edge case! It means you've written something the compiler can't understand.

I get it! But the compiler here is getting in the way, so Rust is the wrong tool choice here, or for anything that requires quick prototyping (like the OP said)

> writing code that where it is so difficult to use type information

It's not difficult, it just takes longer. Typing up front works well when you know exactly what you're building. When you don't, or are doing experimental design, they just get in the way until you've settled on a direction. This direction is not due to technical constraints or language choice, it's simply that designing complex user interactions is hard and you don't know it's correct until you have users use it

> dynamically typed languages

Because the cost of prototyping in a dynamic lang and then fully rewriting in a performant language is higher than having slower iteration speeds in typed languages. But also, this is why a large number of new non-web GUIs use electron (or are mac exclusive, which offers other benefits for GUI development)

> I think you've got it backwards - TS is popular because people want to use types up front,

Personally, I mix it up. There are things I know what their types will be no matter what so i add them up front. Then there are other things which I do not know, and I add those types at the end once i'm performing the final cleanup before code review

The nicest part is, TS runs regardless. I often refactor my types frequently since I get them wrong a lot (especially the up front ones) and have TS in a failing state while developing, but the TS compiler doesn't get in my way, and still works for the types that I expect to have working

[Capricorn2481]

A type error means a type error, and nothing more. Type errors do not mean "incorrectness." Here is an example of something you can't do in rust, but can do in other statically typed languages.

```rust

struct Type1 { id: u32 }

struct Type2 { id: u32 }

fn main() {

    let obj1 = Type1 {

        id: 1

    };

    let obj2: Type2 = obj1; // compile error, Type1 is not Type2

}

```

This code works perfectly fine. These two structs have the same signature. The only thing that doesn't work is the names. There are dozens of things like this where your code works but the compiler is too strict. This is terrible for rapid iteration. It's good for other things like modeling your domain with types.

[dragonwriter]

[text deleted because it was based on a incorrecf recollection of the details of Rust features.]

[Capricorn2481]

This was just one example of type error != logic error.

> one is for things that are structurally identitical but semantically distinct where confusing them creates a semantic error, the other is for alternate (usually, more concise) names for an existing type

This is not always true. Sometimes there are cases where you have different type aliases and want to use them interchangeably. Now you have to refactor them to inherit from some general type that didn't exist before. I also could count on one hand the amount of times this has caught a genuine bug even with diligent domain modeling (Which I would argue is overhyped).

[dbrueck]

Exactly this. Typing in the final version is great. Typing up front is almost always getting in the way.

Most interesting programs involve a lot of figuring things out as you go, and so any "tax" on that process is one you hope to avoid. The last thing you want is for the language itself to be the source of that tax any more than it has to be.