4 ms·

Yeah. I think "keyword" is less of an issue personally. At the end of the day, if we want to approach things like async / await and ownership, I would prefer "c

by liuliu 2y ago

Yeah. I think "keyword" is less of an issue personally. At the end of the day, if we want to approach things like async / await and ownership, I would prefer "consume / borrow" than some particular symbols. That has been said, I do worry that there are too much runtime stuff built into the language, and it doesn't seem there any desire to clean it up. Newer things like actors that people argues cannot be done as library brings runtime into the language. autograd is in the similar vein. Even automatic-reference-counting (a.k.a. classes) would be nice to move that out of core language. The end result is that Swift is a huge project for people to maintain, in both the compiler land and the runtime land. I am happy that Apple is paying for it, but ...

jarjoura 2y ago
I do find it quite unsatisfying the way the actor executor is somehow magically generated at compile time, without any way to build your own in Swift. It's also not obvious that actors are re-entrant until you stumble into it. It's quite interesting the way the swift compiler gets around its own complexity by wrapping core functionality as llvm builtins whenever the engineers hit a wall. Is it an abstraction? Not really sure what to call it, but I'm finding it becomes a very leaky design after working in large Swift codebases. Sure, there is always intentionality behind the decisions that get made, and not saying it its sloppy, it's not. However, every single language design decision feels one-off, and in 2024, the language is now made up of hundreds of little one-off decisions that somehow still work out okay.
- liuliu 2y ago
  Yeah. I guess that I misspoke a little bit. I am not even criticize actor (as in Go, there is a relatively "heavy" runtime to implement its green thread too). I was originally thinking about distributed actor proposal (and implementation) and forget to spell that out. > It's also not obvious that actors are re-entrant until you stumble into it. Yeah, this part is annoying. While understandable from runtime implementation perspective, it feels like a big mistake need to be corrected in the future. > the language is now made up of hundreds of little one-off decisions that somehow still work out okay. There are some fixes on these decisions, some times. For example, `some` / `any` fixed some associated type related weirdness that you need to workaround (this is a huge improvement for me at least). But some other problems remains: the existence of existential type is not obvious at all and can cause issues. For example, a closure type is not existential, and cannot be extended. This is OK most of the time, but then UnboundedRange is defined as a closure: https://developer.apple.com/documentation/swift/unboundedrange https://developer.apple.com/documentation/swift/unboundedran... so you cannot extend that easily (which would be ideal if you want to extend PartialRange / ClosedRange / UnboundedRange to do something like, return Python slice object?). I think this / or similar issue also made things like tuples to automatically conform to Equatable / Hashable protocol not easy to do, which is not big problem, but minor annoyance.
conradev 2y ago
They actually allow you to opt out of ARC in Swift 6 by marking types as non-Copyable (~Copyable), along with “consume” and “borrowing” keywords. There are restrictions (i.e. their use in generics is limited), but it’s pretty great for optimizing hot loops.
- jarjoura 2y ago
  Have you had much success adopting consume and borrow? Once you need anything in the swift standard library, you can't use a non-copyable struct with it. The keywords are all in too, so either you write completely self-contained rust-like code that doesn't touch your other code, or you revert back to using the older copyable types. I've tried many times to ease into using them, but I can never stick with them, and eventually revert. I do really like the high-level design though and look forward to it evolving into something usable.
  - conradev 2y ago
    Nope. The ergonomics are really bad at the moment. I also had to revert any places I used them in API surface. I haven’t had a use case yet where I could use them privately in the internal functioning of a type. I thought borrowing could still be used with Copyable types, though
danpalmer 2y ago
I agree, the number of keywords really doesn't get in may way day to day. You know what does get in the way? Lack of functionality. I use Go in my day job and it's really quite frustrating to write much of the time because the compiler does so little for you. I regularly hit issues that would be checked for me in Swift, I regularly write type-unsafe code because the type-checker isn't sufficiently advanced, or I implement slow things myself because it's impossible to use a generic fast implementation, and I don't want a week long side-quest implementing an obscure data structure in my otherwise 2 day long feature. In that way Go is much like C, and while it's trendy to hate on C++, there was a reason why C++ was created – C wasn't doing enough for people.

by liuliu 2y ago

jarjoura 2y ago

I do find it quite unsatisfying the way the actor executor is somehow magically generated at compile time, without any way to build your own in Swift. It's also not obvious that actors are re-entrant until you stumble into it. It's quite interesting the way the swift compiler gets around its own complexity by wrapping core functionality as llvm builtins whenever the engineers hit a wall. Is it an abstraction? Not really sure what to call it, but I'm finding it becomes a very leaky design after working in large Swift codebases. Sure, there is always intentionality behind the decisions that get made, and not saying it its sloppy, it's not. However, every single language design decision feels one-off, and in 2024, the language is now made up of hundreds of little one-off decisions that somehow still work out okay.

liuliu 2y ago
Yeah. I guess that I misspoke a little bit. I am not even criticize actor (as in Go, there is a relatively "heavy" runtime to implement its green thread too). I was originally thinking about distributed actor proposal (and implementation) and forget to spell that out. > It's also not obvious that actors are re-entrant until you stumble into it. Yeah, this part is annoying. While understandable from runtime implementation perspective, it feels like a big mistake need to be corrected in the future. > the language is now made up of hundreds of little one-off decisions that somehow still work out okay. There are some fixes on these decisions, some times. For example, `some` / `any` fixed some associated type related weirdness that you need to workaround (this is a huge improvement for me at least). But some other problems remains: the existence of existential type is not obvious at all and can cause issues. For example, a closure type is not existential, and cannot be extended. This is OK most of the time, but then UnboundedRange is defined as a closure: https://developer.apple.com/documentation/swift/unboundedrange https://developer.apple.com/documentation/swift/unboundedran... so you cannot extend that easily (which would be ideal if you want to extend PartialRange / ClosedRange / UnboundedRange to do something like, return Python slice object?). I think this / or similar issue also made things like tuples to automatically conform to Equatable / Hashable protocol not easy to do, which is not big problem, but minor annoyance.

conradev 2y ago

They actually allow you to opt out of ARC in Swift 6 by marking types as non-Copyable (~Copyable), along with “consume” and “borrowing” keywords. There are restrictions (i.e. their use in generics is limited), but it’s pretty great for optimizing hot loops.

jarjoura 2y ago
Have you had much success adopting consume and borrow? Once you need anything in the swift standard library, you can't use a non-copyable struct with it. The keywords are all in too, so either you write completely self-contained rust-like code that doesn't touch your other code, or you revert back to using the older copyable types. I've tried many times to ease into using them, but I can never stick with them, and eventually revert. I do really like the high-level design though and look forward to it evolving into something usable.
- conradev 2y ago
  Nope. The ergonomics are really bad at the moment. I also had to revert any places I used them in API surface. I haven’t had a use case yet where I could use them privately in the internal functioning of a type. I thought borrowing could still be used with Copyable types, though

danpalmer 2y ago

I agree, the number of keywords really doesn't get in may way day to day. You know what does get in the way? Lack of functionality. I use Go in my day job and it's really quite frustrating to write much of the time because the compiler does so little for you. I regularly hit issues that would be checked for me in Swift, I regularly write type-unsafe code because the type-checker isn't sufficiently advanced, or I implement slow things myself because it's impossible to use a generic fast implementation, and I don't want a week long side-quest implementing an obscure data structure in my otherwise 2 day long feature. In that way Go is much like C, and while it's trendy to hate on C++, there was a reason why C++ was created – C wasn't doing enough for people.