Live data from Hacker News

Go vs. Swift [pdf]

github.com

61–70 of 128 posts

Re: Go vs. Swift [pdf]

#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't do any better than that it would once and for all put an end to this stupid benchmark.

Re: Go vs. Swift [pdf]

#64
post #62

It's not true that Go requires import "fmt" to print something.

I have a note about that:

> Note that Go does support a ‘println’ function that does not require import- ing from the standard library; however, this function reports to ‘stderr’, rather than ‘stdout’, and is not guaranteed to stay in the language 19.

Re: Go vs. Swift [pdf]

#65

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…

Java has optional support, yes. However it lacks elvis operator "?." which actually makes code much clearer.

Re: Go vs. Swift [pdf]

#66
post #13
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…

I like Swift but incremental builds are very much broken on Xcode 8 and have been for a while: https://forums.developer.apple.com/thread/62737

This leads to very long compile times for even simple one line changes.

Re: Go vs. Swift [pdf]

#67

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…

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)

Re: Go vs. Swift [pdf]

#68

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 nearest analogue to swift in the android ecosystem is kotlin - give it a look if you haven't.

Re: Go vs. Swift [pdf]

#69
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…

I'm not sure it should be Apples job to build a best-in-class text editor. I haven't used XCode in a long while, but last time I did it worked pretty well with external text editors, and you could configure the UI in a way that really facilitated using it just for just compiling/debugging.

Every single IDE I've used, I've always used another text editor for doing actual programming. It's nice to have a half-decent text editor in the IDE for debugging (see value of variables in the code, looking up and quickly fixing compile errors, etc).. but I don't expect it to be as powerful as vim, emacs, sublime, et.al.

Re: Go vs. Swift [pdf]

#70

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.

[deleted]
Post reply on HN