[geodel]

Interesting interview. Java is mentioned many times as language Swift aspires to replace. He is right about Kotlin:

"Kotlin is very reference semantics, itʼs a thin layer on top of Java, and so it perpetuates through a lot of the Javaisms in its model.

If we had done an analog to that for Objective-C it would be like, everything is an NSObject and itʼs objc_msgSend everywhere, just with parentheses instead of square brackets. .."

I think Swift has real chance to reach Java level popularity. It is already at #11 in Redmonk ranking. All languages above Swift are at least 15 year older than Swift. And once it server side features like concurrency it can be much more general purpose.

[gurkendoktor]

I wish Swift focused on reference semantics. One of the big problems of value types in C++ is that you have to be a language lawyer to not accidentally make wasteful copies of everything, and the same is true of Swift:

http://rosslebeau.com/2016/swift-copy-write-psa-mutating-dic...

I thought Objective-C had already solved this problem quite nicely with the explicit NSFoo/NSMutableFoo class pairs. I don't see why this needed to be fixed again, in a less explicit way.

[bushin]

They are trying to address that https://github.com/apple/swift/blob/master/docs/OwnershipMan...

[kjaleshire]

> One of the big problems of value types in C++ is that you have to be a language lawyer to not accidentally make wasteful copies of everything...

Not always. The C++ standard has allowed copy elision for some time [1]. Guaranteed copy elision for certain forms of copy has been proposed for C++17 [2].

[1] http://en.cppreference.com/w/cpp/language/copy_elision

[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p013...

[catnaroek]

The conflation of values (which exist in the language's semantics on paper) with physical representations (which exist in computer memory) plagues most imperative languages that try to do value semantics.

[pjmlp]

For that to happen Swift needs to be usable at Java level in all OSes where JVM/JDKs (some of them with AOT support since the early days of Java) do exist.

I am still waiting for first class support on Windows on the download page.

Right now Rust has much better OS support than Swift.

[LeoNatan25]

At the timeframe discussed on the panel, I don't think Swift is really lagging. In few years, it has gone rather well, and in few more years, it should mature a lot more on multiple platforms. Right now, I think attempting to use Swift on a Linux server would be a big nuisance; it's enough to look at the open-source implementation of Foundation & co. and the many trivial things still missing. Once that is complete, it should start becoming more interesting. I don't think the push for Windows support will be very difficult.

[Duckton]

  I think attempting to use Swift on a Linux server would be a big nuisance

I beg to differ. Look at Vapor, Kitura & Perfect. I know Foundation is missing implementations for Linux, but it is not something that makes it a big nuisance IMO.

You can quickly have a setup with Swift on Linux running a simle CRUD app.

[pjmlp]

Yes it is possible and IBM is the one pushing for it.

However it is still light years behind JEE and Spring features, including parity with existing JDBC drivers.

Also besides instruments on OS X, there are no comparable performance monitoring tools like VisualVM, Mission Control and many others from the JDK vendors.

[LeoNatan25]

But as far as I know, Instruments is using tools available already in lldb, clang and dtrace. So building a UI that displays the collected data should be more than possible.

[coldtea]

>For that to happen Swift needs to be usable at Java level in all OSes where JVM/JDKs (some of them with AOT support since the early days of Java) do exist.

No, you seem to confuse "replace Java" with "TOTALLY AND ABSOLUTELY replace Java everywhere".

Swift just needs to be usable on the platforms that matter -- and since it's by default on OS X, that leaves Windows and Linux.

Nobody cares if it runs on some mainframe architecture that 0.001 of Java use happens, or some other obscure environment.

[pjmlp]

Apparently you have forgotten about Android, smart cards, blue ray players, embedded devices controlling your electric and heating bill, car infotainment systems, IoT gateways, Cisco phones, Ricoh and Xerox laser printers, ....

Also as of 2017 Swift is still quite unusable on Linux beyond a few demo apps and on Windows nowhere to be seen.

Additionally GNU/Linux, BSD and Windows are better served by Rust, SML, OCaml, Haskell and F# than Swift.

In all aspects that matter, they have better compilers to chose from, IDE support, libraries and tooling.

The positive aspect of Swift is being a modern multi-paradigm language being pushed by a company like Apple, which will hopefully improve the adoption of such languages.

However outside Apple's own operating systems, Swift has a very long road to travel before it gets any kind of meaningful adoption, let alone being a threat to programming languages on GNU/Linux, BSD and Windows.

[coldtea]

>Apparently you have forgotten about Android, smart cards, blue ray players, embedded devices controlling your electric and heating bill, car infotainment systems, IoT gateways, Cisco phones, Ricoh and Xerox laser printers, ....

I haven't forgotten them, but apart from Android, I simply don't care for them as domains where Swift should dominate to call it a Java replacement. Nobody cares what runs in a set top box or smart card reader, and blue ray players wont be a thing very soon (if they ever were).

Heck, even Android is moving to Kotlin (and it's Davlik no JVM, so it's twice removed from Java now) and don't they also do a new framework for Android programming with Dart? And Fucsia, when that comes out, I don't see it featuring Java either.

I don't think Lattner had those things in mind when he mentioned competing with Java either. Nor did he had in mind some future in which Java has 0% market share and Swift has all of Java's share in every domain. (Plus, he mentioned the server side and service development as targets Swift is interested in specifically).

>Additionally GNU/Linux, BSD and Windows are better served by Rust, SML, OCaml, Haskell and F# than Swift

That would be relevant if somebody had said that Swift is to replace them today. But what was said was an intention. Not a description of the current situation.

(And let's be real: I don't think Ocaml, SML and Haskell will ever go that far at the stakes Swift is interested in. They are excellent languages but either too esoteric, or with too small communities that don't show much signs of getting any bigger. Languages with corporate backers, on the other hand, usually fair much better -- so Rust still plays, even if Mozilla is not a major player, because it also chose a much needed niche).

[pjmlp]

> Heck, even Android is moving to Kotlin (and it's Davlik no JVM, so it's twice removed from Java now) and don't they also do a new framework for Android programming with Dart? And Fucsia, when that comes out, I don't see it featuring Java either.

Apparently forgetting again that without Java and the JVM there isn't Android studio and 100% of all major Android libraries are written in Java.

Java will never go away from Android, just like C will never go away from any UNIX-like OS.

Praising Kotlin while bashing Java, is like thinking any UNIX derived OS will ever use anything other than C for its system level programming, or that JavaScript will ever stop being the king of the browser in spite of WebAssembly.

The framework you mention is Flutter and the Android team doesn't have anything to do with it. It is being developed by the Dart team while searching for whatever might become the language's killer feature to be adopted outside AdWords team and Google walls.

Java might eventually lose to other programming languages, hence the active work regarding improvements on AOT compilation, value types and GPGPU programming.

But the language taking Java's place surely won't be Swift.

[vorg]

> Kotlin is very reference semantics, itʼs a thin layer on top of Java

One of the main points of Kotlin is that it integrates tightly with IntelliJ. So Kotlin is a layer (not so thin) between a visual IDE (IntelliJ or Android Studio) and Java-decompilable bytecodes on the JVM.

You don't get that with other JVM languages, e.g. Apache Groovy only gives correct type hints in Eclipse 80% of the time, and JAD stopped working on Groovy-generated bytecodes in Groovy 1.7.

[nine_k]

Kotlin also happens to compile to JS and native code (using LLVM).

It's very wide use of lambdas with unique syntactic support for them makes it feel very different from Java.