6 ms·

I don't care about the random TIOBE fluctuations. But I really don't get the love for Swift. - Optional is a nuisance and I don't think it is highly effective

I don't care about the random TIOBE fluctuations. But I really don't get the love for Swift. - Optional is a nuisance and I don't think it is highly effective at preventing the dereference of a nil pointer in practice. People are going to fiddle with ? and ! until their code works, and the protection that Optional provides then disappears. - "let" is a mess. In one context it means unwrapping an Optional. In another, it doesn't. If you use it in an expression, it interferes with the usual refactorings that people apply to expressions. - There is so much fussy detail around preserving the syntax of object.field = expression. didSet, willSet, getters, setters, oldValue, newValue. WHY IS THIS SYNTAX SO FRIGGIN' IMPORTANT? One of the justified criticisms of C++ (IMHO) is that operator overloading means that all sorts of functions can be running under innocent-looking code. I would much rather have = mean assignment, and use function call notation when I really want functions to run. - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy). It sure beats Objective-C, and it does have some nice modern features, but I think they made some unfortunate design choices.

sonnyblarney 8y ago
I don't think there is a 'love' so much as it's the future of iOS platform. Swift is just too much, too many things, and yes, they kind of dorked optionals. To me it's just trying to hard.
- christoph 8y ago
  I'm glad I'm not the only one who feels this way. I used to absolutely love writing Objective C, like totally get into a zone and lose track of time. I've never managed to achieve that same feeling with Swift.
  - fooker 8y ago
    This is what most people seem to totally miss. You want to solve interesting problems. You do not want interesting tools getting in the way. A boring, old, flawed tool would often work better for solving the problem without interruptions.
    - AsyncAwait 8y ago
      > This is what most people seem to totally miss. No, they don't 'miss' it. I think what you're missing is that is perfectly possible to 'get' optionals and be as, if not more, productive than in ObjC. Not all people get the Swift model and for them it may be unintuitive, but many do get it. I find it distressing that some developers just want to bang out code as fast as possible and any tool that tries to impose a bit of good software engineering in between that is seen as 'evil'. I've seen similar sentiments expressed about Rust i.e. 'I'd rather take my memory leaks and data races over the borrow checker'. That's fine, but please be aware that I'll try my best to not let you execute any code on my machine if that's how you approach the craft.
rimliu 8y ago
From your comment looks like you do not get Swift anf that prevents from getting why it is loved. There is no need to "fiddle" with ? and ! Optionals are not that complex. And there is nothing wrong with let. It has nothing to do with optionals.
- geophile 8y ago
  "if let x = someOptional" unwraps the optional, no? And "let x = someOptional" doesn't, right? So the first form does have something to do with Optionals, and it is true that the two forms of let behave differently with respect to them. (I have moved on from Swift, so if things have changed since Swift 3.x and 4.something, my apologies.)
  - _hardwaregeek 8y ago
    I agree that's confusing coming from an imperative context. The core misunderstanding here is that `let` is a binding, not a variable declaration. It's binding a name to a value, not creating a variable which can be modified. Therefore the `if let` example is saying "if we can bind the value inside the optional to a name", while the regular let example is just saying "bind the optional to x"
    - geophile 8y ago
      I get all that, but in one case the type of the value bound to the declared identifier is T, and in the other case it is T?. To me, that violates The Law of Least Astonishment, but that is admittedly subjective.
  - zapzupnz 8y ago
    Actually, in `if let x = someOptional`, you should rather see it like this: `if (let x = someOptional)`. If that second part were a function, it would be `() -> Optional<T>`. That is to say, the if statement is satisfied if the "result" of the "function" (if you follow me; clearly I don't mean it's actually a function in the implementation) returns .some(T) (not nil) rather than .none (nil). That we can do an assignment with `let` is just syntactic sugar for: if someValue != nil { let x = someValue! } Basically, we want to know if the value is non-nil. There are instances where the result can be nil, and if so, nothing gets assigned. For example: protocol Fruit { } protocol SeededFruit: Fruit { } protocol SeedlessFruit: Fruit { } struct Mandarin: SeedlessFruit { } let mandarin = Mandarin() if let someFruit = mandarin as? SeededFruit { } Okay, so the compiler will actually disallow this, but you get the basic idea: `mandarin` is not a SeededFruit, the cast will always be false, therefore someFruit will be nil, therefore the "result" of the "function" will be nil, which is counted as false. The thing is, this isn't specific to the `let` keyword, either. You could just as easily define a new variable with the `var` command. So `let` and `var` don't mean different things in different contexts and never have. Swift just allows them to be used as syntactic sugar in if statements.
tommymachine 8y ago
Lots of misunderstanding of how optionals are designed to work in this comment!
- hu3 8y ago
  Is it only the developers fault when critical parts of a programming language are hard to grasp? I suspect that might be a sympton of excessive complexity and parent's example of C++ seems spot on.
  - mamcx 8y ago
    But optional is very simple concept. However, break from the old habits is hard. I was there moving to f# and the first month or so I try to bend the rules. Same now with rust. I try to mold it as a OO language, and get SUPER annoyed with how rust is so different. But you embrace algebraic types and pattern matching and suddenly a lot of other hidden problem simple disappear forever.
    - kitsunesoba 8y ago
      Proper optional use is indeed a habitual thing. When I was first transitioning from ObjC to Swift I found them to be an annoyance, but after using Swift for the past few years I find myself wondering how my ObjC code ever ran as well as it did without them. I’m now reluctant to use languages that lack option types.
- eyerishcoffee 8y ago
  Whether there is misunderstanding by the grandparent post or not, in practice there are a lot of people who do just play with ?/! until they manage to get code to compile and then hope for the best. You can see it all over the place in code people write, posts on Stack Overflow, etc. The Apple Swift book does a poor job explaining the rationale and benefit of using option types.
  - christoph 8y ago
    Genuine question - does this not highlight a problem with the language on some level?
plainOldText 8y ago
I actually like Swift: advanced type system and compiler, clean syntax, very fast. I think optionals are a great way of saying: “Hey developer, this value can sometimes be nil; be sloppy or not, your call.” Any language you pick is an interplay of choices and compromises. No such thing as perfect.
- mpweiher 8y ago
  > very fast This is a common sentiment, but it rarely holds up to closer scrutiny (such as measurements...). Swift is both slow to run and very slow to compile. Both compile and runtime come with extremely high variance. Such unpredictability is arguably even worse than just plain slow performance.
  - notafrog 8y ago
    Up until Swift 4, compilation took longer than with Objective-C according to my experience. Not sure how much Swift 5 has changed things.
  - plainOldText 8y ago
    In most of these benchmarks [1] Swift's performance comes pretty close to that of Rust. So yeah, I would call that very fast. [1] https://web.archive.org/web/20190402100249/https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/swift-rust.html https://web.archive.org/web/20190402100249/https://benchmark...
    - raphlinus 8y ago
      Try some JSON benchmarks with Codables in Swift vs serde in Rust. Rust smokes Swift, something like 20x. Incidentally I've spent considerable effort on this problem, including writing a prototype faster JSON parser in Swift (still about 3x slower than Rust, but a huge speedup over what's there). I couldn't get anyone in the Swift community to care enough to motivate me to finish the work, which is indicative of a deeper problem: Swift just doesn't have "performance culture," the benchmark game results notwithstanding.
    - 7y ago
mamcx 8y ago
- Optional is a nuisance.. People are going to fiddle with ? and ! And that is GOOD. This mean that wrong code look wrong: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... and many instances of it mean something is badly wrong in the codebase, and the developer(s) haven't adapted to how must be done. In contrast: bad.shit.happends Good look with that... - "let" is a mess Overloading keywords have problems, but in this case the rules are simple. And is not that many context to worry about. - I would much rather have = mean assignment Agree. Overloading keywords are fishy, but operators are in another league! Have some sense for maths but in other contexts is not worth the extra "feature". - Reference counting is a bad compromise You mean, ARC. Is not exactly the same, and the compromise is totally worth. I work with .NET for iOS/android and man, is heavy. All is about what is default. With GC, by default, eat memory and unpredictable destructors. With (A)rc only need to worry about break cycles. That not happened often enough to be a real problem BTW, I have use obj-c, pascal, .net, python, rust. The ARC model is the best for most kind of code most do. I honestly have more unpredictable and unfixable problems with GC (mostly on android with underpowered devices), so I prefer to get something less automatic..
- ken 8y ago
  > [Using Optional] mean that wrong code look wrong ...as long as you don’t use any implicitly unwrapped optionals (which virtually all Mac/iOS code does), or use any frameworks that predate Swift (like AppLit/UIKit/Foundation), or wrap any C libraries (most third-party libraries in the world). So basically that’s true for the 5-line samples showing how cool Optional is, and no real program I’ve ever written. It was a nice experiment but in practice I have more issues stemming from Optional than I ever did with nil. > In contrast: bad.shit.happends Do you not read any Swift forums? There are newbies posting every single day asking why "a.b.c" crashed in Swift.
  - mamcx 8y ago
    > There are newbies posting every single day asking why "a.b.c" crashed in Swift. That is fair. And totally show why optionals are the right thing. Because obj-c and others NOT have it the world suck MUCH more. That is why nulls are the billon dollar MISTAKE with capital letters. The solution is to more and more languages, libraries and frameworks embrace the idea of algebraic types, not just declare "interfacing with old codebases with this huge MISTAKE is not nice, so why bother??". What rust make nice is declare stuff as UNSAFE. I wish this was the case with swift and obj-c so make clear to everyone that you have entered the realm of nasty things and must be more careful...
ppeetteerr 8y ago
I can share my love of Swift - Optional has made null pointer exceptions virtually non-existent. There are occasions where deserialization does result in a nil value where one is not expected, but that's rare. I think this is as massive as garbage collection was back in the day. - The language is in a sweet spot between something convoluted and heavy like Java and something overly simplistic like PHP/Ruby/Python. It's perfect for software development and large code-bases with a low learning curve. - There is no magic (methods, properties, etc). Everything is explicit but not wordy. This may change in the future but I hope it never does. - It's more legible than Kotlin with fewer unnecessary language features. Speaking of which... - It's a simple language and its syntax is straight forward It's not a perfect language: - The package manager needs a lot of work - Extensions can lead to confusion (eg. in the case of conformance to protocols (interfaces)). - I would like an optional garbage collection system for long-running processes (e.g. server-side applications) - I would like it to perform even better You can nitpick syntax anomalies with any language, but a language is defined by how easy it is to scale to multiple programmers, how applicable it is to a problem, how well it performs, how easy it is to read for someone new to the system, how it helps the programmer not commit mistakes, etc. Of all the languages I've written, none has been as successful in all regards as Swift.
- ken 8y ago
  > It's a simple language and its syntax is straight forward Wha? It has about 100 reserved words — more than C++, now, I think. Even its own designer said [1]: “You’re unlikely to run into anybody that says that Swift is a simple language. Swift is a complicated language.” If you consider Swift simple, what language do you consider complex? Of all the languages I've written, none has been as complex as Swift. [1]: http://atp.fm/205-chris-lattner-interview-transcript http://atp.fm/205-chris-lattner-interview-transcript
  - ppeetteerr 7y ago
    Yes, it's simple from a user's perspective. Even the quote in your comment is then followed by Chris talking about how easy it is to learn Swift (e.g. `print("Hello world!")` is a valid program). There are a lot of keywords in Swift, but that is not what makes a language complicated. They are all in English, after all. Symbols and unique concepts are what complicate a language because they are not explicit or unorthodox. For instance, using `:=` or `(setq x (1+ 2))` for assignment instead of `=`.
netheril96 8y ago
> I would much rather have = mean assignment, and use function call notation when I really want functions to run. And then you end up with Java where you have to write so many boilerplates for getters and setters, even if they are only plain attribute access, just in case you want a function later.
- geophile 8y ago
  I agree that a very common Java pattern is to create getters/setters for every private field. Which is just stupid, might as well have the members be public. To use the popular phrase, Java classes like that have a "bad code smell". It tells me that the author of the class doesn't really understand how it should be used. I think a well-designed class will have private members and public member function interfaces that don't resemble each other very much.
cletus 8y ago
> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy). This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy. You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language. This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck. But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC. Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point? Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.
- throwaway34241 8y ago
  IDK about Java, but the GC characteristics of Go seem pretty ideal for UI code. I think they're at sub-1ms pauses on multi-GB heaps now. So even if you want to run at 100 fps it shouldn't be a big obstacle to making frame rate. Of course there's a throughput trade off, but same thing with reference counting. Although I guess it doesn't matter much since the library ecosystem isn't there. I think it would have been an interesting choice for Flutter instead of Dart though. For just memory management, I don't see the downside of GC (vs reference counting) if the latency is good enough. Sure you can still leak memory by maintaining references but at least it deals with cycles (and it's one less thing that any dependencies can screw up). If GC latency is OK, the only remaining advantage of reference counting I can think of is the deterministic destruction of non-memory resources like file handles etc.
bsaul 8y ago
I wonder if you have real experience with swift or you’ve just been looking at the language from a distance, because i disagree with pretty much every point you made. Optional is the best thing that could happen to a language that allows nil values ( the only other option being not allowing them at all, but that’s not common). If let ( and guard let) is an elegant idiom for unwrapping optionals safely, but that’s about the only cass you’re going to see a let in something that looks like an expression. The only complain you could have in that part in the language is between let and var, but that’s actually quite useful in practice for self documenting code. Operator overloading could become dangerous, but it seems that it is used very sparingly in the swift ecosystem. Standard library doesn’t overuse it, so people don’t as well. Reference counting to me has quite the same drawback as GC : it makes you forget about memory cycles and ownership. But apart from rust who tried something very different ( and is scaring a lot of developers), once again i don’t see a lot of other options.
- geophile 8y ago
  I do have some experience, playing with an iOS app for several months, through various versions of the language (3.x, 4.x). But this was as a hobby. I liked Optionals when I learned about them, and less as I started using them. I found that libraries sometimes changed return types, e.g. T to T? (or vice versa). The feature struck me as having some drawbacks similar to Java checked exceptions: the rigor required ran counter to clean and easy to understand code. Did I just not get the design of the feature? Perhaps, but I did find it very difficult to avoid tweaking code with ? and !. I have no problem with var vs. let. I like that distinction. And I do understand that let is used only sparingly in expressions. But that's what bugs me about it, it is so limited. It is not an "orthogonal" feature, (usable in any expression). An expression is ideally functional (no side effects). Let definitely does have a side effect, declaring and binding an identifier. I find it awkward to mix the two ideas. This may be many years of mental baggage, from C, C++, and Java, but it is there, and I think that the introduction of such a major side-effect into the world of expressions is a genuinely bad idea. GC vs. reference counting: GC really does allow you to forget about memory management. Until you start running into problems requiring GC tuning. But then, the fixes tend to leave the code alone completely. With reference counting, tuning requires more intrusion into code. Yes, this is subjective. Just explaining my reasoning.

sonnyblarney 8y ago

I don't think there is a 'love' so much as it's the future of iOS platform. Swift is just too much, too many things, and yes, they kind of dorked optionals. To me it's just trying to hard.

christoph 8y ago
I'm glad I'm not the only one who feels this way. I used to absolutely love writing Objective C, like totally get into a zone and lose track of time. I've never managed to achieve that same feeling with Swift.
- fooker 8y ago
  This is what most people seem to totally miss. You want to solve interesting problems. You do not want interesting tools getting in the way. A boring, old, flawed tool would often work better for solving the problem without interruptions.
  - AsyncAwait 8y ago
    > This is what most people seem to totally miss. No, they don't 'miss' it. I think what you're missing is that is perfectly possible to 'get' optionals and be as, if not more, productive than in ObjC. Not all people get the Swift model and for them it may be unintuitive, but many do get it. I find it distressing that some developers just want to bang out code as fast as possible and any tool that tries to impose a bit of good software engineering in between that is seen as 'evil'. I've seen similar sentiments expressed about Rust i.e. 'I'd rather take my memory leaks and data races over the borrow checker'. That's fine, but please be aware that I'll try my best to not let you execute any code on my machine if that's how you approach the craft.

rimliu 8y ago

From your comment looks like you do not get Swift anf that prevents from getting why it is loved. There is no need to "fiddle" with ? and ! Optionals are not that complex. And there is nothing wrong with let. It has nothing to do with optionals.

geophile 8y ago
"if let x = someOptional" unwraps the optional, no? And "let x = someOptional" doesn't, right? So the first form does have something to do with Optionals, and it is true that the two forms of let behave differently with respect to them. (I have moved on from Swift, so if things have changed since Swift 3.x and 4.something, my apologies.)
- _hardwaregeek 8y ago
  I agree that's confusing coming from an imperative context. The core misunderstanding here is that `let` is a binding, not a variable declaration. It's binding a name to a value, not creating a variable which can be modified. Therefore the `if let` example is saying "if we can bind the value inside the optional to a name", while the regular let example is just saying "bind the optional to x"
  - geophile 8y ago
    I get all that, but in one case the type of the value bound to the declared identifier is T, and in the other case it is T?. To me, that violates The Law of Least Astonishment, but that is admittedly subjective.
- zapzupnz 8y ago
  Actually, in `if let x = someOptional`, you should rather see it like this: `if (let x = someOptional)`. If that second part were a function, it would be `() -> Optional<T>`. That is to say, the if statement is satisfied if the "result" of the "function" (if you follow me; clearly I don't mean it's actually a function in the implementation) returns .some(T) (not nil) rather than .none (nil). That we can do an assignment with `let` is just syntactic sugar for: if someValue != nil { let x = someValue! } Basically, we want to know if the value is non-nil. There are instances where the result can be nil, and if so, nothing gets assigned. For example: protocol Fruit { } protocol SeededFruit: Fruit { } protocol SeedlessFruit: Fruit { } struct Mandarin: SeedlessFruit { } let mandarin = Mandarin() if let someFruit = mandarin as? SeededFruit { } Okay, so the compiler will actually disallow this, but you get the basic idea: `mandarin` is not a SeededFruit, the cast will always be false, therefore someFruit will be nil, therefore the "result" of the "function" will be nil, which is counted as false. The thing is, this isn't specific to the `let` keyword, either. You could just as easily define a new variable with the `var` command. So `let` and `var` don't mean different things in different contexts and never have. Swift just allows them to be used as syntactic sugar in if statements.

tommymachine 8y ago

Lots of misunderstanding of how optionals are designed to work in this comment!

hu3 8y ago
Is it only the developers fault when critical parts of a programming language are hard to grasp? I suspect that might be a sympton of excessive complexity and parent's example of C++ seems spot on.
- mamcx 8y ago
  But optional is very simple concept. However, break from the old habits is hard. I was there moving to f# and the first month or so I try to bend the rules. Same now with rust. I try to mold it as a OO language, and get SUPER annoyed with how rust is so different. But you embrace algebraic types and pattern matching and suddenly a lot of other hidden problem simple disappear forever.
  - kitsunesoba 8y ago
    Proper optional use is indeed a habitual thing. When I was first transitioning from ObjC to Swift I found them to be an annoyance, but after using Swift for the past few years I find myself wondering how my ObjC code ever ran as well as it did without them. I’m now reluctant to use languages that lack option types.
eyerishcoffee 8y ago
Whether there is misunderstanding by the grandparent post or not, in practice there are a lot of people who do just play with ?/! until they manage to get code to compile and then hope for the best. You can see it all over the place in code people write, posts on Stack Overflow, etc. The Apple Swift book does a poor job explaining the rationale and benefit of using option types.
- christoph 8y ago
  Genuine question - does this not highlight a problem with the language on some level?

plainOldText 8y ago

I actually like Swift: advanced type system and compiler, clean syntax, very fast. I think optionals are a great way of saying: “Hey developer, this value can sometimes be nil; be sloppy or not, your call.” Any language you pick is an interplay of choices and compromises. No such thing as perfect.

mpweiher 8y ago
> very fast This is a common sentiment, but it rarely holds up to closer scrutiny (such as measurements...). Swift is both slow to run and very slow to compile. Both compile and runtime come with extremely high variance. Such unpredictability is arguably even worse than just plain slow performance.
- notafrog 8y ago
  Up until Swift 4, compilation took longer than with Objective-C according to my experience. Not sure how much Swift 5 has changed things.
- plainOldText 8y ago
  In most of these benchmarks [1] Swift's performance comes pretty close to that of Rust. So yeah, I would call that very fast. [1] https://web.archive.org/web/20190402100249/https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/swift-rust.html https://web.archive.org/web/20190402100249/https://benchmark...
  - raphlinus 8y ago
    Try some JSON benchmarks with Codables in Swift vs serde in Rust. Rust smokes Swift, something like 20x. Incidentally I've spent considerable effort on this problem, including writing a prototype faster JSON parser in Swift (still about 3x slower than Rust, but a huge speedup over what's there). I couldn't get anyone in the Swift community to care enough to motivate me to finish the work, which is indicative of a deeper problem: Swift just doesn't have "performance culture," the benchmark game results notwithstanding.
  - 7y ago

mamcx 8y ago

- Optional is a nuisance.. People are going to fiddle with ? and ! And that is GOOD. This mean that wrong code look wrong: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... and many instances of it mean something is badly wrong in the codebase, and the developer(s) haven't adapted to how must be done. In contrast: bad.shit.happends Good look with that... - "let" is a mess Overloading keywords have problems, but in this case the rules are simple. And is not that many context to worry about. - I would much rather have = mean assignment Agree. Overloading keywords are fishy, but operators are in another league! Have some sense for maths but in other contexts is not worth the extra "feature". - Reference counting is a bad compromise You mean, ARC. Is not exactly the same, and the compromise is totally worth. I work with .NET for iOS/android and man, is heavy. All is about what is default. With GC, by default, eat memory and unpredictable destructors. With (A)rc only need to worry about break cycles. That not happened often enough to be a real problem BTW, I have use obj-c, pascal, .net, python, rust. The ARC model is the best for most kind of code most do. I honestly have more unpredictable and unfixable problems with GC (mostly on android with underpowered devices), so I prefer to get something less automatic..

ken 8y ago
> [Using Optional] mean that wrong code look wrong ...as long as you don’t use any implicitly unwrapped optionals (which virtually all Mac/iOS code does), or use any frameworks that predate Swift (like AppLit/UIKit/Foundation), or wrap any C libraries (most third-party libraries in the world). So basically that’s true for the 5-line samples showing how cool Optional is, and no real program I’ve ever written. It was a nice experiment but in practice I have more issues stemming from Optional than I ever did with nil. > In contrast: bad.shit.happends Do you not read any Swift forums? There are newbies posting every single day asking why "a.b.c" crashed in Swift.
- mamcx 8y ago
  > There are newbies posting every single day asking why "a.b.c" crashed in Swift. That is fair. And totally show why optionals are the right thing. Because obj-c and others NOT have it the world suck MUCH more. That is why nulls are the billon dollar MISTAKE with capital letters. The solution is to more and more languages, libraries and frameworks embrace the idea of algebraic types, not just declare "interfacing with old codebases with this huge MISTAKE is not nice, so why bother??". What rust make nice is declare stuff as UNSAFE. I wish this was the case with swift and obj-c so make clear to everyone that you have entered the realm of nasty things and must be more careful...

ppeetteerr 8y ago

I can share my love of Swift - Optional has made null pointer exceptions virtually non-existent. There are occasions where deserialization does result in a nil value where one is not expected, but that's rare. I think this is as massive as garbage collection was back in the day. - The language is in a sweet spot between something convoluted and heavy like Java and something overly simplistic like PHP/Ruby/Python. It's perfect for software development and large code-bases with a low learning curve. - There is no magic (methods, properties, etc). Everything is explicit but not wordy. This may change in the future but I hope it never does. - It's more legible than Kotlin with fewer unnecessary language features. Speaking of which... - It's a simple language and its syntax is straight forward It's not a perfect language: - The package manager needs a lot of work - Extensions can lead to confusion (eg. in the case of conformance to protocols (interfaces)). - I would like an optional garbage collection system for long-running processes (e.g. server-side applications) - I would like it to perform even better You can nitpick syntax anomalies with any language, but a language is defined by how easy it is to scale to multiple programmers, how applicable it is to a problem, how well it performs, how easy it is to read for someone new to the system, how it helps the programmer not commit mistakes, etc. Of all the languages I've written, none has been as successful in all regards as Swift.

ken 8y ago
> It's a simple language and its syntax is straight forward Wha? It has about 100 reserved words — more than C++, now, I think. Even its own designer said [1]: “You’re unlikely to run into anybody that says that Swift is a simple language. Swift is a complicated language.” If you consider Swift simple, what language do you consider complex? Of all the languages I've written, none has been as complex as Swift. [1]: http://atp.fm/205-chris-lattner-interview-transcript http://atp.fm/205-chris-lattner-interview-transcript
- ppeetteerr 7y ago
  Yes, it's simple from a user's perspective. Even the quote in your comment is then followed by Chris talking about how easy it is to learn Swift (e.g. `print("Hello world!")` is a valid program). There are a lot of keywords in Swift, but that is not what makes a language complicated. They are all in English, after all. Symbols and unique concepts are what complicate a language because they are not explicit or unorthodox. For instance, using `:=` or `(setq x (1+ 2))` for assignment instead of `=`.

netheril96 8y ago

> I would much rather have = mean assignment, and use function call notation when I really want functions to run. And then you end up with Java where you have to write so many boilerplates for getters and setters, even if they are only plain attribute access, just in case you want a function later.

geophile 8y ago
I agree that a very common Java pattern is to create getters/setters for every private field. Which is just stupid, might as well have the members be public. To use the popular phrase, Java classes like that have a "bad code smell". It tells me that the author of the class doesn't really understand how it should be used. I think a well-designed class will have private members and public member function interfaces that don't resemble each other very much.

cletus 8y ago

> - Reference counting is a bad compromise between the unpredictability of GC, and the burden of explicit memory management. It's mostly unobtrusive, but I've seen examples of code that require careful and non-obvious use of weak to avoid memory leaks, (sorry, I don't have the reference handy). This is such a bizarre statement to me. I have to wonder if the commenter has ever dealt with production systems or code that uses GC? Because with years of writing and tuning Java servers, I've long since come to the conclusion that GC is largely a false economy. You still have to deal with memory leaks but the cause this time is objects maintaining references they don't need. Sure GCs become cleverer at detecting unused forests of objects and so on but this largely makes another problem worse: so-called stop-the-world pauses for a full GC. It's still an issue you have to deal with on Java, Go and probably every GC language. This isn't to say that ref-counting is a panacea (what is?). Particularly on servers the critical region for updating the ref-count itself can become hot and a bottleneck. But this isn't really a problem on mobile app code. I've long said that iOS's uses of ref-counting (ARC since 5.0+) is a strategic and competitive advantage to Android's Dalvik/Java GC. Google's Plan9 2.0 (ie Fuchsia) makes me sad (for many reasons). Just one is that they've embraced Dart/Flutter at the application level (which isn't required as anyone who works on it will tell you, yada yada yada) but Dart is such a strange choice because it still relies on GC. What's the point? Oh and just to be pedantic, you list ref-counting as a negative of Swift compared to Objective-C. ARC is orthogonal to that. Like I said, ARC came about in iOS 5.0.

throwaway34241 8y ago
IDK about Java, but the GC characteristics of Go seem pretty ideal for UI code. I think they're at sub-1ms pauses on multi-GB heaps now. So even if you want to run at 100 fps it shouldn't be a big obstacle to making frame rate. Of course there's a throughput trade off, but same thing with reference counting. Although I guess it doesn't matter much since the library ecosystem isn't there. I think it would have been an interesting choice for Flutter instead of Dart though. For just memory management, I don't see the downside of GC (vs reference counting) if the latency is good enough. Sure you can still leak memory by maintaining references but at least it deals with cycles (and it's one less thing that any dependencies can screw up). If GC latency is OK, the only remaining advantage of reference counting I can think of is the deterministic destruction of non-memory resources like file handles etc.

bsaul 8y ago

I wonder if you have real experience with swift or you’ve just been looking at the language from a distance, because i disagree with pretty much every point you made. Optional is the best thing that could happen to a language that allows nil values ( the only other option being not allowing them at all, but that’s not common). If let ( and guard let) is an elegant idiom for unwrapping optionals safely, but that’s about the only cass you’re going to see a let in something that looks like an expression. The only complain you could have in that part in the language is between let and var, but that’s actually quite useful in practice for self documenting code. Operator overloading could become dangerous, but it seems that it is used very sparingly in the swift ecosystem. Standard library doesn’t overuse it, so people don’t as well. Reference counting to me has quite the same drawback as GC : it makes you forget about memory cycles and ownership. But apart from rust who tried something very different ( and is scaring a lot of developers), once again i don’t see a lot of other options.

geophile 8y ago
I do have some experience, playing with an iOS app for several months, through various versions of the language (3.x, 4.x). But this was as a hobby. I liked Optionals when I learned about them, and less as I started using them. I found that libraries sometimes changed return types, e.g. T to T? (or vice versa). The feature struck me as having some drawbacks similar to Java checked exceptions: the rigor required ran counter to clean and easy to understand code. Did I just not get the design of the feature? Perhaps, but I did find it very difficult to avoid tweaking code with ? and !. I have no problem with var vs. let. I like that distinction. And I do understand that let is used only sparingly in expressions. But that's what bugs me about it, it is so limited. It is not an "orthogonal" feature, (usable in any expression). An expression is ideally functional (no side effects). Let definitely does have a side effect, declaring and binding an identifier. I find it awkward to mix the two ideas. This may be many years of mental baggage, from C, C++, and Java, but it is there, and I think that the introduction of such a major side-effect into the world of expressions is a genuinely bad idea. GC vs. reference counting: GC really does allow you to forget about memory management. Until you start running into problems requiring GC tuning. But then, the fixes tend to leave the code alone completely. With reference counting, tuning requires more intrusion into code. Yes, this is subjective. Just explaining my reasoning.