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

51–60 of 128 posts

Re: Go vs. Swift [pdf]

#51

Post by hardwaresofton »

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…

I completely agree with your point -- you can't compare the power of compile-time checking to Java's Optionals, for the most part.

However I tend to think that what's important about Optionals is the spreading of the notion of thinking critically about failure modes around improper input/output. "Defensive" coding is often considered a mid-range skill (at least I think), and IMO it's because a lot of junior programmers just assume if some method get ObjectThing a, it's going to be there, and not null. I think merely seeing Optional a encourages movement in the right direction as far as program correctness, a road that will almost surely tour through concepts and languages that take that kind of correctness more (ex. Swift, Haskell).

Also, Optionals are a light introduction to functors which is nice.

For more concrete actionable stuff please see other comment (https://news.ycombinator.com/item?id=13433335), there are tools that can do this at compile time for java

Re: Go vs. Swift [pdf]

#52

Post by jakerockland »

solidsnack9000 wrote: post #46

> 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.

This is one of the things I have marked as an issue to elaborate a bit more on.

https://github.com/jakerockland/go-vs-swift/issues/8

Thanks for the link! :)

Re: Go vs. Swift [pdf]

#53

Post by mahyarm »

zomgbbq wrote: post #34
mahyarm wrote: post #19

Earlier quoted context omitted.

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

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

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.

Re: Go vs. Swift [pdf]

#54

Post by solidsnack9000 »

jakerockland wrote: post #52
solidsnack9000 wrote: post #46

> 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.

This is one of the things I have marked as an issue to elaborate a bit more on. https://github.com/jakerockland/go-vs-swift/issues/8 Thanks for the link! :)

The two differences that I wonder about:

* What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model.

* Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide which queue to put things on; but also kind of requires it of you.

Re: Go vs. Swift [pdf]

#56

Post by tomjakubowski »

comex wrote: post #29
wyager wrote: post #24

Earlier quoted context omitted.

> This includes optional-chaining, Haskell has bind (>>=) and do-syntax, rust has `and_then`. This is pretty standard with any ADT-supporting language. > if-let Most languages with ADT support have good pattern matching that subsumes if-let syntax and allows you to do other things as well. Swift's pattern matching, such as it is, is a bit of a mess. > guard-let unwrapping Haskell has `guard` and `MonadFail`, which ad…

Rust copied 'if let' from Swift (~2 years ago) despite having decent pattern matching; community consensus today is that it's highly worthwhile as a feature. There have also been proposals to add 'guard let'. So, while I don't have enough Swift experience to judge its ADT support overall, I wouldn't cite those features as evidence that it's wanting. They might not be as natural in traditional FP languages like Haskel…

> Rust copied 'if let' from Swift (~2 years ago) despite having decent pattern matching; community consensus today is that it's highly worthwhile as a feature.

Rust copied 'if let' and made it far nicer and more capable by allowing arbitrary fallible pattern matches to be the condition. Then Swift 2 copied that improvement back with 'if case'.

Re: Go vs. Swift [pdf]

#57

Post by Nullabillity »

lern_too_spel wrote: post #50
wfleming wrote: post #43

Earlier quoted context omitted.

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.

Scala's Somes cost an object as well, though (I believe) None is free in both Java and Scala.

Re: Go vs. Swift [pdf]

#58

Post by edblarney »

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.

This is a big thing for Swift - the 'optional' paradigm is totally unavoidable, and heavily affects the code as usage is fairly pervasive.

Not having used them much in the past, I rather don't like them, but I'm aware of the fact they could simply take getting used to.

Anyone chime in on whether or not Optionals are really the 'future of good syntax'? Or they are quirk? Or good in some cases, not for others?

Re: Go vs. Swift [pdf]

#59

Post by eridius »

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…

I don't know what kind of Swift code you're writing, but you're very, very wrong when you say "no one really uses it heavily". Pattern matching is in fact quite powerful and is used heavily in any codebase that isn't simply a straight porting of Obj-C idioms.

> The Optional type in Swift gets a lot of special compiler support

Only the ?. optional chaining operator (and technically the ! postfix operator too, though that could have been implemented in the standard library instead of being special syntax and in fact I'm not really sure why it isn't just a stdlib operator). And probably some logic in the switch exhaustiveness checker so it knows nil is the same as Optional.none. Everything else (including the actual pattern matching against the "nil" keyword) is done in a way that can be used by any type, not just Optionals (nil for pattern matching specifically evaluates to a stdlib type called _OptionalNilComparisonType which implements the ~= operator so it can be compared against any Optional in a switch, and you could do the same for other ADTs too, assuming they have a reasonable definition for nil).

Re: Go vs. Swift [pdf]

#60

Post by eridius »

solidsnack9000 wrote: post #54
jakerockland wrote: post #52

Earlier quoted context omitted.

This is one of the things I have marked as an issue to elaborate a bit more on. https://github.com/jakerockland/go-vs-swift/issues/8 Thanks for the link! :)

The two differences that I wonder about: * What is the cost profile of Dispatch relative to the Go scheduler? It seems that Go programs suffer a slow down just to enable multi-threading, for example -- which is not unlike other systems (GHC at some time in the past) that have a similar model. * Is Dispatch suitable for "millions of threads" ala Erlang? Hundreds of thousands of threads? Dispatch allows you to decide w…

AIUI Dispatch is suitable for potentially hundreds of thousands of queues. It doesn't spin up thousands of actual OS threads, instead it intelligently manages a pool of OS threads and multiplexes the queues onto them. IIRC each dispatch queue is around 100-200 bytes in size (while empty).
Post reply on HN