181–190 of 229 posts
Earlier quoted context omitted.
> If you've ever worked on a project with a 40 minute build I've worked on plenty of C++ code based that had a 2 day build time! If you were lucky, incremental builds only took a few hours.
I remember hearing that Microsoft was excited to get full NT builds below 24 hours.
I'm suspicious about the truth of this claim. I don't think bidirectional typechecking is the problem in itself: the problem trying to do type inference when you have some extremely flexible operator overloading, subtyping, and literal syntax features. It's these "expressive" features which have made type inference in Swift far more computationally complex, not type inference itself. And certainly not bidirectional t…
Yeah, I agree. Regular H-M typechecking if you don't have subtyping is actually really fast. The problem is that subtyping makes it really complicated--in fact, IIRC, formally undecidable.
Earlier 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…
A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.
Earlier quoted context omitted.
I found an online Swift Playground, and here is a smaller test case that produces the "unable to type-check this expression in reasonable time" message: print("a" + "b" + "c" + 11 + "d") ...if you reduce it even further to: print("a" + "b" + "c" + 11) ...the error message is: :3:23: error: binary operator '+' cannot be applied to operands of type 'String' and 'Int' print("a" + "b" + "c" + 11) ~~~~~~~~~~~~~~~ ^ ~~ :3:…
`print((a + b + c) as String + n + d + e)` (I’m not sure of the precedence, that might need another pair of parens)
let a:String = "a" as String
let b:String = "b" as String
let c:String = "c" as String
let d:String = "d" as String
let e:String = "e" as String
let n:Int = 11 as Int
print((a + b + c) + n + d + e)
let a:String = "a" as String
let b:String = "b" as String
let c:String = "c" as String
let d:String = "d" as String
let e:String = "e" as String
let n:Int = 11 as Int
print((a + b + c) as String + n + d + e)
Earlier quoted context omitted.
A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.
This is a direction I've been pushing in partly because I'm using a significantly slower type inference algorithm in my language. I'm hoping with that and focusing on separate compilation I'll be able to keep the fancy inference without sacrificing the UX too much
If you have a massive codebase no matter how fast your compiler is, re-compiling is going to be slow. But hot code swap is even better in that you can keep any state around without having to set it up all over again.
In Java I could change a method implementation with the program running and as long as I didn't touch my class state it would just work. Re-compilation was slow, but hot code swap was _fast_ and I maybe did a recompile 3-5 times per day total.
Earlier quoted context omitted.
You can define multiple implementations for the Mul trait with different right-hand sides, no problem at all. https://play.rust-lang.org/?version=stable&mode=debug&editio...
Thanks, I didn't know that. In light of this, would you say that there is any sense in which Rust doesn't support the full extent of what is usually called operater overloading?
Wait, 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,…
Isn't it pretty evident that implicit conversions should only go from integer to floating point?
> precision loss by implicit conversion
That's a reasonable worry, but "Int" in general is only safe to store 32 bits, and 32 bit integers will losslessly convert to doubles.
Earlier quoted context omitted.
The only thing holding it back is Apple not investing into making it happen. Swift is in a weird spot where it has so much potential, but without investment in the tooling for other platforms (which is uncommon for Apple in general) it just wont happen, at least not as quickly as it could.
> The only thing holding it back is Apple not investing into making it happen. This seems to be a (bad) pattern with Apple, one that Google used to (and still does) get a lot of flack for, this habit of not investing in things and then thing dying slow, painful deaths. E.g. I remember this criticism being leveraged at e.g. Safari a lot. But, for better or worse, Apple is not a technology company, really, its a design…
One 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. 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…
Earlier 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…
A fast hot code swap of a module is a more important feature in my opinion, but it is somehow even harder to find these days than a fast compilation speed language. But ideally I want both.