4 ms·

indeed that would be number 1 by a VERY high margin. It's pretty ridiculous to start with "world domination" as an objective and end up 10 years later without a

by bsaul 3y ago

indeed that would be number 1 by a VERY high margin. It's pretty ridiculous to start with "world domination" as an objective and end up 10 years later without a portable stdlib (aka foundation). Another issue would be a coherent concurrency system. Today we have a mix of gcd and actor system, declarative task, async await, etc which when put together makes me totally unable to understand what's going on in a real world program, unless you're doing like i do in my team : i specifically ban all modern concurrency apis in favor of the old ones. The same could be said with protocol extension + generics + class + structs. For each problem, there are approximately 4 possible designs with subtle tradeoffs. Swift team advocates for "expressiveness". My personnal experience is that all patterns and technics will ultimately end up showing in the codebase, depending on the mood of the developer. In the end, i've started to do like C++ developers end up doing : write guidelines on which language features are allowed, and which are forbidden. Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum. The end result is that go pushes you toward simple and maintainable code. Swift pushes you toward being fancy for no good reasons.

jb1991 3y ago
> protocol extension + generics + class + structs you are referring to basic languauge features... you consider classes and structs pain points? these are the basic building blocks of the language, if you find them painful this is definitely not the language for you.
- bsaul 3y ago
  protocol extension adds another axis of design, with all its new gotcha ( pat , overrides, etc) It looks great on paper and do enable beautiful designs in some cases. But after tasting languages like go you realize you can get away with struct & functions in 99% of the cases, and that having less design options is actually a plus. It lets you focus on what really matters : domain modeling.
  - jb1991 3y ago
    It's a lot more than "looks great on paper." My suspicion is that you have not really used and benefited from these features in a non-trivial way or you'd understand why they are there.
KerrAvon 3y ago
It doesn’t sound like you actually understand Swift or the Mac platform you claim it’s tied to. (a) Foundation is portable and available on Windows and Linux. (b) You are confusing language features and OS features. Async/await is part of the language. GCD is part of the OS. (c) Banning modern concurrency primitives is not viable forever — you’ll be left behind as the native APIs adopt them.
- bsaul 3y ago
  a : https://github.com/apple/swift-corelibs-foundation/blob/main/Docs/Status.md https://github.com/apple/swift-corelibs-foundation/blob/main... I wouldn't want to be the guy relying on this table advancement for his own project. The fact that they're rewriting it in pure swift probably says a lot about the quality of the current approach. b: makes absolutely no difference from a developer perspective. if you want to run threads in swift you're going to use gcd. c: my take with all apple software tech has been to wait until they've dogfooded their own tech long enough to make it useable. Worked very well for me so far, thank you very much.
slavapestov 3y ago
> Another issue would be a coherent concurrency system. Today we have a mix of gcd and actor system, declarative task, async await, etc which when put together makes me totally unable to understand what's going on in a real world program, unless you're doing like i do in my team : i specifically ban all modern concurrency apis in favor of the old ones. There’s a layering: - gcd is the lowest level - async/await lets you write tasks with suspension points (they wait for events to happen); but an async function is still conceptually executed serially - the Task API let’s you spin up async functions into various arrangements of parallel tasks and wait for those tasks to complete - ‘async let’ is sugar for creating a Task to compute a single expression - for async functions and Tasks to share data there is a Sendable model and various static isolation checks - actors build on everything else; actors are classes whose state is completely isolated to the actor, and all method calls are posted on the actor’s executor Memory-safe concurrency is hard. There’s a lot of ground to cover to replace the kind of things people do with shared state concurrency, and just actors alone are not enough. > Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum. I like the aesthetics of small languages too, but I think Go picked the wrong small subset. It reminds me of Java in the 1.x days, for x <= 4, where the language had fundamental expressiveness constraints that created a huge amount of unavoidable boilerplate and type unsafety in even the most basic programming situations.
- bsaul 3y ago
  "... reminds me of java" i was having doubts before go introduced generics. But the fact that they managed to add it so perfectly while maintaining the unambiguous focus on simplicity and structs made me confident they've really nailed it. The only feature i don't get why they haven't added yet is proper enum to get some kind of ADT. It looks super orthogonal to the language and quite convenient. However at this point i fully trust their taste. If they think it's going to lead to catastrophic design decisions, i fully believe them.
  - pjmlp 3y ago
    Go generics are far from perfect, and while they finally sort out a major paint point, they still leave some room for improvements.
fauigerzigerk 3y ago
It seems to me that their threshold for introducing new language features is extremely low. If something cannot be made to look flawlessly pretty using existing syntax they will go to any length to fix it, regardless of how much extra complexity they have to introduce. Result builders are a case in point. Essentially, they didn't like the bracket and the comma between array items in the special case where a function returns only a single array. // So rather than this let items = makeUgly { [ Item("One"), Item("Two"), Item("Three") ] } // It had to look like this let items = makePretty { Item("One") Item("Two") Item("Three") } Yes, it's prettier. There's a bit less clutter. But there's a cost too. makePretty uses entirely different language semantics without any syntactical clue at the call site. So now there are essentially two separate syntax modes in Swift, and every time you look at some code you have to make up your mind on whether to read it in normal mode or in result builder mode. Sometimes that's easy to know in context. But it's another thing you have to pay attention to at all times.
- bsaul 3y ago
  I feel swift really makes it impossible to learn as a language. The number of idioms has grown exponentially at the detriment of orthogonality. I think the red line was crossed with result builders indeed. Looks like a manager once said "we've got to look like jsx/html, now !" and the poor devs had to obey. It makes absolutely no sense from a language design POV.
pjmlp 3y ago
Apple never said anything about "world domination" outside their ecosystem. I guess you never looked into Kubernetes and their blobs of generated code to work around Go's weaknesses.
- frou_dh 3y ago
  It was Chris Lattner that used the phrase "world domination" and would even clarify that although it sounded like a joke, he was fairly serious about it.
  - pjmlp 3y ago
    His influence on Swift's stewardship ended the day he decided to leave Apple.
    - bsaul 3y ago
      i think the day he left was also the day swift lost its focus.
      - pjmlp 3y ago
        Swift focus is quite clear, replace C, C++ and Objective-C on Apple ecosystem, it is even stated on its official documentation. As such it should provide comparable level of flexibility, tooling and developer power. Anything else isn't part of swift focus.
- bsaul 3y ago
  Indeed i haven't ( although i've heard about it). However i have yet to see any swift codebase of comparable complexity. So, the jury is still out on which language enable the largest scale.

by bsaul 3y ago

jb1991 3y ago

> protocol extension + generics + class + structs you are referring to basic languauge features... you consider classes and structs pain points? these are the basic building blocks of the language, if you find them painful this is definitely not the language for you.

bsaul 3y ago
protocol extension adds another axis of design, with all its new gotcha ( pat , overrides, etc) It looks great on paper and do enable beautiful designs in some cases. But after tasting languages like go you realize you can get away with struct & functions in 99% of the cases, and that having less design options is actually a plus. It lets you focus on what really matters : domain modeling.
- jb1991 3y ago
  It's a lot more than "looks great on paper." My suspicion is that you have not really used and benefited from these features in a non-trivial way or you'd understand why they are there.

KerrAvon 3y ago

It doesn’t sound like you actually understand Swift or the Mac platform you claim it’s tied to. (a) Foundation is portable and available on Windows and Linux. (b) You are confusing language features and OS features. Async/await is part of the language. GCD is part of the OS. (c) Banning modern concurrency primitives is not viable forever — you’ll be left behind as the native APIs adopt them.

bsaul 3y ago
a : https://github.com/apple/swift-corelibs-foundation/blob/main/Docs/Status.md https://github.com/apple/swift-corelibs-foundation/blob/main... I wouldn't want to be the guy relying on this table advancement for his own project. The fact that they're rewriting it in pure swift probably says a lot about the quality of the current approach. b: makes absolutely no difference from a developer perspective. if you want to run threads in swift you're going to use gcd. c: my take with all apple software tech has been to wait until they've dogfooded their own tech long enough to make it useable. Worked very well for me so far, thank you very much.

slavapestov 3y ago

> Another issue would be a coherent concurrency system. Today we have a mix of gcd and actor system, declarative task, async await, etc which when put together makes me totally unable to understand what's going on in a real world program, unless you're doing like i do in my team : i specifically ban all modern concurrency apis in favor of the old ones. There’s a layering: - gcd is the lowest level - async/await lets you write tasks with suspension points (they wait for events to happen); but an async function is still conceptually executed serially - the Task API let’s you spin up async functions into various arrangements of parallel tasks and wait for those tasks to complete - ‘async let’ is sugar for creating a Task to compute a single expression - for async functions and Tasks to share data there is a Sendable model and various static isolation checks - actors build on everything else; actors are classes whose state is completely isolated to the actor, and all method calls are posted on the actor’s executor Memory-safe concurrency is hard. There’s a lot of ground to cover to replace the kind of things people do with shared state concurrency, and just actors alone are not enough. > Compare that to go, where there's (at most) one satisfying way to design the problem in the typesystem. As a sideeffect people have to think more about the problem they're trying to solve, and how to simplify it to the maximum. I like the aesthetics of small languages too, but I think Go picked the wrong small subset. It reminds me of Java in the 1.x days, for x <= 4, where the language had fundamental expressiveness constraints that created a huge amount of unavoidable boilerplate and type unsafety in even the most basic programming situations.

bsaul 3y ago
"... reminds me of java" i was having doubts before go introduced generics. But the fact that they managed to add it so perfectly while maintaining the unambiguous focus on simplicity and structs made me confident they've really nailed it. The only feature i don't get why they haven't added yet is proper enum to get some kind of ADT. It looks super orthogonal to the language and quite convenient. However at this point i fully trust their taste. If they think it's going to lead to catastrophic design decisions, i fully believe them.
- pjmlp 3y ago
  Go generics are far from perfect, and while they finally sort out a major paint point, they still leave some room for improvements.

fauigerzigerk 3y ago

It seems to me that their threshold for introducing new language features is extremely low. If something cannot be made to look flawlessly pretty using existing syntax they will go to any length to fix it, regardless of how much extra complexity they have to introduce. Result builders are a case in point. Essentially, they didn't like the bracket and the comma between array items in the special case where a function returns only a single array. // So rather than this let items = makeUgly { [ Item("One"), Item("Two"), Item("Three") ] } // It had to look like this let items = makePretty { Item("One") Item("Two") Item("Three") } Yes, it's prettier. There's a bit less clutter. But there's a cost too. makePretty uses entirely different language semantics without any syntactical clue at the call site. So now there are essentially two separate syntax modes in Swift, and every time you look at some code you have to make up your mind on whether to read it in normal mode or in result builder mode. Sometimes that's easy to know in context. But it's another thing you have to pay attention to at all times.

bsaul 3y ago
I feel swift really makes it impossible to learn as a language. The number of idioms has grown exponentially at the detriment of orthogonality. I think the red line was crossed with result builders indeed. Looks like a manager once said "we've got to look like jsx/html, now !" and the poor devs had to obey. It makes absolutely no sense from a language design POV.

pjmlp 3y ago

Apple never said anything about "world domination" outside their ecosystem. I guess you never looked into Kubernetes and their blobs of generated code to work around Go's weaknesses.

frou_dh 3y ago
It was Chris Lattner that used the phrase "world domination" and would even clarify that although it sounded like a joke, he was fairly serious about it.
- pjmlp 3y ago
  His influence on Swift's stewardship ended the day he decided to leave Apple.
  - bsaul 3y ago
    i think the day he left was also the day swift lost its focus.
    - pjmlp 3y ago
      Swift focus is quite clear, replace C, C++ and Objective-C on Apple ecosystem, it is even stated on its official documentation. As such it should provide comparable level of flexibility, tooling and developer power. Anything else isn't part of swift focus.
bsaul 3y ago
Indeed i haven't ( although i've heard about it). However i have yet to see any swift codebase of comparable complexity. So, the jury is still out on which language enable the largest scale.