I'm confused as to why this piece was written using LaTeX.
I'm sure we'll see a 'Go vs LaTeX' post before the day is done...
Go vs. Swift [pdf]
61–70 of 128 posts
Re: Go vs. Swift [pdf]
#62Re: Go vs. Swift [pdf]
#63I 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]
#64It's not true that Go requires import "fmt" to print something.
> 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]
#65The 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…
Re: Go vs. Swift [pdf]
#66Earlier 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…
This leads to very long compile times for even simple one line changes.
Re: Go vs. Swift [pdf]
#67Earlier 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…
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]
#68The 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.
Re: Go vs. Swift [pdf]
#69Swift: 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…
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]
#70The 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.