Does anyone know why, anecdotally, it seems like the slowness of type inference is more of a pain point in Swift than in Ocaml, Rescript, Purescript, Haskell, etc?
[deleted]
The Swift compiler is slow due to how types are inferred
21–30 of 229 posts
Re: The Swift compiler is slow due to how types are inferred
#22One of the interesting tradeoffs in programming languages is compile speed vs everything else. If you've ever worked on a project with a 40 minute build (me) you can appreciate a language like go that puts compilation speed ahead of everything else. Lately I've been blown away by the "uv" package manager for Python which not only seems to be the first correct one but is also so fast I can be left wondering if it real…
> One of the interesting tradeoffs in programming languages is compile speed vs everything else.
In the case of Rust it's more of a cultural choice. Early people involved in the language pragmatically put everything else (correctness, ability to ship, maintainability, etc.) before compilation speed. Eventually the people attracted to contribute to the language weren't the sort that prioritized compilation speed. Many of the early library authors reflected that mindset as well. That compounds and eventually it's very difficult to crawl out from under.
I suspect the same is true for other languages as well. It's not strictly a bad thing. It's a tradeoff but my point is that it's less of an inevitability than people think.
Re: The Swift compiler is slow due to how types are inferred
#23The 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).
Does this improve when declaring all variables with explicit types before using them in expressions?
Re: The Swift compiler is slow due to how types are inferred
#24Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!
Re: The Swift compiler is slow due to how types are inferred
#25They never will, since it's also one of Swift's greatest strengths. What they may, eventually, do is dedicate the resources to minimize the negative aspects of the system while documenting clear ways to mitigate the biggest issues. Unfortunately Apple's dev tools org is chronically under resourced, which means improvements to the inference system and its diagnostics come and go as engineers are allowed to work on it.…
[flagged]
Re: The Swift compiler is slow due to how types are inferred
#26Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!
One could overload the * infix operator to support this type of multiplication. It just doesn’t come with the standard library.
Re: The Swift compiler is slow due to how types are inferred
#27Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!
No cast, just a conversion, depending on how you want the math to work. int * double would usually be Double(int) * double.
Re: The Swift compiler is slow due to how types are inferred
#28One could argue that anything that anything that makes the development process itself more efficient, as opposed to the compiling, is worth it since programmers themselves ain’t getting any faster anytime soon, but timing out after more than 40 seconds on a state-of-the-art CPU because of a handful of lines is just ridiculous.
These type inference landmines are all over the place with SwiftUI too. I run into them with View/Shape/Color frequently
Re: The Swift compiler is slow due to how types are inferred
#29Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!
You could overload * if you really don't want to convert the int manually
Re: The Swift compiler is slow due to how types are inferred
#30Wait, in Swift it's illegal to multiply an int by a double?? So you would have to explicitly cast index to a double? I definitely didn't expect that!
I think this is the correct way to handle this. I don’t know how many times I’ve been stymied by integer arithmetic and precision loss by implicit conversion. How should this be handled? Should the int be converted to a double before the operation, should the double be converted to int before the operation, or should the result be converted to an int or a double? As someone who writes code in many languages in a day, these implicit conversion rules can be difficult to remember. It’s best to enforce the developer to be explicit about the intention.