There are fast type inference algorithms available today, such as MLStruct. [0]
The Swift compiler is slow due to how types are inferred
101–110 of 229 posts
Re: The Swift compiler is slow due to how types are inferred
#102Earlier quoted context omitted.
I wouldn't describe Swift itself as having so much potential: I loved it and advocated for it, for years. After getting more experience on other platforms and having time to watch how it evolved, or didn't as per TFA, it's...okay to mediocre compared to peers - Kotlin, Dart, Python come to mind. If Foundation was genuinely cross platform and open source, that description becomes more plausible for at least some subse…
Im surprised to see Python in that list. Swift being type safe and Python not puts Swift miles ahead.
Python has Mypy (yes, it’s good enough, don’t bother arguing with me that’s it’s not “real”) and ecosystem is leagues above anything Swift can offer.
Re: The Swift compiler is slow due to how types are inferred
#103Earlier quoted context omitted.
Python real strength is the speed it can be taught, read and written.
It is an ilusion that Python is like BASIC, in reality Python 3.12 is rather complex, more like Common Lisp, when taking into account all language breaking changes during the last 30 years, its capabilities, the standard library, and key libraries in the ecosystem.
Almost every modern language with a well-specified runtime looks a lot like Common Lisp because Common Lisp was one of the first languages specified by adults and the Common Lisp spec had a lot of influence on future languages like Python and Java. For instance most languages have a set of data types in the language or the standard library, such as bignums, that are similar to what CL has.
Re: The Swift compiler is slow due to how types are inferred
#104Earlier quoted context omitted.
Im surprised to see Python in that list. Swift being type safe and Python not puts Swift miles ahead.
One of those awkward things where I don't like it, and wouldn't go back to nulls that blow up. But as far as being the right tool/accessible it ended up winning use cases where I expected scripting and Playgrounds to have mindshare
Mypy is non-nullable, as far as I know. Unless you do Type | None. (Or was it TS?)
Re: The Swift compiler is slow due to how types are inferred
#105Earlier quoted context omitted.
> One of the interesting tradeoffs in programming languages is compile speed vs everything else. Yes, but I don't think that compile speed has really been pushed aggressively enough to properly weigh this tradeoff. For me, compilation speed is the #1 most important priority. Static type checking is #2, significantly below #1 and everything else I consider low priority. Nothing breaks my flow like waiting for compilat…
I think this is a false choice. It comes from the way we design compilers today. When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. This is quite silly. Surely it’s poss…
> Surely it’s possible to make a compiler that takes time proportional to how much of my code has changed [...]
My understanding is that this is how Eclipse's Java compiler works, but I'm not positive.
Re: The Swift compiler is slow due to how types are inferred
#106Earlier quoted context omitted.
It’s not, actually, any more than any other language. That was Guido’s original plan, but show a page of modern Python code to someone who’s never seen it before and they’ll run screaming. There is a minimal subset where you can say it reads like pseudocode, but that’s a very limited subset, and, like AppleScript, you have to have a fair amount of knowledge to be able to write it fluently.
It is. Compared to other languages (short of JS without Symbols and async/await/promises mumbo jumbo or lisp) it has much easier entry barrier.
Python absolutely has async/await/promises, and it's actually quite a lot worse than JavaScript in this regard because Python _also_ has synchronous APIs and _no_ tooling whatsoever to make sure you don't call a sync API in an async function thereby blocking your event loop (which, if your application is a networked service with any amount of traffic at all, will typically result in a cascading failure in production). I'm no great fan of JavaScript, and I've written _wayyyyy_ more Python than JS, but async/await/promises is exactly the wrong example to make the case that Python is better.
Re: The Swift compiler is slow due to how types are inferred
#107The math type inference example makes the usual claim that "what if Swift can replace Python" a non-starter. As someone who have to deal with this on frequent basis, it is pretty sad. (I maintains s4nnc and a fork of PythonKit).
> what if Swift can replace Python
What a ridiculous statement. I’m willing to bet everything I have in life that this is never going to happen.
Re: The Swift compiler is slow due to how types are inferred
#108Earlier quoted context omitted.
I think this is a false choice. It comes from the way we design compilers today. When you recompile your program, usually a tiny portion of the lines of code have actually changed. So almost all the work the compiler does is identical to the previous time it compiled. But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. This is quite silly. Surely it’s poss…
> But, we write compilers and linkers as batch programs that redo all the compilation work from scratch every time. I don't think that there are that many production level compilers that don't perform the kind of caching that you're advocating for. Part of them problem is what the language semantics are. https://www.pingcap.com/blog/rust-huge-compilation-units/ gives an example of this. > Surely it’s possible to make…
Yes, rust has an incremental compilation mode that is definitely faster than compiling the whole program from scratch. But linking is still done from scratch every time, and that gets pretty slow with big programs.
I agree that it would be a lot of work to retrofit llvm like this. But personally I think that effort would be well worth it. Maybe the place to start is the linker.
Re: The Swift compiler is slow due to how types are inferred
#109Earlier quoted context omitted.
> aimed at app developers I'm a native Swift app developer, for Apple platforms, so I assume that I'm the target audience. Apps aren't major-league toolsets. My projects tend to be fairly big, for apps, but the compile time is pretty much irrelevant, to me. The linking and deployment times seem to be bigger than the compile times, especially in debug mode, which is where I spend most of my time. When it comes time to…
I tried to fix a bug in Signal a few years ago. One part of the code took so long to do type inference on my poor old Intel MacBook that the Swift compiler errored out. I suppose waiting was out of the question, and I needed a faster computer to be able to compile the program. That was pretty horrifying. I’ve never seen a compiler that errors nondeterministically based on how fast your cpu is. Whatever design choices…
That sounds like Web sites, designed by designers with massive monitors.
The tools team probably had ultra-fast Macs, and never encountered that.
It definitely sounds like a bug in the toolset. I hope that it was reported.
Re: The Swift compiler is slow due to how types are inferred
#110Earlier quoted context omitted.
I think most people haven't used many languages that prioritize compilation speed (at least for native languages) and maybe don't appreciate how much it can help to have fast feedback loops. At least that's the feeling I get when I watch the debates about whether Go should add a bunch more static analysis or not--people argue like compilation speed doesn't matter at all, while _actually using Go_ has convinced me tha…
In the case of Rust the fast feedback loop is facilitated by the `cargo check` command which halts compilation after typechecking. Unlike in Swift the typechecking phase in Rust is not a significant contributor to compilation times and so skipping code generation, optimization, and linking is sufficient for subsecond feedback loops.
I mean, you still need to run code at the end of the day. Yeah, the type checker will update your IDE quickly enough, but you still need to compile and link at least a debug build in order to meaningfully qualify as a feedback loop IMHO.