Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go vs. Swift [pdf]

github.com

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Go vs. Swift [pdf]

#41

Post by xenadu02 »

wyager wrote: post #26
austinz wrote: post #17

Earlier quoted context omitted.

Swift supports ADTs and implements its Optional type as an ADT.

> Swift supports ADTs True, but perhaps not practically relevant. The pattern matching in Swift isn't much better than what you would get with a tagged C union, which is why no one really uses it very heavily. The Optional type in Swift gets a lot of special compiler support, which is indicative of the fact that the broader language isn't very friendly towards using ADTs to structure data. But you're right, I should…

In what way is Swift pattern matching not "much better than what you would get with a tagged C union"?

enum in Swift has pattern matching support, can have properties, adopt protocols, etc.

I would disagree with your assessment that "nobody uses them".

Re: Go vs. Swift [pdf]

#42

Post by ridiculous_fish »

melling wrote: post #18
blario wrote: post #7

Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.

I would hope that Go is better in all of the above. It has been available for much longer, and it's supported by a great team. I want to know how the languages compare for writing code. Dos one make it easier to write more succinct and correct code? Swift is missing concurrency support until at least the next version, for example.

Go's compiler emits naive code quickly. For example, parameters are always passed on the stack.

Swift is built atop LLVM, and it emits code more slowly, but supports many optimizations like hoisting, vectorization, etc. that Go does not currently perform.

Re: Go vs. Swift [pdf]

#43

Post by wfleming »

hardwaresofton wrote: post #37
seanalltogether wrote: post #6

The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.

While I'm sure you're aware, Java 1.8 does have Optional support ( https://docs.oracle.com/javase/8/docs/api/java/util/Optional... ). Once Jack is completed ( https://developer.android.com/guide/platform/j8-jack.html ) I assume you'll be able to use it too. Of course, you can also just use a library (like Guava) that makes Optionals available (and somewhat close to the spec so you can phase it out in the future if ne…

Maybe I'm wrong about how it works, but I feel that Optionals in Java are a bolt-on solution that only solves half the problem that the same concept solves in Swift (or Haskell, or Rust, etc.)

An Optional in Java is just another value, and nothing in practice stops that from being null. I.e. a method that returns an Optional can still return an actual null if poorly implemented. So the major benefit Optionals give you in Java is a typed declaration that the method may return an "empty" value, which is certainly helpful for knowing what cases your client code needs to handle, but it does not guarantee that the method will never return null. It reduces the probability of unhandled null pointers, but it does not eliminate them.

On the other hand, Swift & co. guarantee at compile time that a function which says it returns an Optional will always return an an Optional, never a null, and, better still, if a function says it returns some non-optional value, it still is guaranteed to never return null.

It's great that Java is pushing for this style of code, but I'm afraid without compile-time guarantees of return values it will always feel less powerful there.

Re: Go vs. Swift [pdf]

#44

Post by kernelbandwidth »

jordansmithnz wrote: post #25
bsaul wrote: post #10

Earlier quoted context omitted.

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.

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 a…

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.

Re: Go vs. Swift [pdf]

#45

Post by tnecniv »

anonfunction wrote: post #40
jakerockland wrote: post #28

Earlier quoted context omitted.

Because it's nice to learn how to use new tools? Hadn't used LaTeX before and saw this as a good learning opportunity for getting started. I'm confused as to what is wrong with writing this piece with LaTeX?

I'm not who you're replying to but I was looking for some way to convert it to an html page. It's unfortunate that the only readable copy is the pdf since it cuts the code examples and renders poorly on my laptop.

Interesting, it renders fine on mine (not OP).

Re: Go vs. Swift [pdf]

#46

Post by solidsnack9000 »

> Because concurrency is supported through an Apple API rather than being explicit in the language’s design, using it is currently very much coupled to iOS or macOS development.

I am not sure this is accurate, because libdispatch has been ported to Linux:

https://github.com/apple/swift-corelibs-libdispatch

They are "...early in the development of this project..." but server-side frameworks use it.

Re: Go vs. Swift [pdf]

#47

Post by GregBuchholz »

ridiculous_fish wrote: post #20
wyager wrote: post #16

Earlier quoted context omitted.

> the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenev…

One of the things that makes Optional so pleasant in Swift is the syntax support. This includes optional-chaining, if-let and guard-let unwrapping, and some convenient operators. For example, in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. But in Swift this works like you would want. All that is to say that Options in Swift are a bit nicer than what you could get wit…

>in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails.

    -- Probably nothing like in Swift
    instance (Num a , Integral a) => Num (Maybe a) where
        fromInteger x = Just (fromIntegral x)
        
    main = print $ 5 == (Just 5)

Re: Go vs. Swift [pdf]

#48

Post by kazagistar »

wyager wrote: post #16
seanalltogether wrote: post #6

The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.

> the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenev…

Swift does fully support ADTs, and can easily model result types, they just chose to have catchable exceptions as well.

Re: Go vs. Swift [pdf]

#49

Post by kazagistar »

melling wrote: post #18
blario wrote: post #7

Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.

I would hope that Go is better in all of the above. It has been available for much longer, and it's supported by a great team. I want to know how the languages compare for writing code. Dos one make it easier to write more succinct and correct code? Swift is missing concurrency support until at least the next version, for example.

I'm not sure, Go code isn't all that fast.

Re: Go vs. Swift [pdf]

#50

Post by lern_too_spel »

wfleming wrote: post #43
hardwaresofton wrote: post #37

Earlier quoted context omitted.

While I'm sure you're aware, Java 1.8 does have Optional support ( https://docs.oracle.com/javase/8/docs/api/java/util/Optional... ). Once Jack is completed ( https://developer.android.com/guide/platform/j8-jack.html ) I assume you'll be able to use it too. Of course, you can also just use a library (like Guava) that makes Optionals available (and somewhat close to the spec so you can phase it out in the future if ne…

Maybe I'm wrong about how it works, but I feel that Optionals in Java are a bolt-on solution that only solves half the problem that the same concept solves in Swift (or Haskell, or Rust, etc.) An Optional in Java is just another value, and nothing in practice stops that from being null. I.e. a method that returns an Optional can still return an actual null if poorly implemented. So the major benefit Optionals give yo…

Use JSR305 with Findbugs or SpotBugs to solve the problem at compile time. Using Optional in Java does have a problem with extra object overhead, so if you want to avoid that, you should use another language like Kotlin or Scala.
Post reply on HN