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

81–90 of 128 posts

Re: Go vs. Swift [pdf]

#81

Post by steedsofwar »

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…

Coming from an IntelliJ background, one thing that irks me the most when using XCode is: i need to click on the red dot symbol to see the error. For the love of God, just display the error, why do i need to move my hand away from the keyboard to the mouse. It just annoys me enough to lose my coding mojo.

Re: Go vs. Swift [pdf]

#82

Post by bad_user »

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…

> `5 == Just 5` fails. But in Swift this works like you would want

Why in the world would you want those two to be equal when they obviously don't represent the same thing?

That doesn't make sense, not even if they have the exact same memory representation, in which case I'm pretty sure it has been a compromise, which would mean you're still dealing with `null` with some lipstick on it, making that type behave inconsistently with other types in the language.

This kind of misguided convenience is exactly why equality tests in most languages are in general a clusterfuck.

Re: Go vs. Swift [pdf]

#83

Post by hardwaresofton »

pawadu wrote: post #73
hardwaresofton wrote: post #72

Earlier quoted context omitted.

The author notes here (in the HN thread) that it's a very very cursory overview and there are plans to add more later given time. This could have been a blog post (or series of blog posts), so maybe the academic-paper feel was misleading. While I'm not sure this content should be on the front page, it never was represented as a very deep comparison. I do admit that when I read it through I expected much more. Also, h…

> I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. Up to a certain point, stars can be useful as it helps you discover projects other people have found of use. But saying project X is better than project Y because it has more stars? What does it show other than more people using X are on github or people using X a more prone to push the star button? For reference…

Oh I definitely am not trying to imply you should use a project just because it has more stars -- maybe the right term was "hype" instead of word-of-mouth

Re: Go vs. Swift [pdf]

#84

Post by rimantas »

mahyarm wrote: post #19
zomgbbq wrote: post #13

Earlier quoted context omitted.

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

You worked with source of both, Uber and Lyft? And Linkdin too?

Re: Go vs. Swift [pdf]

#85

Post by rimantas »

danielparks wrote: post #55

Go feels like a beefed up version of C. Swift feels like a high level language with static typing. Interestingly, Swift doesn't feel much like Obj-C.

  > Interestingly, Swift doesn't feel much like Obj-C.
Not necesarrily a bad thing. However I am the one who does like Obj-C. That said after some time with Swift you do not really want to go back to Ojbective C any more.

Re: Go vs. Swift [pdf]

#86

Post by 35bge57dtjku »

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.

People have known about Optionals being better for decades.

Re: Go vs. Swift [pdf]

#87

Post by coldcode »

cwbrandsma wrote: post #15
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.

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.

Mostly Xcode, but issues with compilation speed in the Swift compiler also means some of the problems are harder to pinpoint the issues.

Re: Go vs. Swift [pdf]

#88

Post by coldcode »

I use Swift every day and appreciate it a lot, while I have only cursory experience in Go, mostly because it didn't have any real debugger support in the past. But any comparison is rather shallow because at the moment they don't really address the same target usage, and Swift is only minimally supported on the server side where Go is generally used. Give it a couple years and the comparison might be more meaningful.

Once Jetbrains Gogland is up and running I will be playing more with Go.

Re: Go vs. Swift [pdf]

#89

Post by criddell »

chmike wrote: post #74

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent…

> I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance.

I work in C++ and still use inheritance (although I generally prefer composition). One advantage over composition is that it's less typing. For example, if I'm using public inheritance to express a is-a relationship between a base and derived class, all of the public methods of the base are available without having to implement a method in the derived class that just forwards the call to the base class.

Re: Go vs. Swift [pdf]

#90

Post by seertaak »

criddell wrote: post #89
chmike wrote: post #74

I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent…

> I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance. I work in C++ and still use inheritance (although I generally prefer composition). One advantage over composition is that it's less typing. For example, if I'm using public inheritance to express a is-a relationship between a base a…

My understanding is that Go provides for this by a mechanism called embedding. You can place an object i:Inner in class c:Outer and then Outer acquires all of Inner's public interface.

I think it's a nice idea. In general, Go seems to provide the language mechanism without the "moral" aspect. In other words, it saves you typing without forcing you to accept the OO paradigm (Liskov substituion etc.).

Post reply on HN