For your first question, yes, it can be optionally turned on and set to a specific value. In the early days of Swift it was quite useful. I still have it on in one project but it rarely shows up anymore and when it does it is usually a mystery as to why it shows up and there's no clear way to fix it.

For your second point, this is mostly the case for Swift as well. 123 defaults to Int so if you wanted a floating point you'd have to write let x: Double = 123 or let x = 123.0. Most people will default to the latter because it is less typing.

It is pretty rough but as someone who has been programming in Swift since 1.0 I can say it rarely happens in practice. In the early days it happened all the time where the compiler would trip up on random expressions. I can still get it to happen, especially on complex closure type things, but even if those did compile they're confusing enough where they really shouldn't make it past code review anyway. That url example should never either.

I am very curious as to what you're running into where you're seeing wildly slow type checking times.

No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.

That Chris Lattner is taking a very different approach to the type checker in Mojo is afaik due to this kind of thing.

isn't rust's compilation speed slow primarily due to its reference / lifetime checker, rather than the "actual compilation" of the program?

The IDE experience on Linux doesn't make it any better either.

Oh how I wish I could have a working Swift :(.

I too appreciate detail-free programs, and I wonder at the value of including all the typedecls and pointer markings, and lifetime markings, and mutability markings interleaved with the logic. Some people I guess believe that the details are "part of the program" and they aid understanding. Do you buy that?

I find that sometimes typedecls aid understanding, but they get in the way if they're the least bit complicated. I'm better off reading the program. I never had problems understanding Lisp programs for some reason.

it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?

Follow a couple of rules and this won’t happen.

Type annotate everything. Don’t mix integers and doubles, be explicit. Most important of all, do not ever make a long chain of nested result building function calls with those stupid trailing untyped dangling {} closures, especially when the closure expects an implicit return of an opaque ‘some’ type.

What I’m saying is, don’t use SwiftUI. It’s a pee filled kiddie pool to attract JavaScript react devs with awful performance and semantics.

Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".

That is exactly what happened and the competence of the engineers working on the language is not really relevant.

There is a reason why 1/3 apps in the Apple App Store are now written in Flutter instead.

> I think, though, that modern PLs need better solutions for adhoc overloading.

So, something like "How to make ad-hoc polymorphism less ad hoc"?

Going from 10s down to 6s is not nearly near sufficient to me. This should be instant.