[yvsong]

Swift: better OO, syntax, IDE; Go: built-in concurrency;

Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

[ajmurmann]

I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration.

Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifications to get updated sometimes takes tens of second which can be very confusing.

[jksmith]

Yeah agree. While I've moved on, IMHO xcode was generally crap compared to dev envs I used back in the friggin 90's, like Delphi or Topspeed. Not many on HN know much about Delphi, but it set the gold standard for the desktop IDE.

Great thing about Go is you don't need much of an IDE because it's best to just keep Go in its sweet spot, which is services. LiteIDE works great for Go- small footprint,debugging, enough project management to get by. Just like with everything else about Go, you can get a newbie dev going with the Go toolchain actually producing something that works in hardly any time.

[gurkendoktor]

To add some anecdata, I know three people (myself included) who moved from "playing with Delphi 5 as a student" into iOS dev. And I still feel that ObjC in Xcode is (sadly) the best replacement for Delphi right now:

- A stable and pragmatic language that interfaces well with the C world.

- Nice separation of class interface/implementation; ARC is as easy as COM was in Delphi; solid reflection/metaprogramming capabilities (e.g. enumerating properties).

- Compilation is fast enough on my 5y/o laptop.

- A standard library that is so good that people never re-invent it.

- The debugger works really well and is always-on (IntelliJ still has separate "Run" and "Debug" buttons, facepalm).

- IBDesignable/IBInspectable makes writing your own components as nice as it was in Delphi: http://nshipster.com/ibinspectable-ibdesignable/

The points above will probably fall apart with Swift, but right now it's not actually too bad.

[untog]

Agreed. I don't use the GUI tools much (I prefer to manually construct stuff, I know, I know...) and XCode has been just awful to work with. Random crashes, freezing while debugging... in the most recent version I can't view log outputs of a process I attach to, and if I try to take a screenshot from the iOS Simulator it immediately crashes.

[audunw]

I'm not sure it should be Apples job to build a best-in-class text editor. I haven't used XCode in a long while, but last time I did it worked pretty well with external text editors, and you could configure the UI in a way that really facilitated using it just for just compiling/debugging.

Every single IDE I've used, I've always used another text editor for doing actual programming. It's nice to have a half-decent text editor in the IDE for debugging (see value of variables in the code, looking up and quickly fixing compile errors, etc).. but I don't expect it to be as powerful as vim, emacs, sublime, et.al.

[ajmurmann]

Have you used any of the JetBrains IDEs?

[steedsofwar]

Coming from an IntelliJ background, one thing that irks me the most when using XCode is: i need to click on the red dot symbol to see the error. For the love of God, just display the error, why do i need to move my hand away from the keyboard to the mouse. It just annoys me enough to lose my coding mojo.

[bsaul]

Everything you saîd about swift is correct for small sized projects. The story becomes much much different once you work on a piece of code for a few months with a team. Then xcode crashes, swift builds slowly ( in minutes), you start to be crippled because of the compiler and tool.

I hate to say it, but It's not production ready yet, at least not for a big project.

[zomgbbq]

I hear this argument a lot that it's not production ready but my personal experience does not agree. I use Swift in production for several apps with relatively large codebases that sustain many hundreds of thousands of sessions per day. I would agree that a full clean/rebuild is not as fast as Objective-C and that the incremental build system sometimes seem as though it is compiling more files than you'd like. However, for most part the incremental build system is fine and in daily use it is not a problem. I could never imagine going back to writing objective-C again when I compare the net gains we've realized coding in Swift. The readability and succinctness of the language, as well as catching bugs at compile-time rather than run-time, is a huge benefit. Value-based programming, functional(-ish) programming, and protocol extensions have made my code so much easier to maintain and test, as well.

[mahyarm]

How many lines of code does your project use? How complicated is your module structure? Is everything in one huge target or do you split your app into 100s of modules? What do you use for dependency management, what is your deployment target? Are things running in one process like an iOS app or is it some sort of OS X project?

Pretty much every large swift project I've seen has had the problems described. Lyft, Uber, Linked In, etc.

[zomgbbq]

I'm going to answer but I should preface by saying I'm not going to try to proselytize you to Swift. If it doesn't work for you and you're happy with Objective-C, then by all means do what makes you happy and keeps you productive. I have a couple of apps that have about 50k lines of Swift, one also with 60k lines of Objective-C and another with 40k lines of Objective-C. We use MVVM as well as a fairly involved mechanism of VM abstraction with intercommunication using RAC. Common code is in a cocoapod as well as other third-party dependencies otherwise the other target is the iOS app itself. I think LOC is a poor metric to measure complexity, but it does have a relevance to compile time. Others have also said that Swift and Xcode are not perfect, but as an engineer programming in Swift makes me quite happy.

[mahyarm]

Aha! You haven't hit the LOC barrier that starts to make swift & xcode/source kit act like bsaul described. At around 100kloc you will start to get that experience with swift. While an equivalent 100-200kloc line app written in objective c will work quite fine with xcode. You'll start noticing some degradation as you get to 60-70kloc. You also have a simple module structure, which makes things better.

You can see it happen pretty plainly with a simple codegen script creating a bunch of dummy code up to X lines of code.

[G4BB3R]

Then, it's not Swift that is not production ready, but XCode that is crap :)

[rimantas]

You worked with source of both, Uber and Lyft? And Linkdin too?

[mahyarm]

They do presentations about swift and have twitter employee accounts where they complain about swift :)

[nodamage]

I like Swift but incremental builds are very much broken on Xcode 8 and have been for a while: https://forums.developer.apple.com/thread/62737

This leads to very long compile times for even simple one line changes.

[jordansmithnz]

I also use Swift for large projects (many modules, lines of code, complex generics etc). Yes, Swift and Xcode are far from perfect. But the fluent language, and the tools that Xcode provides far outweigh any stability issues I've run into, especially recently.

There's some tools you can use to diagnose build times, often slow builds are just a line or two that seem to mess with the compiler and can easily be broken apart or written in a different way.

Also, have you tried the Android emulator/Android studio? Last time I did it made me appreciate Xcode and the Apple dev ecosystem a whole lot more.

[kernelbandwidth]

I wonder if there's a cognitive anchoring effect. I've found Android Studio to be the best part of Android development, while Java and particularly Android itself being quite painful. XCode, on the other hand, I've found to be particularly painful, while iOS is much easier to work with, and Swift is one of the most pleasant languages I've used, so XCode looks bad in context, while AS looks much better.

[cwbrandsma]

But are those issues with Swift or with XCode? XCode is a known piece of crap that does not play well with teams. And XCode isn't any more stable with ObjectiveC than it is with Swift.

[coldcode]

Mostly Xcode, but issues with compilation speed in the Swift compiler also means some of the problems are harder to pinpoint the issues.

[bitmapbrother]

In terms of IDE support Go has Gogland by JetBrains.

https://www.jetbrains.com/go/