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

11–20 of 128 posts

Re: Go vs. Swift [pdf]

#11

Post by untog »

ajmurmann wrote: post #9
yvsong wrote: post #3

Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration. Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifi…

Agreed. I don't use the GUI tools much (I prefer to manually construct stuff, I know, I know...) and XCode has been just awful to work with. Random crashes, freezing while debugging... in the most recent version I can't view log outputs of a process I attach to, and if I try to take a screenshot from the iOS Simulator it immediately crashes.

Re: Go vs. Swift [pdf]

#13

Post by zomgbbq »

bsaul wrote: post #10
yvsong wrote: post #3

Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

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 hear this argument a lot that it's not production ready but my personal experience does not agree. I use Swift in production for several apps with relatively large codebases that sustain many hundreds of thousands of sessions per day. I would agree that a full clean/rebuild is not as fast as Objective-C and that the incremental build system sometimes seem as though it is compiling more files than you'd like. However, for most part the incremental build system is fine and in daily use it is not a problem. I could never imagine going back to writing objective-C again when I compare the net gains we've realized coding in Swift. The readability and succinctness of the language, as well as catching bugs at compile-time rather than run-time, is a huge benefit. Value-based programming, functional(-ish) programming, and protocol extensions have made my code so much easier to maintain and test, as well.

Re: Go vs. Swift [pdf]

#14

Post by jksmith »

ajmurmann wrote: post #9
yvsong wrote: post #3

Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

I never understand the praise for XCode. I love the iOS specific features like GUI creator out property explorer. But the text editor part is just awful compared to anything else I've used (primarily JetBrains IDEs, but also vim, sublime and some atom). On top of that it also has comparatively poor git integration. Edit: one thing I forgot is the very slow feedback at least when editing Swift. For syntax error notifi…

Yeah agree. While I've moved on, IMHO xcode was generally crap compared to dev envs I used back in the friggin 90's, like Delphi or Topspeed. Not many on HN know much about Delphi, but it set the gold standard for the desktop IDE.

Great thing about Go is you don't need much of an IDE because it's best to just keep Go in its sweet spot, which is services. LiteIDE works great for Go- small footprint,debugging, enough project management to get by. Just like with everything else about Go, you can get a newbie dev going with the Go toolchain actually producing something that works in hardly any time.

Re: Go vs. Swift [pdf]

#15

Post by cwbrandsma »

bsaul wrote: post #10
yvsong wrote: post #3

Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.

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.

But are those issues with Swift or with XCode? XCode is a known piece of crap that does not play well with teams. And XCode isn't any more stable with ObjectiveC than it is with Swift.

Re: Go vs. Swift [pdf]

#16

Post by wyager »

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 whenever a function returns one.

There's another ADT, usually called "Either" or "Result", that allows you to shift exceptions to the type level. You can see from the type of the function what kind of exception it might return, and you deal with exceptions like any other value instead of via a special exception handling mechanism.

Re: Go vs. Swift [pdf]

#17

Post by austinz »

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 supports ADTs and implements its Optional type as an ADT.

Re: Go vs. Swift [pdf]

#18

Post by melling »

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.

Re: Go vs. Swift [pdf]

#19

Post by mahyarm »

zomgbbq wrote: post #13
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 hear this argument a lot that it's not production ready but my personal experience does not agree. I use Swift in production for several apps with relatively large codebases that sustain many hundreds of thousands of sessions per day. I would agree that a full clean/rebuild is not as fast as Objective-C and that the incremental build system sometimes seem as though it is compiling more files than you'd like. Howeve…

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, Linked In, etc.

Re: Go vs. Swift [pdf]

#20

Post by ridiculous_fish »

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…

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 with pure ADTs. It's a similar story for Swift's syntax-level error handling vs type-level monadic error handling. (The downside of course is that the compiler has to be specially taught about these - but maybe you want that anyways, e.g. for Rust's null-pointer optimization.)

Post reply on HN