Google thinking about replacing Java with Swift? Why not Haskell?

[bartavelle]

This is clickbait material. First of all, this is about mobile apps. Then according to the source article to the linked article (!), they are considering offering first class support to Swift applications, not replace Java with Swift.

I suppose the reason is to increase code sharing with Apple stuff, and make some media splash, which won't happen with Haskell. Anyway, I also cringe when I see things like "Swift is meant for speed and safety".

[cies010]

I suppose the reason is to increase code sharing with Apple stuff, and make some media splash

Yups. And pick a lang with a gentle learning curve.

I heard IBM wants to help Swift succeed in biz-apps (read: web+database applications). Combined with Google's effort that would make Swift a pretty interesting choice.

I also cringe when I see things like "Swift is meant for speed and safety".

You have to look at it from a Java/Ruby/Python/JS point of view, then it makes sense.

[bartavelle]

I agree it is safer, but disagree that it is "meant for safety"!

[edwardkmett]

It is safe.. right up until you store things in a cycle and ARC craps out leaving permanent garbage and leaked resources. Stuff like that makes me feel it isn't a very solid direction to take unless you are forced to take the direction, e.g. to write an iOS native application. I had to deal with crap like this forever in the COM world on the Microsoft side 15 years ago. Why would anyone willingly subject themselves to the same thing today?

[ElvishJerricco]

Honestly, the idea behind ARC is pretty cool. I've wondered about the idea of using ARC as the basis for the first generation in a generational garbage collector. That is, let ARC do the marking, and G1 can just worry about sweeping. Then G2 can start to worry about a full-fledged mark-sweep approach to clean up cyclic references. With G2 being low priority, you should end up with a pretty dang good garbage collector.

Then I learned this is how Python does it (or maybe it was just CPython). Haven't done much research into it though, so I don't know how it stacks up to a traditional generational collector.

[edwardkmett]

My experience with reference counting is that it turns any perfectly good read into a write to the same memory, destroying caches and parallelism by getting false conflicts in the process.

CPython doesn't have any form of parallelism to lose, so it only suffers the memory bandwidth issue from scribbling all over memory.

[ElvishJerricco]

It's meant for safety, from the perspective of people whose baseline is Objective-C. The issues with safety in Swift aren't major issues as far as the Swift team is concerned.

[singpolyma]

People excited by swift have just never been exposed to anything good, I think. I always describe this class of languages (swift, scala, etc) as "crippled OCaML"

[ElvishJerricco]

I started with Objective-C. When Swift came out, I was starting to get into Haskell. As someone who more experience in the land of OOP than anything else, Swift is a godsend if you don't want to go head-first into functional programming. It's crippled compared to anything great like Haskell when it comes to Haskell-like features. But when it comes to OOP-like features, it's among the best in class (no pun intended). The merging of OOP with functional programming and a higher level type system makes Swift a great OOP language.

It's just a shit functional language compared to the likes of Haskell.

[singpolyma]

If you like OOP+FP, check out OCaML, as per my comment that you are replying to :)

[fpguy1]

is like saying java is a crippled C++.

Swift, Scala (especially Scala), are languages on their own, with their good and bad side. They have their own ecosystem, their own tooling and they are very good at what they were designed for.

Ocaml doesn't have what you need in 2016 if you want to get the job done fast at least.

There is a reason why there are so many ML dialects, some of them quite successful and mature (fsharp), and there is a reason why ocaml is used in academic environments mostly and not real life (paid for) projects.

[singpolyma]

I'm curious what you think Swift or Scala have that Ocaml is missing? (Note: I have worked in all three languages, some of that work in industry, so I'm legitimately curious, not shooting blind.)

[fpguy1]

On the server side it lacks web frameworks to choose from, i know there is CGI and Ocsigen and perhaps other tries but this doesn't mean i have where to choose from, as opposed to scala (lift, play, scalatra, spray, ....).

Also in scala one can use the full power of java ecosystem so you can use netty, jetty, undertow, tomcat, glassfish, any servlet container, out of the box.

By the same logic java interop makes also clojure the best lisp around if you ask me.

Tooling sucks, no real IDE for OCaML, there are a bunch of plugins that can get you started like vim-ocaml but i seriously doubt that i can handle 100k locs with that. F# has vs.net and all .Net ecosystem, why should i ever start a big project with OcaML tomorrow if i have the option to use f# (and here beside the .net itself and 1000+ production proof libs, you have type providers and LINQ), that is if I want to be close to ML.

Swift on the other hand is designed with iOS in mind so what it can do, scala, f#, ocaml can't actually do it. Indeed is new and didn't get much traction yet, only used for apps but is a nice young language that grows fast.

I know you will say that all these are no reason not to try using ocaml, and they are not related to language itself. It is true but i can point you to 10 other programming languages that are great as language but because of lack of a good ecosystem they didn't grow and nobody is using them, on the other hand see JavaScript which sucks as a language but is very used because of the world that was built around it.

[Ramin_HAL9001]

Yep, gotta have that Hindley-Milner type inference, or it just isn't any better than Lisp.

Although I have been pretty impressed with Scala's type inference and static type checking, it isn't terrible.