Hacker News Reader

One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully.

The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.

Swift is amazing, Xcode is crap, and I've been using Xcode and its NeXT version for almost 20 years. I work in Xcode every day and every day I want to hurl it. Apparently Apple either doesn't care or is too overwhelmed with building 4 OSs every year. To be effective for building server side apps we need a new dev environment.

I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable.

Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a project.

I love going back to Ruby dev because VS Code is just such a joy to work in compared with Xcode. Xcode really struggles on my top of the line MBP with 16GB RAM.

I still love the language compared to ObjC but the tooling is abysmal. Every year we hold out hope that Xcode will magically get better but its the iTunes of IDEs at this point.

Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references.

You can always use AppCode if you don't like Xcode.

AppCode has also become increasingly buggy over the last year or so, and is now almost as unusable as Xcode (albeit in different ways).

On my computer, recent versions of AppCode constantly use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.

I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.

There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).

It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.

This is my point - I use multiple storyboards to break up the app and use storyboard references where appropriate. But loading up individual storyboards, waiting for them to render (which takes far longer now with @IBDesignable), etc is such a drain in productivity.

> You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive.

In which language does optimal performance come for free without really studying it? You have to pay attention to your case and context and use features accordingly, no matter what language you're using..

> It automatically manages memory

I have to stop you there. You shouldn't compare anything to C/C++ or Rust after that. You are better off comparing Swift with Go(i.e. both have automatic memory management, nice syntax, static typing, dynamic feeling etc) or Java(automatic memory management, well established in the enterprise world). If Apple was to design a language to respond to Go or Java it would be Swift and that's it. So the pitch is that you have a nice language which encourages productivity and you can share the knowledge/code between server and client.

Well, technically Swift's memory management is the same as what C++ offers via smart pointers, the only difference is that in C++ it is opt-in (and still very popular). Swift is quite unlike Go or Java's memory management; it is not a GC in the sense that they use it.

Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it.

I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).

You don't need in/out params to get references; in Swift, anything defined with "class" is always passed by reference.

Unmanaged references. Regular old class references aren't unmanaged (they adjust reference counts).

Swift does have a runtime though. In its current form I can't see it replacing C or C++. It may provide more deterministic performance than Go but it's not C. If it were to be designed as C replacement I would expect a roadmap for embedded environments, praise about its mapping to the hardware, how it trashes or at least matches C/C++ on its application domain(i.e. low level/ hardware interface or performance) etc but it's clear that is not the case and its focus is on "apps" first, servers second and maybe a bit of low level.

> but without a stop-the-world garbage collector a

RC is a stop-the-world garbage collector when the reference count reaches 0 in very complex data structures, which trigger a cascade of deletions.

Also it has issues with sharing data between threads leading to cache coherency contention and locks.

Fair enough. The point I was (trying) to make is that Swift doesn't have a traditional GC like Java, or Javascript, etc.

That's not stop the world. Under RC, when a thread is destroying a complex data structure, other threads are free to keep doing useful work.

RC does otherwise have very bad interactions with threads of course.

edit: clarify

Just like a parallel GC.

parallel != stop-the-world