[HN Gopher] Swift Regrets
___________________________________________________________________
Swift Regrets
Author : tempodox
Score : 117 points
Date : 2021-09-21 11:03 UTC (1 days ago)
(HTM) web link (belkadan.com)
(TXT) w3m dump (belkadan.com)
| [deleted]
| msoad wrote:
| Swift has way too many shorthand syntaxes. It feels nice from a
| language design perspective but when teaching Swift, you can see
| how confusing it is for the students. In larger codebases a lot
| of shorthands are forbidden by the organizations for consistency.
| So I'm not sure who's the real beneficiary for all those
| shorthands?
| kyralis wrote:
| Very much this. The original discussions around Swift talked
| about the value of being explicit rather than implicit and
| reducing surface area (for instance, no ++/--
| increment/decrement operators). That goal appears to have been
| completely lost recently.
| bsaul wrote:
| My impression following swift forums is that original core
| team members were very concerned about relying a lot on first
| principles, whereas the new generation is more about building
| powerful constructs, in a fast paced way.
| bsaul wrote:
| i think there's a growing concern about the language
| complexity. I hope next releases are going to be about trimming
| down the language, and consolidating the not-so-sexy but very
| important other aspects (multiplatform, compilation speed, spm,
| tooling, etc) following golang's example.
| [deleted]
| SV_BubbleTime wrote:
| > So I'm not sure who's the real beneficiary for all those
| shorthands?
|
| Coffee shop and college project app developers who are chasing
| the cool (be it tricks or frameworks).
|
| That's not a knock, but that's who I see using these things.
|
| We were hiring a guy for a Flutter app that had no previous
| experience in Dart, but turned us down because Dart lacked some
| whiz bang feature he had too grown accustomed to. I did not see
| this as a loss.
| diskzero wrote:
| The shorthands mystify me as well. I have taught a few courses
| using Swift and the shorthand notation, as well as implicit
| variables like oldValue and newValue in setters, are confusing.
| You can try to ignore them, but eventually a student will find
| them.
|
| In my experience, teaching courses using Racket have had better
| outcomes. At the end of the Racket courses, I can quickly
| transition students to other languages, including Swift. It
| hasn't worked out so well with Swift. I am still gathering data
| so I can come to a better conclusion as to why.
| throwdecro wrote:
| > Swift has way too man shorthand syntaxes. It feels nice from
| a language design perspective but when teaching Swift, you can
| see how confusing it is for the students.
|
| 100% agree. As a late adopter of Swift, I spent a lot of time
| looking at code that was so stingy with information that it was
| challenging to even formulate a Google-able question from it.
| dekhn wrote:
| I remember when the creator of Swift joined google and there was
| a lot of noise about Swift and Tensorflow. i told people while it
| seemed like a nice idea, it was never going to replace
| Python/C++. Eventually Lattner lost interest and the project
| died.
| protomyth wrote:
| I guess I was in the minority who loved Objective-C and it's
| selector syntax. I think my main objection to Swift is that it
| seems to be written by people who hate Objective-C and made the
| calling syntax much more complicated. I dearly wish a more mature
| F-Script had been the next Apple language.
|
| A lot of the other problems is Apple not providing good
| documentation and making sure sample programs continue to
| compile. Bringing a new language into the world requires massive
| amounts of high quality documentation.
| joeberon wrote:
| I don't understand why Apple's developer documentation is so
| terrible
| apple4ever wrote:
| I was there with you too. Objective-C may have been verbose,
| but it was readable and easily modifiable.
|
| It definitely seemed like the people who wrote Swift hated
| Objective-C. The "let", "func", etc syntax is ugly and
| unnecessary, along with the question marks.
|
| I know I'm swimming against the tide, but I'll be writing
| Objective-C for as long as I can.
| zionic wrote:
| > I think my main objection to Swift is that it seems to be
| written by people who hate Objective-C
|
| I mean that's the vast majority of people
|
| >and made the calling syntax much more complicated.
|
| How is this true? Swift is very straightforward, and similar to
| other languages
|
| Meanwhile Objective-C is slow, unsafe by default, with super
| ugly syntax only a mother could love. More than half of Apple's
| CVE/iOS vulnerabilities lately have been from parts of the OS
| that still use ObjC, the sooner they get rid of that garbage
| the better.
| Apocryphon wrote:
| > I mean that's the vast majority of people
|
| Maybe...
|
| https://news.ycombinator.com/item?id=15421073
|
| It's an old article by now, but check out the responders-
| Marco Arment, Steve Troughton-Smith, Marcel Weiher- pretty
| eminent iOS devs among them.
| rsfinn wrote:
| Yes, that article is nearly four years old. Since then,
| Swift has evolved considerably.
|
| Steve Troughton-Smith has tweeted recently about his work
| in converting all of his apps to Swift over the last year
| [1]. "I will remember ObjC and the times we had together
| fondly, but after a year of being Swift-only I prefer
| making apps with it" [2]. "I also wouldn't change the
| timeline in which I adopted Swift ... I don't feel I lost
| out on anything positive by waiting" [3].
|
| [1] https://twitter.com/stroughtonsmith/status/143923417616
| 36638... [2] https://twitter.com/stroughtonsmith/status/142
| 16157982091100... [3] https://twitter.com/stroughtonsmith/s
| tatus/14216193780265820...
|
| Marco Arment has talked about using Swift in new
| development for Overcast, although I don't believe he's
| rewriting existing code. He seems more open to Swift these
| days than when that article was written. (Can't find a
| quotable source at present)
|
| Marcel Weiher has continued working on a language now
| called Objective-S, which sounds like the "more
| Smalltalk-y" language that other commenters have wished
| for: "Objective-S includes an Objective-C compatible
| runtime model, but using a much simpler and consistent
| Smalltalk-based syntax." [4]
|
| [4] http://objective.st/About
| mpweiher wrote:
| > > and made the calling syntax much more complicated.
|
| > How is this true? Swift is very straightforward, and
| similar to other languages
|
| Swift is objectively one of the most complex languages out
| there[1]. Just recently, they adopted basically the entirety
| of Smalltalk syntax as an edge case of an edge case[2].
|
| Just the rules for initialisers are more complex than many
| languages and still don't cover all the cases[3].
|
| > Meanwhile Objective-C is slow,
|
| The only people who believe this are those who have never
| measured (and have uncritically accepted Apple propaganda on
| this topic)[4]. Objective-C is a language you can easily
| write very fast code in (languages by themselves aren't fast
| or slow)[5]. Objective-C code is almost invariably faster
| than Swift code, and often by quite a lot.[6]
|
| > unsafe by default,
|
| Also not true. The id subset is quite safe[7] (and pretty
| fast), as are primitives. The parts that make C dangerous,
| particularly strings and other raw pointer accesses are
| abstracted away behind safe NSString, NSArray, NSData and
| friends.
|
| > ugly syntax
|
| Keyword syntax is actually highly elegant (Smalltalk's fits
| on a postcard) and extremely functional. So functional that
| Swift just recently added pretty much all of it as an edge
| case of an edge case of its closure syntax. Oh, did I already
| mention that?
|
| > More than half of Apple's CVE/iOS vulnerabilities lately
| have been from parts of the OS that still use ObjC
|
| Citation needed. Also: way more than half of the OS is still
| written in Objective-C, so you'd expect that.
|
| [1] https://www.quora.com/Which-features-overcomplicate-
| Swift-Wh...
|
| [2] https://blog.metaobject.com/2020/06/the-curious-case-of-
| swif...
|
| [3] https://blog.metaobject.com/2020/04/swift-initialization-
| swi...
|
| [4] https://blog.metaobject.com/2014/09/no-virginia-swift-is-
| not...
|
| [5] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl
| ?ie...
|
| [6] https://blog.metaobject.com/2020/04/faster-json-support-
| for-...
|
| [7] https://blog.metaobject.com/2014/05/the-spidy-subset-or-
| avoi...
| saagarjha wrote:
| > Meanwhile Objective-C is slow, unsafe by default, with
| super ugly syntax only a mother could love. More than half of
| Apple's CVE/iOS vulnerabilities lately have been from parts
| of the OS that still use ObjC,
|
| Objective-C is quite fast-in many cases faster than Swift-and
| as (memory) safe as Swift for the most part. Most of Apple's
| CVEs come from code written in C or C++, not Objective-C.
| iainmerrick wrote:
| Right! If it's so slow, how did the original iPhone work so
| slickly, when all the apps and most of the frameworks were
| written in Objective-C?
| Someone wrote:
| For the same reason python is fast for machine learning:
| because the performant parts were written in C.
|
| Ignoring slick animations (which were written in C, if
| not in hand-tuned assembly) typical UIs of apps on the
| original iPhone could have run (a bit slowly and in
| monochrome) on an original Mac, that is in 128kB RAM on a
| 8MHz CPU.
| ajconway wrote:
| Animations were slick (compared to other mobile
| platforms) because they were hardware accelerated.
| mpweiher wrote:
| > because the performant parts were written in C
|
| Objective-C _is_ C. More specifically a strict superset
| of C.
|
| > Ignoring slick animations (which were written in C, if
| not in hand-tuned assembly)
|
| Nope. The reason the animations were smooth (not
| necessarily fast) is that they were processed by the GPU
| and orchestrated by a separate process.
| Aaargh20318 wrote:
| The original iPhone was very slick mainly because
| everything else on the market at that time was so
| terrible.
| ace2358 wrote:
| Because the original iPhone was so stripped down that it
| could run on that thinly little slow cpu. It took Apple
| years and years to add features back into iOS frameworks.
| Every one very considered and every attempt to not
| destroy the battery of the iPhone. Multi tasking only
| around in iOS 4 right? Like on iPhoneOS 1 every app was
| closed when you hit that home button. That it worked so
| smoothly was the result of extremely focused UX.
| zionic wrote:
| I think you're forgetting how barebones iOS1 was. I had
| to jailbreak to get MMS and copy-paste.
| ajconway wrote:
| If you look at the original review videos (or even the
| keynote), you may notice that the first iPhone lags quite
| a bit. Of course, it's not Objective-C that causes it,
| but rather the limited hardware of the time.
| zionic wrote:
| This shouldn't be true, ObjC's only innate advantage is
| compile time, because the compiler is simply doing less and
| is capable of producing far worse (unsafe) code.
|
| At runtime Swift can utilize static dispatch, where
| objective C is mostly dynamic. Good swift code should
| generally be faster.
| mpweiher wrote:
| > This shouldn't be true
|
| Performance isn't about what you believe should be true,
| but about what actually is true. Kinda like science.
| (versus religion)
|
| > ObjC's only innate advantage is compile time
|
| Objective-C has a bunch of advantages. Compile time isn't
| really one of them, except when compared to Swift, which
| is ridiculously slow to compile.
|
| And there are languages with very comparable feature sets
| to Swift that are way faster to compile.
|
| > At runtime Swift can utilize static dispatch
|
| "can"
|
| > where objective C is mostly dynamic.
|
| Not true. The C part of Objective-C (it is most of the
| actual language) is very static.
|
| Also, Swift has some pretty amazing dynamic performance
| pitfalls. For example protocols. You see, protocols in
| Swift can be adopted by both structs and classes. Meaning
| that when you call a function via a protocol, the
| compiler doesn't even know the size of the arguments or
| how to access them or copy them into the function's
| scope. So even that has to be handled by a small vtable,
| and you haven't actually done anything with that argument
| yet!
|
| As this is one of the many places where Swift can lose a
| cool few orders of magnitude of performance, you
| obviously need the optimiser to specialise the function
| for specific callers. Which it can do, sometimes, at some
| cost, as long as it can actually see the caller and
| callee at the same time, in the same compilation unit.
|
| IIRC, Uber had an OOPSLA paper describing the extra
| compiler pass they had to write to get their app's
| performance to at least somewhat acceptable levels,
| because the existing optimiser wasn't good enough.
|
| And when you want to do separate compilation, you're sort
| of hosed, because you don't have access to the caller
| when you compile the callee.
|
| > Good swift code should generally be faster.
|
| That turns out not to be the case.
| protomyth wrote:
| _How is this true? Swift is very straightforward, and similar
| to other languages_
|
| That's the argument, most people want to program in
| JavaScript or C++, learning is such a bother. The Swift
| syntax is more characters than ObjC's syntax.
| zozbot234 wrote:
| C++ is of course a _vastly_ more complex language than
| Swift. I don 't think anyone would _want_ to code in C++
| these days if they can avoid it.
| germandiago wrote:
| I want. I do it. It gives me a level of control and a
| number of libs that no other language can give me,
| including all the C libs available as well.
|
| Yes, it is not pretty sometimes, but if you take a look
| at well-written C++ code you would be very surprised at
| how clean it can look. With its quirks from time to time,
| but very clean:
|
| - mark virtual overrides with override
|
| - use move semantics to increase performance
|
| - take advantage of RVO
|
| - write GUIs, CLIs, or servers
|
| - use lambdas and ranges
|
| - use smart pointers to get rid of most memory management
|
| - tune your server to allocate and deallocate in the
| desired patterns via polymorphic allocators or just plain
| allocators
|
| - take advantage of SIMD and parallelism (via parallel
| algorithms library, among many examples)
|
| - create generic infrastructure in algorithms with zero
| overhead penalty that is not even possible in other
| languages
|
| - keep things working for the next 2 or 3 decades without
| touching the code
|
| - Program in HPC environments
|
| C++ is _much better_ than what most people that do not
| use it all the time think. It is not as bad as they put
| it, and, more important, it is very high performance. I
| admit this is one of the big reasons why people use it,
| but C++ for application programming does not look to me
| like crazy either.
| lpapez wrote:
| If besides best possible performance you also value
| ergonomics, security, maturity and tooling then IMO
| nothing comes close to C++, especially C++17 and later.
| Not that there is much choice really, only C and Rust can
| realistically get you comparable performance, each with
| their own problems.
| gumby wrote:
| Actually plenty of people do want to and do so.
| jlarcombe wrote:
| ...and of course it was simple to interoperate with
| Objective-C in C++, in a way that it isn't for Swift,
| sadly
| mpweiher wrote:
| a) I wouldn't be so sure that C++ is actually more
| complex at all, never mind _vastly_. It may be less
| forgiving... :-)
|
| b) With C++, you're at least getting something for all
| that complexity: performance and control.
| jshier wrote:
| > The Swift syntax is more characters than ObjC's syntax.
| How so?
| protomyth wrote:
| well, no - Swift's call syntax actually results in the
| same or more characters:
| somePoint.moveBy(x: 2.0, y: 3.0) [somePoint
| moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0,
| y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0
| z: 4.0];
| jbluepolarbear wrote:
| No it's not. If you have multiple parameters Obj-C is much
| longer and ugly.
| iainmerrick wrote:
| Where are you getting this from?
|
| Swift's mandatory named parameters _come from_
| Objective-C. For the most part only the bracket placement
| is different.
| zionic wrote:
| Mandatory names parameters?
|
| You have been able to provide anonymous arguments since I
| first started playing with Swift in 2.0. The function
| just has to define it that way.
| jbluepolarbear wrote:
| Swift supports default and objc doesn't. This makes calls
| smaller. Swift also has argument hiding with the
| underscore before the parameter. Swift also ask variable
| arguments. Hiding named parameters and variable arguments
| make calls much smaller. My point stands.
| Apocryphon wrote:
| That's not really "much" longer. And in some cases the
| brevity saved could really increase obfuscation and
| confusion.
| jbluepolarbear wrote:
| Yes it is; especially, if there's long parameter names.
| And I disagree with the obfuscation and confusion, but
| that's a discussion on Swifts goal of self documentation
| not code length.
| adamnemecek wrote:
| I think that apple hated that at the end of the day, a lot of
| the system frameworks had to be written in objective-c++ which
| is not great.
| pjmlp wrote:
| NeXT had another point of view on that matter though, the
| original DriverKit was Objective-C.
|
| Objective-C++ main point of existence, just like POSIX, was
| only to bring other software into the platform.
|
| It is quite telling that only old timers have access to
| Objective-C++ docs.
| spijdar wrote:
| Are you and GP talking about the same thing?
|
| The obj-c drivers from next/OpenStep were replaced with a
| restricted subset of C++ (not objective-C++) IOKit system.
| I'm not sure what system GP is referring to based off
| Obj-C++ but I assume it's not the drivers?
| adamnemecek wrote:
| E.g. AVFoundation.
| pjmlp wrote:
| Not really, I am talking about NeXTSTEP and DriverKit.
|
| Ironically I think IO Kit userspace replacement,
| DriverKit, got its name as homage to the Objective-C one
| in NeXTSTEP.
| ChrisMarshallNY wrote:
| _> Bringing a new language into the world requires massive
| amounts of high quality documentation._
|
| Very much agree. Not just a new language. Any complex endeavor
| requires this. I have written a server-based framework,
| including spending a great deal of time developing API
| documentation, and was relatively recently introduced to
| Postman. I have been using Postman to communicate the API to
| another engineer that is not RTFM (I've come to learn that
| folks don't like reading stuff, these days. I am looking at
| ways of communicating information in formats other than
| longform text).
|
| I like Postman. The main issue with using it as a documentation
| source, is that it can easily become "cluttered"; especially as
| I use it in "back-and-forths," over particular commands.
|
| I would have been lost, in my Swift education, without
| StackOverflow, although I hardly ever consult it anymore
| (mostly because it's rapidly becoming less useful; not because
| I don't need the help).
|
| SwiftUI has some of the worst documentation I've ever
| encountered. Obviously, it was headerdoc-style, and no one was
| writing header docs, so I was constantly encountering empty
| pages. It was so bad, a generous individual developed this site
| and companion app[0]. I understand that the SwiftUI
| documentation is being rapidly improved. I haven't really
| started into a big learning drive on SwiftUI, yet, so I hope it
| is in better shape, by the time I get to it.
|
| [0] https://swiftui-lab.com
| pianoben wrote:
| I'm with you.
|
| Despite the verbosity of the NS/Cocoa/etc APIs, Objective-C is
| a small, flexible, and unambiguous language. It performs very
| well at runtime, and is amazingly quick to compile. With
| version 2.0 and ARC, it became _productive_ in addition to
| everything else.
|
| I get it, it was long in the tooth, and the C legacy was both a
| blessing and a heavy weight holding the language back, but we
| lost a lot of the simplicity in the move to Swift.
| sharp11 wrote:
| Unlike many commenters here, I came to praise Swift. Of course
| there will be regrets -- nothing's perfect -- but on the whole I
| think the designers (and community) did an amazing job with
| Swift. I say that after having written multiple apps in Objective
| C -- I would never consider going back.
|
| Optionals and null safety, first class enums, first class
| functions are just lovely in swift, all in a language that is
| super readable when well-written.
| BuyMyBitcoins wrote:
| I don't know if this is Swift's fault, _per se_ but I find Xcode
| to be a real pain to use. There's something about the Apple Way
| for UI /UX that just doesn't jive well with an IDE experience. I
| find myself constantly jockeying around the various windows and
| panes within Xcode that I usually never have to bother with
| inside of Visual Studio.
| kennywinker wrote:
| There is swift language tooling for vscode, if you're so
| inclined.
| kitsunesoba wrote:
| Probably depends a good deal on what you're used to. By far,
| the IDE I've spent most time in through my career is Xcode (or
| its predecessor Project Builder) and have found it's not too
| bad once you've got a grip on the things it doesn't "like".
|
| In fact I enjoy working in it more than I do the much-vaunted
| Jetbrains IDEs, even when configured to use Xcode key shortcuts
| (thus short-circuiting the familiarity problem a bit). The
| faster autocomplete is nice, but a lot of the "smarter" parts
| end up getting in my way or doing the wrong thing more
| frequently than they are helpful. I can't really compare with
| Visual Studio since I've never really seriously developed for
| Microsoft platforms.
|
| I will say though that Xcode got noticeably worse after
| Interface Builder got merged into it, and I think much of its
| woes stem from that merger even today. IB should've been left a
| separate tool, which is particularly evident now that XIBs and
| Storyboards are yielding to SwiftUI in the nearish future.
| drclau wrote:
| If you develop for iOS|macOS professionally, you may be
| interested in Jetbrains' AppCode [0].
|
| Note: I'm not connected in any way to Jetbrains, and I have not
| used AppCode myself, but I used other tools from them, and
| they're quite competent, I'd say.
|
| [0]: https://www.jetbrains.com/objc/
| w0mbat wrote:
| Apple professionals use Xcode. Using different tools than the
| ones Apple uses leads to a lot of problems that Apple are not
| interested in fixing. The days when a company like Metrowerks
| or Symantec could be a viable third party IDE supplier are
| long gone.
| tathisit wrote:
| Not an apple user, but I've heard that xcode is an ide+build
| system. Which means that you can't compile an application if
| you don't have the exact version of xcode installed. How true
| is that?
| sedatk wrote:
| They're part of Xcode package but they can also be installed
| separately IIRC.
| gwking wrote:
| Xcode's faults preceded Swift by many years.
| novok wrote:
| I'm surprised he doesn't bring up minor features that lead to
| huge compile time issues, like operator overloading and imports
| being module sized vs file or folder wide and type inference in
| some cases. Not to mention how the language doesn't actually
| scale that well with core count vs. many, many other programming
| languages. Throwing 64 cores / 128 threads at a C++ code base
| speeds up builds in a linear fashion during the compile step, in
| swift it does not and it tends to effectively max out at around 8
| to 16-ish build threads. Even with 3 view toy apps made with
| SwiftUI on a M1 macbook is slow to build & run relative to it's
| size!
|
| Honestly you would have gotten %80-%90 of the benefits of swift
| by making Obj-C use a new syntax that looked like swift and
| continued to improve Obj-C as a language than what you would have
| gotten with swift. A lot of the ugly of obj-c could have been
| translated away with very simple 1:1 syntactic sugar macros. And
| you would actually have fast, responsive compile and indexing
| times, unlike swift.
| jshier wrote:
| The main point of Swift was to create a memory-safe language
| Apple could use across its OSes. Trying to change Obj-C's
| syntax doesn't help with that goal.
| zozbot234 wrote:
| Swift does not provide memory safety for concurrent code. It
| has comparable pitfalls to Go. (You can use Thread Sanitizer
| to try and diagnose these issues, but that's best-effort and
| runtime-only; it does not make your code totally safe.)
| dddddddan wrote:
| It does now with actor based concurrency
| jarpadat wrote:
| Concurrent memory safety is definitely a goal. Try the new
| '-warn-concurrency' flag to see what I mean, it is
| comparable to rust and quite different than thread
| sanitizer. There's also a new runtime sanitizer this year
| with swift intrinsics, not best effort like tsan was.
|
| That said. Swift is in the tough position of trying to be a
| lot of things at once to users with competing needs.
| Applications, systems, performance, education, prototyping,
| etc. While there's broad agreement concurrency safety is
| important, not everybody thinks it is important enough to
| bury your working build under a thousand errors (though
| that view is represented)
|
| Ultimately swift's philosophy is that safety is practice
| and not theory. _Some_ people do turn on '-warn-
| concurrency' and fix their errors, others would want to
| ignore them and find some escape hatch to squash them which
| doesn't appreciably improve safety, still others might not
| upgrade if that was required and maybe the ecosystem as a
| whole becomes less safe for it. Swift feels responsible for
| these kinds of outcomes.
|
| It's a tough problem but it does lead to interesting ideas
| that make safety more practical and productive. Remains to
| be seen how much of both worlds you can have, but
| swift/clang/llvm have a long history of doing stuff like
| that better than you expect.
| azakai wrote:
| That is true, but the great majority of memory safety
| issues are not concurrent ones. In practice Swift and Go
| are huge improvements over C, C++, and Objective-C in terms
| of memory safety.
|
| I'd also say they are in a reasonable space in the state of
| the art of safety in general. While they do not make
| concurrency safe and Rust does, in Rust you need to use
| unsafe to write things like doubly-linked lists and graphs
| (or resort to things like indexes-in-an-array), which you
| can do safely in Swift and Go. So there are interesting
| tradeoffs all around - our industry has not found a perfect
| solution here yet.
| novok wrote:
| If I had Go's build speed in Swift, I wouldn't have
| minded a clean break language like Swift.
| saagarjha wrote:
| In my experience post-ARC almost all memory safety issues
| are thread-safety related.
| novok wrote:
| What do you mean specifically about memory safety? A clean
| break new-syntax Objective C could have dropped the C part of
| ObjC, added strict nullability, dropped header files, add non
| ABI breaking features like enum ADTs and a bunch of other
| tweaks and still kept most of the same language compiler code
| without all the downsides of swift. Swift became a silver
| bullet homer car as far as languages go.
| azakai wrote:
| That would not have helped with use-after-free, though,
| which Swift does solve.
| saagarjha wrote:
| That's solved by ARC, not Swift.
| azakai wrote:
| Oh right, good point. Other types of memory safety are
| more relevant here then.
| tialaramex wrote:
| C++ pays an _extraordinary_ price for the fully parallel
| builds, concealed in the "One Definition Rule".
|
| The price is, if you violate the ODR the standard says your
| program is not valid C++ (and thus has no defined meaning)
| _but_ there is no requirement for a diagnostic (ie a compile or
| link error) and the build might complete.
|
| This has sometimes been described as "False positives for the
| question is this a program?" and is a pretty serious penalty to
| pay for the benefit of improved compile time.
| germandiago wrote:
| Modules mitigate in a big measure ODR violations. It will be
| quite more difficult. Compile times will also be better, at
| least incremental ones.
| novok wrote:
| Could you have ODR and proper warnings / errors handling the
| issue when it pops up without much penalty?
| slavapestov wrote:
| > Honestly you would have gotten %80-%90 of the benefits of
| swift by making Obj-C use a new syntax that looked like swift
| and continued to improve Obj-C as a language than what you
| would have gotten with swift. A lot of the ugly of obj-c could
| have been translated away with very simple 1:1 syntactic sugar
| macros.
|
| This is a common talking point I hear in the Objective-C
| community, but nobody has come up with a credible design or
| implementation of "incrementally evolve Objective-C and drop
| the C part" beyond stating that it's trivial, etc.
| Apocryphon wrote:
| Hypothetical designs are bandied about _all the time_
|
| https://medium.com/@mattmass/the-alternative-reality-of-
| obje...
|
| https://twitter.com/tolmasky/status/1401972686037913601
|
| https://mjtsai.com/blog/2014/10/14/hypothetical-
| objective-c-...
|
| https://web.archive.org/web/20141224114850/https://swiftopin.
| ..
| slavapestov wrote:
| "Hypothetical" being the key word here, though. These
| proposals are all thin on details, and if it was so easy
| someone would've made such a language by now.
| rapsey wrote:
| Before Swift/Kotlin our iOS team was way more productive than
| android. Everything was done in half the time.
|
| They both switched to new languages.
|
| Now it has flipped. Android does things in half the time the
| other team needs.
| dhritzkiv wrote:
| I've found similar results, although at the end of the day, iOS
| development is still faster overall.
|
| Kotlin does a better job of getting out of the way when you
| need it to (compared to Swift), and Jetpack Compose is the real
| game-changer in terms of productivity.
|
| That being said, there's a lot that you 'get for free' in iOS'
| frameworks, and APIs are generally more interoperable /
| batteries included. Both of these factors are what ultimately
| speed up iOS development.
| kitsunesoba wrote:
| I haven't had a chance to use Jetpack Compose yet but this
| roughly tracks with my experience. Needing to hunt down
| third-party libs for everything slows development down
| considerably and makes for complications down the road when
| those libraries inevitably stop being supported.
| dhritzkiv wrote:
| Totally.
|
| To add to this: when looking for third party libraries
| (Swift/Objective-C or Kotlin/Android Java), aside from
| those from large organizations (Square, Airbnb, etc.), I've
| found the selection and quality of those available for iOS
| to be better, on average.
| iainmerrick wrote:
| I think it helps that C and C++ just work on iOS, so you
| can easily use or wrap existing code in those languages.
|
| Unless things have changed a lot recently, C/C++ sort-of-
| works on Android but it's a pain to use and the tooling
| support is very weak.
| gavinray wrote:
| There's a tool called "scapix" that's popped up recently
| that fixes this and is really impressive.
|
| It's zero-boilerplate (IE, don't need to manually write
| bindings like most tools) bindings from C++ code for both
| Swift/ObjC and Java. The idea being you can write C++
| code and then consume it on both mobile platforms, making
| your life easier.
| https://github.com/scapix-com/scapix
|
| It also is really useful if you want to use Java from
| C++. Manual JNI invocation and type translation is awful,
| this just smoothes over all of it.
| https://github.com/scapix-com/scapix#java-link
|
| Good usecase being when you want to extend a Java app
| with some native capabilities.
|
| I've had a scenario where another app handed me the
| pointer to a window to render to, and so the only way to
| use it from JVM was to write some bridge code. Where C++
| started the JVM & invoked my Java app's entrypoint,
| sending over the window pointer, and then from there I
| could render/paint into the window.
| kitsunesoba wrote:
| Strong agree here. This is also tied into the "batteries
| included" approach of Apple platforms, because many if
| not the majority of Swift/Obj-C libraries are mainly
| wrappers around system frameworks that either bring them
| to a higher level (in the case of C or C++ APIs) or add a
| sprinkle of syntactic sugar and light-to-moderate gap
| filling functionality. So naturally, these libraries are
| easier to maintain in the long term simply because
| they're doing so much less.
| zionic wrote:
| That's just your team then. Swift is far superior to
| Objective-C(rap) in terms of both speed and overall
| productivity.
| jorgemf wrote:
| Don't forget kotlin. It is a really game changer.
| jshier wrote:
| Yeah, this sounds like a tooling issue. I have no
| difficultly believing Kotlin + Android Studio might be
| faster or more reliable than Swift + Xcode. Hard to say
| with any certainty though, it could be any number of
| things, if the perceived difference is even real.
| rapsey wrote:
| From my outside looking in perspective:
|
| * Android studio is reliable and just works.
|
| * Kotlin is simple, easy to learn and productive.
|
| * xcode is buggy and with their rapid pace of development
| it is just getting worse.
|
| * Swift is complex. They had to rethink and redesign
| multiple times. Also the language was constantly changing
| under them.
| jshier wrote:
| Swift hasn't changed much in the last 2.5 years, and was
| stable for the year before that, so it really shouldn't
| be an issue any more.
| jorgemf wrote:
| Yes, but kotlin has been much more stable for more years.
| kennywinker wrote:
| I find it hard to believe that anybody is faster coding in objc
| than swift, if you control for garbage code. It was easy to
| quickly write buggy messes in objc - swift made that a lot
| harder, and is also a much more ergonomic and productive
| language in my experience. I feel like there has to be some
| other factors at play if that's the results you're seeing.
| (Source: I've been doing objc since 2009, and swift since
| version 1.0)
| ardit33 wrote:
| A well jelled team, with senior engineers can be much more
| productive with Objective C.
|
| But for beginners, swift looks less intimidating due to its
| syntax familiarity. The language pitfalls become apparent as
| you dive into it.
|
| Perhaps that's why swift in ML and other areas failed. People
| don't like the language. In iOS you are forced to use it.
|
| I hope the swift team does some hard thinking and start
| slashing features and make it Simpler. What we got is
| something more complex than even Java. This is the same
| reason that Scala didn't take off (even though some people
| like it).
| jshier wrote:
| This just isn't true. Given equal familiarity, Swift will
| be vastly more productive at any skill level. Of course you
| can always tunnel deeper into more sophisticated solutions
| using Swift, since Obj-C lacks most of its capabilities,
| but that's hardly an equal comparison.
| ardit33 wrote:
| You are talking out of your arse... and so am I.
|
| Unless we have well researched data, it is just a
| opinion.
|
| My opinion and experience is definitely different than
| yours, and I have seen that objective c leads to more
| productive teams if they are mostly senior people. (With
| a couple of libraries (just some helper categories on
| strings and arrays) and some sparse macros objective c
| becomes a very productive language. But it takes a senior
| team to do that well).
|
| Meanwhile with swift you feel you have to please the
| compiler at every! step? And it really doesn't lead to
| much safer language anyway (swift bugs are different) and
| you feel you have to fight the compiler in every way.
|
| Objective c is less fuzzy, and while it lets you do
| dumb/fast things (especially important during
| prototyping) it gives you a clear 'you are doing x wrong'
| warning which gives you the best of both worlds
|
| Fast prototyping when you need it, and safety when you
| need to ship (you can have a production build fail on
| just warnings)
| novok wrote:
| Nullability isn't that big of an issue in practice. Every
| call in objective-c is equivalent to a variable?.thing
| call anyway, and in swift codebases most things become
| non-null fairly quick. It's probably the top feature of
| swift for me, which is ironic because it's relatively
| cheap (in compile time) to implement compared to many
| other things swift has.
|
| And if you're doing nullability, you might as well add
| ADT enums, since that is usually how it's implemented.
| jshier wrote:
| These are the same stupid points people brought up when
| Swift was first released. I used to believe it too. Then
| I actually used the language and integrated it into
| existing codebases. The jump in quality and performance
| was notable and immediate. What you state here about both
| languages doesn't match any experience I've ever had or
| seen from other teams.
| diskzero wrote:
| I have a rather complex application that is a mix of C++,
| ObjC and Swift. I humbly consider myself an expert in all
| three languages and worked on AppKit while employed at
| Apple. Perhaps Swift is slightly more accessible when you
| begin development. If you aren't familiar with ObjC
| syntax, Swift my look more familiar at first, but syntax
| quickly becomes familiar.
|
| When you mention more sophisticated solutions using
| Swift, I am not sure what capabilities Obj-C lacks that
| would hamper it. Are you referring to the functional
| parts of the Swift language? Combine?
| novok wrote:
| I have a lot of experience in both languages, and TBH
| it's just not true. I'm less productive in swift in many
| ways, mostly because of it's slow build and indexing
| times. It's infuriating.
|
| You are still coding against the same UIKit and other
| apple libraries in both. SwiftUI has a chance to make it
| better, but it's incomplete and has bugs/gotchas that
| make it not as productive as UIKit when you run into
| that, which is pretty easy. But in an imaginary world
| where we got ObjectiveSwift instead, SwiftUI could have
| existed there and given the same productivity benefits.
|
| Binary sizes ballooned because of the language. Binaries
| were significantly smaller in equivalent Obj-C programs
| than the swift ones, even when the standard swift library
| was finally baked into the OS.
| jshier wrote:
| It would be impossible to evolve Obj-C to add most of
| Swift's capabilities unless you drop binary and source
| back compatibility. At that point it's just another new
| language and you've lost the things you say made Obj-C
| simpler.
|
| I have a hard time believing any engineer is productivity
| bound by Swift's build times and especially indexing
| times, since indexing doesn't affect your ability
| actually write code. Typically developer productivity is
| bound by thinking of an appropriate solution to a problem
| and expressing that solution in a language. Given how
| much easier that expression is in Swift, especially if
| you spend a bit of time optimizing the language to your
| problem, the build time becomes rather incidental. Add to
| that Swift's ability to catch far more issues at build
| time and its language features and the Obj-C solution
| falls further and further behind. Even if your Obj-C
| solution builds faster it will likely be an inferior
| solution anyway.
| iainmerrick wrote:
| _indexing doesn 't affect your ability actually write
| code_
|
| What! Of course it does. If it doesn't impact coding at
| all, what is it for?
| novok wrote:
| I see you haven't worked in a swift code base that is
| more than a few engineers. Work in a project that is
| 20-80+ engineers and you slam into these issues very
| quickly. Last time I checked the inflection point starts
| around 100k lines of code.
|
| Also 'thinking' of solutions often involves writing
| something and then trying it out in a build-edit-run
| cycle, and then integrating your thing into a larger app
| context, which also involves many build-edit-run cycles.
| Most people do not think of their solution in whole cloth
| in their head other than in a broad strokes manner and
| then start writing code. This means indexing and building
| matters greatly for actual productivity.
|
| Indexing issues means your ide is not auto completing,
| click to definition doesn't work, and in the past, even
| syntax highlighting failed. Also when you have some half
| formed code, a lot of indexing functions start breaking
| in an annoying way, while I don't really recall this
| behavior in Objective-C code bases.
|
| In practice I've found swift being 'able to catch issues
| more' is mostly strict nullability, better array /
| dictionary strictness and enums, which would actually be
| relatively simple to implement in an extended
| ObjectiveSwift. Strict generics would be more work, but
| you can add it to the language also as a version update.
| Dart showed how it's possible to add big changes like
| strict nullability to a language with their dart v1 -> v2
| update. Objective-C could have gone down that path
| instead.
| wlesieutre wrote:
| They're not saying developing in Swift is faster than OjbC,
| they're saying Java for Android was slower than ObjC for iOS,
| and now Kotlin for Android is faster than Swift for iOS.
|
| Both teams move faster in the new languages, but the Android
| team moves _more faster_.
| occamrazor wrote:
| I think GP is saying that ObjC is faster than Java for
| development, but Kotlin is faster than Swift. No comparison
| between ObjC and Swift.
| w0mbat wrote:
| I code several times faster in ObjC than Swift, and this is
| after writing two released Swift apps. Just a simple thing
| like writing string to num to string that works in different
| bases is a nightmare in Swift.
| bsaul wrote:
| the swift string / substring api is still incredibly
| convoluted (or poorly documented, or both), but my feeling
| is that it's because it does a _lot_.
| iainmerrick wrote:
| I prefer Swift on balance, but there's still a lot I miss
| from Obj-C.
|
| For one thing, Obj-C compiles much faster. Swift compilation
| is ludicrously slow.
| bsaul wrote:
| Recently had to update an old objc ios codebase, and the
| first time i built i thought something went wrong, because
| it completed way too fast.
|
| Swift compilation is an order of magnitude too slow,
| especially in incremental built, compared to objc.
| Apocryphon wrote:
| Debugging with LLDB often feels broken or incomplete in
| Swift than with Objective-C, as well.
| wodenokoto wrote:
| This introduction post to the series of swift regrets is placed
| somewhere in the middle of all the posts.
|
| If you want to read these, it might be easier to start here:
| https://belkadan.com/blog/tags/swift-regrets/
___________________________________________________________________
(page generated 2021-09-22 23:01 UTC)