slavapestov

FWIW both Swift and Rust have had value types and generics that abstract over unboxed values since the start.

Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different.

What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.

Similarly, the ‘indirect’ keyword can be omitted from Swift example in the blog post, for the same reason. A Swift Array stores its elements out of line, so an enum case payload can be an array type whose element contains the same enum, without any additional indirection.

Does anyone know of larger apps built using Factor?

The Factor build farm, the website, and the concatenative wiki are all built in Factor, if that counts.

In 2025 you can run apps targeting W95 just fine (and many 16-bit apps with some effort)

FWIW, Windows running on a 64-bit host no longer runs 16-bit binaries.

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.

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.

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.

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).

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.

I feel like if the first link in your post is a tweet from a tech CEO the rest is unlikely to be insightful.

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.

the only-very-recently-stable ABI,

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

Find an area to specialize in that has more depth to it than just gluing APIs together.

You might find Kitten interesting: https://kittenlang.org/

This “Jordan Cutler” guy has a nice grift going, makes money writing a newsletter about career advice when according to his resume, he only has five years of programming experience at best: https://jordancutler.net/assets/images/JordanResume.pdf

The whole point of being an “experienced developer” is that you know more than the new grad. What kind of experienced developer forgets basic computer science on top of which all else is built?

To be fair, you need at least one person on the team to do the actual work, while everyone else is “communicating and managing expectations”.

Basic coding problems involving data structures and algorithms are table stakes for a programmer. This whole thread is embarrassing.

“Total compensation” usually refers to base salary together with your yearly bonus and vested stock. Mortgage lenders will typically look at your W2 income which includes the bonus and stock.

The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.

Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.

Wait, I’m old enough to remember when IntelliJ used Swing. They wrote their own GUI toolkit since then?

Get a math or CS textbook and try solving some of the exercises.

FWIW This stack monoid is more conventionally referred to as the bicyclic monoid in the literature.

LFortran is structured around two independent modules, AST (Abstract Syntax Tree) and ASR (Abstract Semantic Representation), both of which are standalone (completely independent of the rest of LFortran) and users are encouraged to use them independently for other applications and build tools on top.

Modern frontend architecture comes to Fortran! Awesome.

My view now is that the applications are quite limited, but the math is still cool.

This is true of everything, of course. Everyone knows that “practical applications” is just a flimsy excuse to get funding for your cool math project.

I’ve found that the main benefit of learning math is not the practical applications of the theorems and algorithms themselves, but just the practice you get from using this approach to thinking. This also frees you up to learn the math you find interesting and not what you think might be immediately useful in your day job.

Getting dangerously close to 1.0. Congrats!

My biggest struggle has been finding good resources to learn the "proper" way to use it

Why stop at vi? Go all the way and re-orient your entire lifestyle around Unix text processing: vi, awk, sed, troff, and sh.

https://www.oreilly.com/openbook/utp/UnixTextProcessing.pdf

Sadly he passed away before completing Part 2. https://lists.gnu.org/archive/html/axiom-developer/2005-06/m...

Times are changin’. All you young whippersnappers wouldn’t believe that back in my day, Microsoft was evil, Apple was on the verge of bankruptcy, and Google was the scrappy upstart who prided themselves on not serving ads and irrelevant fluff on the search results page.