Swift 2.2 Released | Hacker News Reader

Swift 2.2 Released

swift.org

223 pointsnostrademons115 comments

As someone who refused to sink any significant time into Swift until they open-sourced it, I have found it to be the most productive statically-typed, native language out there. Its type system feels like the best of C# and Rust, while it feels that the speed at which one can pick it up is not that much greater than that of Go despite being a much richer language, (I've started learning in January and am at the level now where I can take on a fairly complex Swift project and feel comfortable about being able to finish it in time, plus I now use Swift for almost any programming task, 90% of them at least). Plus, you have to give Apple credit for getting the open-source release right, (GitHub, pull requests, proposals, mailing lists, frequent dev builds, Linux support - I guess Chris Lattner has been the one driving this, but I have to give credit to Craig Federighi and Tim Cook for letting him do it.)

The only part that frustrates me is that SourceKit seems to crash every other minute for no apparent reason - but that is no fault of the language itself.

Swift is the first piece of Apple software I'm genuinely excited for. Congrats to everyone who contributed to the 2.2 release

> the best of C# and Rust

e.g.? I've only just scratched the surface of Rust and dismissed C# as a Java clone (but maybe I shouldn't have?). What's some examples of the best of Swift that you see?

One case where C# is far superior to Java is generics.

Generics were a cutting-edge feature in 2005. Microsoft took the opportunity to start from scratch, and released the .Net Framework 2.0 without backwards-compatibility, and with full support for generics. A List<String> is actually a List of String.

When Sun released Java 5, they didn't want to disrupt the established Java ecosystem. Their implementation is called "type erasure". As an example, List<String> is actually just List<Object>, with automatic runtime typecasting to String. https://docs.oracle.com/javase/tutorial/java/generics/erasur...

Java's solution works well enough, but it breaks down in certain scenarios, such as multiple levels of generics. For example, when getting an element from a List<List<String>>, Object is not cast to List<String> (which doesn't really exist), but merely List.

C#'s implementation of generics became even more sophisticated with C#4, which introduced covariance and contravariance. https://msdn.microsoft.com/en-us/library/ee207183.aspx

> Generics were a cutting-edge feature in 2005.

Generics have been around since at least the early '80s.

Well, "cutting-edge" in enterprise technology.

Another interesting failed prototype on the JVM was the language "Pizza" https://en.wikipedia.org/wiki/Pizza_%28programming_language%...

Ada isn't enterprise technology?

https://en.wikibooks.org/wiki/Ada_Programming/Generics

http://www.cs.dartmouth.edu/reports/TR86-104.pdf

(From 1984.)

When does it matter what an element from a List<List<String>> is cast to at runtime? In a properly-written statically-typed program, types are a compile-time construct (ignoring the machinery of dynamic linking and method call semantics in particular implementations, which don't matter to the programmer), and though you may use them at runtime via reflection, I would argue that 99% of the time that you do, you're writing bad code. http://stackoverflow.com/questions/20918650/what-are-the-ben...

Type erasure introduces limitations on what you can do at runtime that forces a developer to write code to workaround it. For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary. A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

> A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

I'm not sure how this makes sense. These tags are just standard context bounds, which are extremely useful and quite awesome.

You make it sound as if these tags were some kind of special feature added to the language, or context bounds were solely invented to support these tags.

> For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary.

If a method needs to instantiate an object, the normal technique is to accept a factory function as a parameter. You can do the same thing with type-erased generics.

C# decided to create a shortcut for calling the constructor of a generic type parameter. But, for example, you can't call static methods of a generic type parameter (and a constructor is really just a slightly special static method).

Passing in the class type for instantiating a new instance is not what you should do in your applications. You don't know at compile time if the class you pass in has a default constructor, so your program can fail at runtime. As others have stated, the right thing to do is pass in a factory object. C# solves this by adding even more cruft to the language in the form of a "new constraint" that tells the compiler to ensure that the type has a default constructor. https://msdn.microsoft.com/en-us/library/sd2w2ew5.aspx

Don't Java Generics mess with method (argument type) Overloading?

> Generics were a cutting-edge feature in 2005.

I was already using C++ templates in 1994 with Borland C++ for Windows 3.1!

Ada, CLU and ML go back to the late 70's / early 80's.

Yes, but I guess that code would break in a million ways today in a modern C++ compiler

It certainly worked at the time, for that specific compiler

It was still a language feature even if it wasn't available 100% bug free in all C++ compilers.

C code also used to break left and right long after C90 was approved.

I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

> I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

Curious, what did you need to do specifically? Parameter declarations weren't inlined?

But anyway, C, being smaller, breaks in fewer ways

> Curious, what did you need to do specifically? Parameter declarations weren't inlined?

In those days HP-UX C compiler was still transitioning between K&R and ANSI standards.

We could only properly compile without strange errors while using K&R function declarations.

If memory serves me right, it was the first HP-UX release having support for 64bit file systems.

Templates are not proper generics. Templates can be used to emulate generics, but they are not the same thing at all. Templates are not first-class citizen of the type system (they don't survive to the typechecking phase), while generics are. You cannot write a generic list implementation in C++ and have it typechecked.

I'd like to hear more about that because I'm not sure I understand. Can you give an example for something you cannot do in C++ in a type safe way that you can do in C#, Java or Swift?

I already gave one. You can't write a generic list implementation and make the compiler prove your code is sound (according to the rules of the C++ type system) for any valid type argument value.

You obviously need to learn about template metaprogramming, enable_if, type traits and SFINAE.

C++ templates are Turing complete, you can validate whatever you feel like at compile time.

I'm absolutely aware of enable_if, type traits and SFINAE. But they do not address the concern I raised here. The things you mention come to play on template instantiation, after the concrete (non-generic) types are already known. The problem I mention is that with templates you cannot type check generic code. I can put whatever nonsense enable_ifs on my template declaration and the compiler does not check if they are satisfied by the implementation.

You can write the following C++ code and C++ allows it:

<template typename T> void foo(const T& arg) { arg.bar(); }

This is perfectly fine for a macro system. But this is not how truly generic type system would work. If templates were proper generics, the typechecker would immediately refuse this to compile saying something like: "Error: I can't prove T has the bar() member."

> C++ templates are Turing complete, you can validate whatever you feel like at compile time.

So please write a template metaprogram that validates if a given C++ class (input to the program, given as a template argument) matches a table schema in the database system (the table name and connection string are also given as template arguments). For fetching the schema, you have to connect to the DB, of course at compile time. If the schema does not match, the compilation should fail ;)

Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

Do you want an example how to write it properly?

With or without the upcoming concepts TS already in GCC 6.0?

Also this example would require T to be an interface with a bar method in C#. Do you also want to the the variant with MI and pure abstract classes in C+?

> Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

In a proper generic type system, the compiler validates it, not the programmer. Even if you constrain the type using type traits, the compiler would not check if the implementation satisfies the constraints. I can put a type trait for existence of bar() and then another programmer may rename bar() to baz() forgetting to update the constraint and the code will still compile fine.

Except that reasoning fails with concepts, already available in GCC 6.0 and as a TS.

So you're saying concepts will reject libraries that compile fine today?

They might, if used properly.

I do admit that I need to update myself with what GCC 6.0 allows vs the letter of the TS.

I don't think concepts are even necessary to do what pkolaczk wants to do, which is (I think) to constrain the argument to a particular interface, say Bar:

  template <typename T> 
  void foo(const T& arg) {
    const Bar* b = arg;
    b->bar();
  }

  template <typename T> 
  void foo(const T& arg) {
    static_assert(is_base_of<Bar, T>::value, "T must be a Bar");
    arg.bar();
  }

I can't say I'm a huge fan of either syntax, but the compiler will perform static type checking as if you had written where T : Bar in C#.

The body of the template won't be typechecked until the instantiation of the template. This is different than in C#. If I replaced arg.bar with arg.baz in C#, the generic type definition would not compile, even if I never use it. In C++ I can't write a template and have it typechecked for all possible input types satisfying the type constraints, in C# I can. So C++ type system is weaker than that of C#.

I see what you mean, but uninstantiated also means unused. So we're not talking about anything that could possibly lead to runtime errors. It's not an issue with type safety.

It definitely has a downside for the development process, especially when it comes to writing libraries. But it is also to some degree inevitable if you want structural typing. Maybe there is a better way to do it though.

Now I am curious about an example where generics are able to do what templates, which are Turing complete, aren't.

I think of templates as an automated copy+paste mechanism. C++ templates can bloat the compiled executable pretty significantly... If you define a generic Foo<String> and Foo<Widget>, C++ templates will generate two separate binary implementations. C# will use the same implementation, and perform type checks using reflection at runtime.

Further support for the idea that C++ templates are an automated copy+paste mechanism is that you're allowed to give templates arguments that are not types.

Further reading: https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx

It is not how you think of them, rather what is possible to do with their expressiveness.

C# type checks imply a performance hit and are an implementation detail. Nothing prevents a C# compiler to choose another one. It has nothing to do with generics vs templates.

For example Modula-3 and Ada compilers use the same approach as C++ for code generation of their generics.

So where is that example of something that can only be written with C# generics, but not with C++ templates?

A github gist maybe?

It is not the case of what can only be written, but what can be written and typechecked. C# generics offer much stronger type safety for library writers than C++ templates. C++ templates are not type-checked. C# (and Java, and Scala and Haskell) generics are.

Yes they are type checked.

That is what enable_if, type traits, if constexpr and eventually concepts allow for.

No, they are not. This code compiles fine, despite an obvious non-generic type-error. You may add whatever number of type traits, constexprs, etc there, and it will still compile fine as long as syntax is ok.

  #include <string>

  template <typename T>
  void foo(const T& arg) {
    int x = std::string("int expected");
  }

  $ g++ -c template.cpp
  $ // see, no error

Templates are only syntax-checked. The type checker is not even executed on the non-generic code inside of templates. The type checker will be executed after the template is instantiated (expanded). At that point, generic types do not exist. There exist only concrete types.

They are still type checked when they are instantiated and the code is as generic as always.

Uninstantiated templates are dead code that will be stripped anyway.

Did I write anything different?

Sure, you can type-check them for particular type arguments. But you can't type-check them generally at the generic level and you have absolutely no guarantee that your library code is free of type errors. Not a problem if the goal is to produce the final executable, but a big problem for a library writer, who doesn't control the inputs (in this case: the types provided by the user of the library).

And AFAIK C++17 concepts do not address this problem, really. I can constrain my input types with them, and the calling code will be forced to conform to them (and the compiler will present a nice error message if it doesn't), but there is still no checking on the other side - that is if the template implementation is correct assuming these constraints. I can publicly declare my code requires T.bar(), then shamelessly call T.baz() in the template implementation and the compiler will not catch it.

This is like a Python program. You don't know if it type-checks before you run it, but even if you run it once or twice and it was fine, that doesn't guarantee there are no type errors.

Yes.

The code line int x = std::string("int expected"); has zero relation with any of the template arguments.

So a programmer error that doesn't have anything to do with the types provided for the template.

Sure it will be caught in C#, because its build model assumes the existence of modules and everything is compiled to binary.

In C++ a similar compilation error would occur when compiling the translation unit into a library where the template is instantiated.

Of course, most templates being header only the error will only occur when instating it, but it will still blow on compilation and prevent the final generation of the exe, dll being produced.

Also errors related to semantic type check, independent of template arguments is relatively easy to achieve with unit tests.

I still fail to see how a generic system that doesn't offer partial specialization or meta-programming as being more powerful than templates.

I never said more powerful. I said stronger. In C++ you need unit tests to check something I can have statically proven in C#. And obviously you can't instantiate your template for all possible valid input types, because this number can be infinite.

Monomorphisation is the name of the technique of producing a different version of the code for each set of type parameters that are used in the program. C++ and Rust use monomorphisation instead of doing runtime checks because they're trading off slightly bigger binaries for greater speed.

By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.

Templates are a macro system. Macro systems are often Turing-complete. But if being Turing-complete was the only important thing in programming, then we'd all code in assembly and never look forward. Most programming languages are Turing-complete, but this doesn't mean they are practically equivalent for every job. You know, Brainfuck is also Turing-complete, but you'd be probably pissed-off if I said heavy-templated C++ code readability is often close to that of Brainfuck.

Macro systems can be very powerful, but they are also quite hard to use. It is 2016 and error messages in C++ templates are still inferior to the messages you get in C#, Java or Scala generics, despite templates existing for much longer.

C++ templates are also not the very best at metaprogramming either. Take any macro system like the ones found in LISPs, Scala or Template Haskell - they are much more powerful and consistent with the rest of the language. I can code Scala metaprograms in Scala or LISP metaprograms in LISP. But I can't code C++ metaprograms in C++, I have to use this weird duck-typed functional template language which doesn't have even loops or conditionals.

That weird duck typed functional template language runs circles around C# and Java generics.

I have experience in compiler design and C#, Java and C++ are my tools of trade. So I know their generics systems pretty well.

Maybe if I get bored during Easter I can bother to provide your safe list.

> That weird duck typed functional template language runs circles around C# and Java generics

This sentence doesn't make much sense. Comparing oranges and apples. It is like saying Scala macros are better than Scala generics. C++ templates are neither great at metaprogramming (there are much better macro systems in other languages out there) nor great at generics (Java, C# or Swift generics are not state-of-the-art either, but in some cases I mentioned they are better).

One case where Java generics are far superior to C# (actually CLR) is implementing more advanced generics on top of JVM thanks to erasure. C# generics are too weak to express concepts found in Scala or Haskell type system directly, but at the same time too strong to serve as a base for a standalone implementation of such type systems.

Having worked with both for several years, I would rate C# as a much better language than Java. The language by itself is noticeably better, but the difference is even more pronounced if you include the ecosystem -- Visual Studio vs. Java IDEs, the class libraries, ASP.NET MVC vs. Struts and its ilk. I would check it out if you have the need to do any Windows-related programming. (Not sure how great the support is outside Windows.)

Uh, when was the last time you worked with Java? Struts isn't a popular framework anymore and hasn't been for awhile.

IntelliJ absolutely trounces VSS and some combination of Spring Boot, DropWizard or Vert.x blows ASP.NET MVC away. Not to mention the whole ecosystem is a hell of a lot more open. There is a library for just about anything under the sun.

Enterprise environments tend to be very conservative when it comes to stuff they let you install or even use. Often you can't just drop JARs in there, never mind use your own JRE. So you're often stuck with technology that sites like these consider quite ancient…

It gets even worse on desktops, as sysadmins might be able to isolate a server enough to allow some "new" tech, but vetting a new Java version or library for a few thousand office desktops is a task nobody really wants to do. So I wouldn't be surprised to still see some Java 1.4 Swing apps in use at big insurance or pharma companies. (And if I'd had to pick between that or do a web app that supports their IE8 browsers…)

"Enterprise environments" also have to be very conservative about security issues - which often means they're forced to update to currently supported versions of software. Java 8 is the only version currently receiving security updates.

The same thing applies to many other software packages, including browsers, Linux and Spring. Sane IA folks don't like to deploy known security holes.

It sounds like you're dealing with some backwards-thinking folk. ;-)

We are talking about enterprise here, so backwards-thinking is part of the package. And if you're big enough, you can get by with outdated standard software, either by hiring special consultants or by costly vendor support. I'm pretty sure you can "convince" Oracle to accept your money.

The alternative is auditing all your installed software packages with Java dependencies. Re-hire the agency that did that small Swing client 8 years ago. Hire someone completely new to reverse engineer another client because the original company went belly up. Ad infinitum, ad nauseam.

No wonder they'll do software cryonics.

This is getting better slightly in recent years, when you no longer have that many desktop clients and utilities, as upgrading servers is way easier than building new default images for all your desktop clients.

You are really dating yourself with Struts. That's early 2000s Java tech. Intellij, Java 1.8 and Spring Boot are really nice tools that you're missing out on.

Ah that could definitely be. Back when I switched from Java to C# there was a big difference, even just from having access to lambdas, LINQ, sane generics, etc. But it sounds like Java has gotten better on all fronts, which is great. The main thing I wanted to get across is that while C# has its roots in cloning Java, it ended up being far more than just a clone.

"and dismissed C# as a Java clone"

It definitely looks like that, but I'll take C# over Java any day

Java API looks like it was built by the worse bureaucrats they could find and one piece doesn't fit another except in a very specific (non-obvious) way

Some of the things off the top of my head in no particular order; protocols, (closer to traits than interfaces), Optional types, (elsewhere no null types), pattern matching (if let, case let), guards, (so you can cover your preconditions nicely), immutable let bindings first, var variables second, (with mutability being tied to the binding outsite of reference types/classes), tuples, lazy evaluation, flexible closure syntax, fairly powerful type inference, enums as tagged unions, (or as standard C enums if you want), extensions - even for core structures if you need it - straighforward way to define custom or overload existing operators, type system powerful enough to be able to implement a fairly convincing Functor, Applicative or Monad without much effort, structs AND classes, most things are value types...

But most importantly to me, Swift is composed in such a way that it just 'clicks' for me, ie many times many times I can guess how something is likely called or how it will behave without looking at the docs and I have a solid chance of being right - that 'intuitiveness' is something that is lacking in many other languages I've used over the years.

In regards to C#, by now it is definitely not just a Java clone anymore, in particular saner type system and much more functional features edge it for me over Java, plus the speed of evolution is much greater in the C# land. If you want to see how C# and Java differ but are tied to the JVM, try Kotlin: http://kotlinlang.org - it's fairly similar in feel to C# and has 100% Java compatibility.

I love Swift dearly - I spent two years in Objective C land, after 8 years of C# and 10-ish years of C++ pain, and started using Swift day to day from Swift 1.2. But the current version have one big gaping hole: generic protocols are utter shit. For the uninitiated: Swift generic protocols don't have generic parameters, they have type constraints. Which means that a function can't return generic protocol. Which is the stupidest thing ever.

There's a way to dance around that restriction, by making an intermediate class to do type erasure by hand (why I should do that? That's compiler's job), but still - Swift crew are obviously very talented bunch with a good taste, how they allowed such nonsense from the start?

PS I don't want to sound too negative, Swift replaced C# as my favorite language, 95% of the time it's joy to use (especially after Objective C, I never agreed with that language), it's just - the generic protocol thing drives me mad.

Yeah, somewhat related to that; it's not currently possible to have typealias for a type with generic parameters, one has to wrap it in a struct or an enum, however Swift is very much not done and they're catching up quickly, so I'm optimistic, especially now that we can see and affect what's coming next.

Generic typealiases are coming, thank goodness: http://ericasadun.com/2016/03/08/generic-typealiases-are-a-t...

Awesome! This is what I'm talking about; now that Swift is open-source we can see which improvements have landed and what is coming next. Thanks for the link.

Have you used OCaml? Swift seems very similar to OCaml from what I can see - without the nice module system, but perhaps with a more familiar syntax.

Looks like two potentially breaking changes at source level:

https://github.com/apple/swift-evolution/blob/master/proposa...

Are those not going to be marked depecrated and broken in swift 3?

In Swift 2.2 they're going to add warnings but they won't break previous versions of source (yet).

In Swift 3.0 they'll remove the deprecated syntaxes.

That's a fair point. In practice, it doesn't mean any less work, just longer to rewrite offending code...or not to. Deprecation still imposes debt.

Non deprecation also imposes debt. So does stagnation. So you pick your poison.

Better than the debt of a changed language/library that allows for multiple and confusing variations thanks to not removing those features (syntax, keywords, functions). It makes looking at old documentation difficult (it's wrong now), but also means that outdated guides aren't still correct (so they'll get culled or corrected more quickly) and we won't have the OpenGL situation.

Don't forget the removal of the C-style for loop, along with the increment ++ and decrement -- operators.

https://github.com/apple/swift-evolution/blob/master/proposa...

The one's I linked to are listed as changes incorporated into Swift 2.2 per the announcement.

I am baffled by the for loop removal thing.

I just spent a while reading about both stride and for ... in, and I feel like there are any number of cases where I would rather use a C-style for loop.

I'm not familiar with swift, but Python doesn't have C style for loops either. People just write:

for i in range(10):

instead.

More generally, people write:

for item in sequence:

which is somewhat general (sequences include lists, dicts, strings, tuples, generators, text files and more [2]), and it covers a wide range [1] of use cases.

[1] Pun not intended.

[2] Basically, any iterable. This include custom iterables you can define, which can then be iterated over using the same standard for loop. A unifying feature of the language:

"The use of iterators pervades and unifies Python."

https://docs.python.org/2/tutorial/classes.html#iterators

what sort of cases?

Could you use a while loop instead?

I feel like (as long as the numerical case optimizes to the same thing) the for-in loop (and occasional use of the while loop) is clearer.

Theres only a case here where iterating over a parent/child relationship, and testing for nullability, its more clear with the c-style for than with a while loop:

// old

for x: Thing? = thing; x != nil; x = x.parent {

...

}

// and now

var x: Thing? = thing

while x != nil {

  ...

  x = x.parent

}

It was the only case i've really missed it.. unless theres a better way to do it that im not aware of..

But the for c-style loop for numbers is really not needed

Ideally that sort of relationship should probably be an iterator, though it's still useful for internal type implementation methods.

I am not sure if there is a name for this type of function, so I called it someFunction:

    func someFunction<T>(initial: T, next: T -> T?) -> T
    {
        var current = initial

        while true
        {
            switch next(current)
            {
            case .Some(let value):
                current = value
            case .None:
                return current
            }
        }
    }

Now you can express that idea generally, e.g.:

    extension UIView
    {
        var rootView: UIView
        {
            return someFunction(self, next: { view in view.superview })
        }
    }

I also didn't test it, so it might not work.

Of course, it would be more Swifty to create a "Parentable" protocol and write that as an extension of it!

Changes like this are usually converted automatically by the Xcode migration tool...

i can't believe how much people here on HN love swift! do you guys really love stuff like implicitly unwrapped optionals and awkward syntax where you need exclamation marks all over the place. not to mention their insanely complicated use of enumerations. what about a completely half-baked standard libraries where even basic string operations such as doing a substring are unnecessarily complicated and verbose? i simply cannot see any real basis for all the love for swift.

>implicitly unwrapped optionals

This only exists for objective-c introp, and the creators are actively trying to find ways to get rid of it. On the other hand, in nearly every other language, all pointers would be considered implicitly unwrapped optionals, while in Swift you get optionals built in (food for thought).

>awkward syntax where you need exclamation marks all

Oh come on, syntax does not define a language. If they used a different character or an operator, would you be more happy? Either way, it does take some getting used to but eventually it feels natural.

>insanely complicated use of enumerations

What?! This is one of my favorite features! You can represent so many things with an enum and it can make your code much safer. My favorite two examples are representing JSON as an enum, and the fact that Swift's Optional is actually just an enum with cases .none and .some(T).

>basic string operations such as doing a substring are unnecessarily complicated and verbose

I somewhat agree with you on this. They have their reasons (mostly because strings can have varying sizes, so indexing a utf8 string, for example, can give unexpected results) but I still wish they did something about it.

Happy about renaming typealias to associatedtype, now I don't have to constantly explain why I am using typealiasis when dealing with bugs.

Sad Ubuntu LTS user:

> error: opening import file for module 'SwiftShims': No such file or directory

Apparently the problem with GCC ABI break hasn't been tackled yet.

https://bugs.swift.org/browse/SR-23

As info, the only workaround is to rebuild Swift from scratch.

now they just need to open source Xcode..

swift comes with 'swift-ide'test' which I believe is the linter/codecompleter that would allow any text editor to have the features that xcode has

Interesting! I found https://github.com/apple/swift/tree/master/tools/swift-ide-t..., which seems to be what you describe, but seems a bit tricky to use. Can you point to any OSS implementations of a Swift completer?

I’m not sure you’d really want the crap-fest that is Xcode’s code. It has so many bugs and issues that it’s a better idea to completely dump it and either start over or give up and adopt something like AppCode, like Google did with Android Studio. Making developer tools is just not Apple’s forte and Xcode’s sad state of quality and performance is clear indication of that.

I’m thoroughly convinced that Apple has an internal-only IDE that they use that is far better than Xcode and is actually functional, much like the internal Radar tool. There is no way Apple’s engineers could get any work done if they use Xcode.

Or, they should start charging money for it so they could justify spending resources on the dev tools. One of the reasons (among many) that Visual Studio is still the king of all IDEs is because Microsoft charges money for the serious bits of it (Pro and higher).

Xcode works fine for me. I can't say the same for Android Studio, which seems to require a machine more powerful than a top-of-the-line MBP.

I think you're seriously overstating the issues with Xcode. There are bugs and annoyances, but things have gotten better over the years. It's not as great as Visual Studio, but it's far from horrible. Remember, we live in a world with Eclipse.

Is Eclipse still growing exponentially? I remember Ganymede -> Helios increasing 2MM LOC, Helios -> Indigo 4MM LOC, and Indigo -> Juno 8MM LOC. I couldn't even get Luna to run, and haven't checked back in on it since then. The foundation started to bundle up too much stuff in the distributed versions.

If AppCode ran on other platforms and became a Swift IDE that would be great honestly, not sure how long before JetBrains attempts this. As things stand those of us curious for Swift without any access to Apple products are left with just plain text-editors.

The new CLion 2016.1 release has some Swift support on Linux via a plugin: https://plugins.jetbrains.com/plugin/8240

I want to use Appcode, but the support/autocomplete for swift is just not as good as XCode.

"Making developer tools is just not Apple’s forte"

I'm sorry, but LLVM?

Technically, LLVM started as a research project at UIUC, and then Apple hired the principals and adopted the project in 2005. The LLVM website is still hosted by UIUC, and Google and other companies are also significant contributors.

Right, Apple DID NOT make LLVM. They just hired the guy that did (Chris Lattner) well after it was fully established.

And then maintained it and fostered its growth while it became the foundation of modern computing…?

Some people are really scared of Apple being cool.

Maintaining and growing an existing tool with its existing developers who you bought in is a good thing and to be applauded, but doesn't necessarily mean the company is good at tooling in general. The cultural requirements are very different.

You've just described 90% of every major product from a technology company.

>I’m thoroughly convinced that Apple has an internal-only IDE that they use that is far better than Xcode and is actually functional, much like the internal Radar tool.

That's an interesting point and it makes a lot of sense. With the scale of the codebases a lot of them are working on I also don't see how they could be productive while working in XCode. And also XCode could not be this buggy and broken if it had internal developers working with it and constantly reporting bugs.

The response from a friend who works at apple was laughter and "if only".

personally, I'm the kind of guy with a "vim 4 life" tattoo, so I don't really know why people put up with crappy IDEs...

How does it make a lot of sense? If Apple had a tool that was better than Xcode, why would they hide it from the public? They have proven themselves to be quite motivated to provide developers with good tools and frankly I find the idea that they keep a better tool hidden away ridiculous.

thought_alarm got it right. The experienced developers probably use open source editors / debuggers, unsuitable for the masses. Not an Apple-only tool, but still not XCode.

The experienced developers at Apple are no different than the experienced developers elsewhere. They use the LLDB command-line and write their code in Emacs.

I've never liked Visual Studio, and the last time I worked on a serious Windows product most of the experienced developers used WinDbg and cordbg rather than the neutered Visual Studio debugger. And some guys still wrote their code in Visual Studio 6 rather than the newer .NET IDEs.

My problem with Xcode today is that it's too much like Visual Studio. I'll take Xcode 3 with LLDB any day.

vim. /ducks

Command-line tools are great but graphical displays can be useful, too. The real problem is that pane/window management on OSes is years behind where it should be.

What I want is a way to take any view I please, from any application, and arrange it anywhere in a standard way with keyboard support and sensible omissions of chrome. If this means 65% of my screen is terminals, 20% web browsers, 10% some graphical view from Xcode and 5% notifications, that should be perfect fine. Instead, the most the Mac has been able to cobble together is a simple split screen view and that is only for Full Screen.

And, we also have: Xcode with its own completely custom and quirky pane/tab management scheme, terminals with their own pane/tab scheme, browsers with their own tabs, etc. Individual applications continue to feel some need to over-engineer their own pane/window management to compensate for lack of system support.

There are some signs of hope though. The direction Apple is going with Mac view controllers could theoretically put them in a position to finally turn individual views into first-class citizens that would be feasible to interleave arbitrarily across applications. At that point, command-line tools could integrate very nicely in arbitrary ways with elements that really benefit from being graphical. We’ll see.

I have been using https://www.spectacleapp.com/ for a while now, and it has performed like a champ. Easy window resizing and organization with keyboard shortcuts.

I think Xcode, Instruments etc are _amazing_ tools...especially for the price. Compare with the Android toolchain.

>especially for the price.

Yup! They're free! I have found Apple's developer ecosystem to be fantastic overall.

That is not my experience at all using Xcode professionally for the past 3+ years, and Visual Studio for over 7 years. Most of the complaints I've heard from colleagues about Xcode seemed from using unofficial 3rd party plugins, or Xcode's inferior c++ support for massive projects haphazardly ported form windows.

Xcode for iOS and Mac development has been the most productive IDE I've used professionally, not without its flaws, and unintuitive nuances, but continually improving. Yearly major ticket feature additions like UI Unit testing shows me Apple is still heavily investing in developer tools.

> like Google did with Android Studio

You mean by still not being able to provide an working experience to the NDK users, three years later?

Or by redoing their plugins for Android Studio 2.0, forcing devs that rely on something stable to still be on Android Studio 1.5?

Also by having each release be a bug party that make people at /r/androiddev/ wonder if they ever test what they release?

I find Xcode quite a joy to use. It seems well laid-out, not a lot of UI chrome, easy to find the things you need and get things out of the way when you don't. Code completion, debugging, it's all pretty great for me. Not sure if the degree of your hate for it is accurate.

I agree, Xcode is definitely the best looking IDE by light years. Now if only it had a dark mode...

Have you checked out the Fonts and Colors panel in the Preferences? You can choose both font color and background color and other items.

Yeah, but all the panels remain white.

I think it would far more beneficial if they open source Cocoa/CocoaTouch. I don't care how the IDE works as much as the stuff I use every single day.

I agree. I don't even need very permissive license, just to look at sources would be enough. Sometimes I have to lurk around internet corners just to find out simple things which would require few minutes with source code access. It's so frustrating after Java environment where almost everything is available in source code.

The "source" is almost out there. Attaching the debugger to a 64-bit simulator and putting a breakpoint on Apple methods and functions, you can effortlessly read the disassembler code output by lldb/Xcode. I have fixed and learned countless UIKit-related bugs like that.

Reply on news.ycombinator.com