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

71–80 of 128 posts

Re: Go vs. Swift [pdf]

#71

Post by stickfigure »

ninjaroar wrote: post #67
hardwaresofton wrote: post #51

Earlier quoted context omitted.

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

Checked exceptions also forces thinking critically about failure modes, but they seem to be an unpopular language feature, and few new libraries seem to use them. No other popular language has adopted them. Why are optionals good and checked exceptions bad? (I'm certainly not implying that one replaces the other - i'm just saying that it they both have an origin of forcing programmers to think about errors)

Because checked exceptions are incompatible with the idea of standard interfaces. You can't use interfaces like List, Iterable, Runnable, etc in a world with checked exceptions; you'd have to declare special versions of each of those interfaces for every possible exceptional condition. Since we need standard interfaces to let modules work together, everyone ends up catching and wrapping checked exceptions in runtime exceptions. Any potential value is lost.

Exceptions are exceptional; the whole point is that you aren't supposed to have to think of them in normal program flow. Go gets this wrong too, forcing three extra lines of if err != null { for pretty much every single function call -- and with the added bonus of destroying stack context with each return.

Re: Go vs. Swift [pdf]

#72

Post by hardwaresofton »

pawadu wrote: post #63

I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can…

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, how do you determine what libraries to use and what projects to invest in these days? Do you always do a full audit of every project? I know I don't have the time, so I use stars on a Github project just like one might use word-of-mouth. If a ton of people think a thing is useful, it's probably at least a little useful. Of course, that kind of thinking can be dangerous (see: javascript ecosystem), but a lot of the time, it's "good enough".

BTW, the paper does cover a tiny bit of information regarding differences in platform support when it covers how Swift deals with concurrency.

Re: Go vs. Swift [pdf]

#73

Post by pawadu »

hardwaresofton wrote: post #72
pawadu wrote: post #63

I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can…

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, bootstrap has 100K stars, Linux has 40K...

Re: Go vs. Swift [pdf]

#74

Post by chmike »

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 without all the complications on C++ and that most OO oriented languages forbid because of that complication.

Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis.

To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that with Go programming is fun again. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.

Re: Go vs. Swift [pdf]

#75

Post by interpol_p »

edblarney wrote: post #58
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?

Optionals being clumsy means you start to eliminate them as you write more Swift. It becomes a carefully considered decision to use an optional in your interface. And the compiler keeps you in line.

I love the compile-time optional support now and severely miss it when using languages that don't have the feature. They are brilliant when you are working with all-Swift code or Objective-C code that has been decorated with nullability keywords.

However optionals become a burden when you are working with old Objective-C code that has not been annotated.

Re: Go vs. Swift [pdf]

#77

Post by claudiug »

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…

`Go programming is fun again` I found this expression really difficult to accept it :) Ruby, Python are languages that are quite fun for me.

Also, `Go is a very original language in this aspect as well as with concurrency` CSP is quite old also.

Dlang, is quite a nice and easy to start language, If I will compare d vs go, I will say that you can see that golang has a lot of money and people behind. And, after I wrote more than a simple library, I tend to be tired of some parts of the language decision, and is not about interface, is just the small stuff. But again, I tend to write code that is more OOP :)

Please excuse me if my reply offend you, that is just my personal opinion after work with golang few years ago

Re: Go vs. Swift [pdf]

#78

Post by perryprog »

pawadu wrote: post #63

I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]? I would rather see a discussion about performance, platform support, maintainability, governance and do on. --- [1] someone please create a new programming language where the empty file means "print hello world". Since you can…

Well... there is stuck....

https://stuck.readthedocs.io/en/latest/

Re: Go vs. Swift [pdf]

#79

Post by masklinn »

edblarney wrote: post #58
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?

Optionals should be used sparingly in de-novo Swift code, as the corresponding features (Option/Maybe types) are in other languages (Haskell, Elm, OCaml, Rust, …): only make something an Optional if, well, it's actually optional.

Optionals have lots of syntactic sugar because Swift has to deal with reams of native and objective-c code which is ubiquitously nullable, dealing with that without the syntactic sugar would be nothing short of horrendous. This is also an issue with ported/converted API (which is most of them at this point) as the underlying system tends to leverage nullability extensively (it's a very common Obj-C pattern as nil is a message sink), which is usually left shining through by simple conversion rather than wrap every historical API in a converted Swift version.

Re: Go vs. Swift [pdf]

#80

Post by bad_user »

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…

OOP is primarily about polymorphism (subtyping) and encapsulation, code reuse by means of inheritance is just a nice to have, so that comparison doesn't make sense.

You can compare OOP with parametric polymorphism, you can compare it with type-classes. Heck, OOP isn't necessarily about subtyping and we could be talking about row polymorphism (e.g. OCaml) which has some really nice properties.

> This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication.

Except that it doesn't solve the fundamental problems with OOP, because it's still essentially OOP with subtyping ... and lots of marketing. So coming from Go you can be excused for thinking that the last 30 years of research have been for nothing.

Post reply on HN