Readit News logoReadit News
slavapestov commented on ML needs a new programming language – Interview with Chris Lattner   signalsandthreads.com/why... · Posted by u/melodyogonna
chrislattner · 2 days ago
Mojo has overloading, generics and a much more advanced type system than Swift (dependent and linear types etc), and compile time in all phases is very important. The Mojo design seems to be working well - it gives expressive power, good error messages etc.

It feels like a much better design point overall.

slavapestov · 2 days ago
I wasn’t trying to start a fight over languages, that would be silly. I also wrote a language once and then moved on from it (to your former language ;-)), so I know the feeling! I wish you luck with your new language, and I wish for many more languages in the future to try different approaches and learn from each other.

My original reply was just to point out that constraint solving, in the abstract, can be a very effective and elegant approach to these problems. There’s always a tradeoff, and it all depends on the combination of other features that go along with it. For example, without bidirectional inference, certain patterns involving closures become more awkward to express. You can have that, without overloading, and it doesn’t lead to intractability.

slavapestov commented on ML needs a new programming language – Interview with Chris Lattner   signalsandthreads.com/why... · Posted by u/melodyogonna
chrislattner · 2 days ago
Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics. Mojo does contextual resolution, but it works more similar to how C++ resolves initializer lists etc.
slavapestov · 2 days ago
> Bidirectional constraint solving. It's bad for compile time but even worse for predictable diagnostics.

That’s really only true if you have overloading though! Without overloading there are no disjunction choices to attempt, and if you also have principal typing it makes the problem of figuring out diagnostics easier, because each expression has a unique most general type in isolation (so your old CSDiag design would actually work in such a language ;-) )

But perhaps a language where you have to rely on generics for everything instead of just overloading a function to take either an Int or a String is a bridge too far for mainstream programmers.

slavapestov commented on ML needs a new programming language – Interview with Chris Lattner   signalsandthreads.com/why... · Posted by u/melodyogonna
chrislattner · 3 days ago
Mojo learns a lot from the mistakes in Swift, including this one. Mojo compiles much faster and doesn't have exponential time type checking! :)
slavapestov · 2 days ago
So what did you decide to give up on? Overloading functions with the same name, or bidirectional constraint solving? :)

These days though the type checker is not where compile time is mostly spent in Swift; usually it’s the various SIL and LLVM optimization passes. While the front end could take care to generate less redundant IR upfront, this seems like a generally unavoidable issue with “zero cost abstraction” languages, where the obvious implementation strategy is to spit out a ton of IR, inline everything, and then reduce it to nothing by transforming the IR.

slavapestov commented on ML needs a new programming language – Interview with Chris Lattner   signalsandthreads.com/why... · Posted by u/melodyogonna
drivebycomm · 3 days ago
Actually, even very basic code can cause it. The type system of Swift has issues.

https://www.cocoawithlove.com/blog/2016/07/12/type-checker-i...

let a: Double = -(1 + 2) + -(3 + 4) + -(5)

Still fails on a very recent version of Swift, Swift 6.1.2, if my test works.

Chris Lattner mentions something about him being more of an engineer than a mathematician, but a responsible and competent computer science engineer that is designing programming languages with complex type systems, absolutely has to at least be proficient in university-level mathematics and relevant theory, or delegate out and get computer scientists to find and triple-check any relevant aspects of the budding programing language.

slavapestov · 2 days ago
> let a: Double = -(1 + 2) + -(3 + 4) + -(5)

> Still fails on a very recent version of Swift, Swift 6.1.2, if my test works.

FWIW, the situation with this expression (and others like it) has improved recently:

- 6.1 fails to type check in ~4 seconds

- 6.2 fails to type check in ~2 seconds (still bad obviously, but it's doing the same amount of work in less time)

- latest main successfully type checks in 7ms. That's still a bit too slow though, IMO. (edit: it's just first-time deserialization overhead; if you duplicate the expression multiple times, subsequent instances type check in <1ms).

slavapestov commented on Swift-erlang-actor-system   forums.swift.org/t/introd... · Posted by u/todsacerdoti
cyberax · 2 months ago
I'm not sure how it can detect that outside of trivial cases. Any object that is passed into a library function can escape the current thread, unless the compiler can analyze all the binary at once.
slavapestov · 2 months ago
> Any object that is passed into a library function can escape the current thread,

In Swift 6 this is only true if the value’s type is Sendable.

slavapestov commented on The new skill in AI is not prompting, it's context engineering   philschmid.de/context-eng... · Posted by u/robotswantdata
slavapestov · 2 months ago
I feel like if the first link in your post is a tweet from a tech CEO the rest is unlikely to be insightful.
slavapestov commented on Why is the Rust compiler so slow?   sharnoff.io/blog/why-rust... · Posted by u/Bogdanp
fingerlocks · 2 months ago
The swift compiler is definitely bottle necked by type checking. For example, as a language requirement, generic types are left more or less in-tact after compilation. They are type checked independent of what is happening. This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.

This has tradeoffs: increased ABI stability at the cost of longer compile times.

slavapestov · 2 months ago
> This has tradeoffs: increased ABI stability at the cost of longer compile times.

Nah. Slow type checking in Swift is primarily caused by the fact that functions and operators can be overloaded on type.

Separately-compiled generics don't introduce any algorithmic complexity and are actually good for compile time, because you don't have to re-type check every template expansion more than once.

slavapestov commented on Redesigned Swift.org is now live   swift.org/... · Posted by u/lawgimenez
ohdeargodno · 3 months ago
That's a very debatable viewpoint.

From the horribly slow typecheck that gets exponentially worse every time anyone adds a protocol extension to <very common type>, the debatable choices made with concurrency/async/actors/swift6, the only-very-recently-stable ABI, the regular titanic undertakings needed for bumping any major version that are almost unheard of in most other languages, etc.

Swift is an alright language today. Good even. But for a 10 year old language ? It aged horribly, going through senseless breaking changes just to fit Apple's needs. It's fine if you're locked in on Apple's platforms, but any other language doing that would have been set on fire already. Look at how painful the python2/python3 split was: Swift did worse than that, _four_ times.

slavapestov · 3 months ago
> the only-very-recently-stable ABI,

You mean 6 years ago? https://www.swift.org/blog/swift-5-released/

slavapestov commented on Ask HN: SWEs how do you future-proof your career in light of LLMs?    · Posted by u/throwaway_43793
slavapestov · 9 months ago
Find an area to specialize in that has more depth to it than just gluing APIs together.
slavapestov commented on Emit   re.factorcode.org/2024/10... · Posted by u/kencausey
Pet_Ant · a year ago
Always glad to see Factor in the feed. Would love to see it get a type system though.
slavapestov · a year ago
You might find Kitten interesting: https://kittenlang.org/

u/slavapestov

KarmaCake day1149January 26, 2017View Original