
Swift vs. Go - supster
https://sapan.svbtle.com/swift-vs-go
======
pkaler
The list doesn't mention optionals in Swift. Optionals are a substitute for
nil/NULL and handle the absence of a value in a type-safe manner. It is
similar to the Maybe type in Haskell.

(BTW, if you're interested in Swift, I send a weekly newsletter at
[http://swiftnews.co](http://swiftnews.co))

~~~
supster
Good catch, I added it to the list

~~~
catnaroek
Optionals aren't a “functional concept”, whatever that means. They're just
another data type, like tuples, lists, trees, etc.

~~~
supster
Actually they are a special type of Monad which is a functional programming
concept (see Haskell).

~~~
catnaroek
Yes, and lists [not necessarily linked lists] could have a Monad instance too.
Does this make lists a “functional concept”?

------
r0fls
Is Swift a general purpose language? I thought it was for iOS and Mac
development. I understand it is open source, but so is C#, and I don't see a
lot of people using that outside of Windows (I could be wrong though).

~~~
mikeash
I think C# is pretty a pretty common cross-platform language for games due to
Unity's support for it. It's not common for other apps, though.

I don't think there's much cross-platform work being done in Swift yet. Give
it a little time, though, it's only been open sourced for a few months.

One nice thing about it compared to many other languages is that it can use C
APIs with almost no work. There's no need to screw around with annoying FFI
systems, you just point the compiler at your C headers and the calls become
available in Swift. They may not be very idiomatic Swift, but they're at least
no more difficult to use in Swift than they are in C. That means that you
don't necessarily need a bunch of Swift libraries to be built before you can
start getting stuff done.

------
halosghost
> inferred strong static typing

“strong” compared to what? Go's duck-typing actually makes it weaker than a
lot more type systems than you might expect, and compared to something like
Haskell or Rust, both of these type systems are incredibly weak. If you're
comparing to C, then sure, but “strong” and “weak” typing mean nothing without
reference to another language.

~~~
supster
In this context, strong as compared to Ruby/Python/Javascript

~~~
whitegrape
Seems odd to lump Python (which is pretty strongly typed) with Ruby and
JavaScript (JS especially not being strong). Edit: Actually this whole thread
makes it seem like we all have our own different definitions on what makes
something "strongly typed" (or just confusion with strong and static). For
myself, a language's type system's relative strength is all about how it
handles (or doesn't handle) implicit type conversions.

~~~
halosghost
This is roughly my point.

“Strong” and “Weak” are inherently relative terms; so, when used without a
reference point, they will mean something different to different people. So,
without a point of reference, the terms are not useful.

~~~
whitegrape
Even being inherently relative, you still need to determine the underlying
values with some metric (like implicit type conversions, or max deadlift). If
you tell me someone's max deadlift is twice their bodyweight, that tells me
they're strong, even if it doesn't tell me their relative strength compared to
say Sigmarsson. If someone says "Language X generally forces you to be
explicit with your type conversions" that tells me it's strongly typed. Is it
more strongly typed than language Y? That depends on explicitness exceptions
-- e.g. Java does implicit autoboxing and toString()ing when you're doing
string concatenation, Go effectively type aliases primitives so that e.g.
net.IP can implicitly convert to []byte, Python complains when you don't
explicitly call str() on things but converts numbers pretty freely (like auto-
converting to a bignum, whereas other languages might throw an exception or
automatically and silently wrap-around to a much smaller number than
expected).

~~~
catnaroek
“Strong typing” doesn't mean anything when comparing languages. The difference
between raising a `TypeError` at runtime or silently doing something wrong is
entirely a matter of standard library design. For example, you can replace
Python's built-in lists with your own list class that is as “weakly typed” as
you want. But, from the point of view of _programming languages_ , the only
thing that matters is that an unwanted situation couldn't be ruled out by the
language itself.

------
stcredzero
I just got out of a work presentation on new features in C++11 and C++14. The
two presenters went into what's apparently the standard debate about noexcept.
This makes me appreciate Go's pragmatic decision not to have exceptions! When
you start getting into the nitty-gritty and epiphenomena around implementing
APIs, multiple return values with error codes looks pretty darn good.

Error codes are explicit and devoid of implicit automagic. You're not going to
break a lot of contracts and alter semantics by adding a keyword. The error
codes are explicitly part of your function signature, in the most stupidly
straightforward way possible. If you're going to be a bad developer and ignore
error codes, this is going to appear explicitly in your code. (As opposed to
being rewarded with "cleaner" code when you sweep exceptions under the rug.)

~~~
dllthomas
_" multiple return values with error codes looks pretty darn good"_

I'm a fan of making errors explicit, but I continue to find the use of
effectively a product type (value _and_ error) to return what is actually a
sum type (value _or_ error) to be ugly and error prone. Ideally, invalid
states should be unrepresentable. In this case, both "value and error" and "no
value and no error" are not. This is not good design.

~~~
stcredzero
_Ideally, invalid states should be unrepresentable._

And clearly any language in which invalid states are representable is useless?
Nice try, but nah. I like me some pure functions sometimes, but I'm not
dogmatic about it.

~~~
dllthomas
Your response is so bad I almost think you're trolling... Hoping (I think)
not:

 _" And clearly any language in which invalid states are representable is
useless?"_

I did not call anything useless, much less the entire language.

And I am the first to agree that trade-offs need to be made between a variety
of considerations. But in this case, _for the approach under discussion_ , I
pointed out a design criteria that I find often important, that this approach
is in _flagrant_ violation of, while getting basically (perhaps literally)
nothing in return toward any other design considerations.

Either I missed things or that's just a bad decision. If you think it's the
former, please engage me more constructively so that at least one of us can
learn something.

 _" Nice try, but nah."_

This is needlessly rude.

 _" I like me some pure functions sometimes"_

This issue has _zero_ to do with pure functions.

 _" but I'm not dogmatic about it."_

Right, pointing out bad design can only come from a place of dogma. Never
experience, never consideration, and never anything that could permit
substantive discussion.

------
Apocryphon
Would Kotlin be a better comparison to Swift, given they've both got huge
potential for writing mobile apps?

~~~
gman83
Kotlin doesn't have a big backer though. I could see Google adopting Kotlin
for Android officially in which case it could really take off.

------
pbnjay
I'd argue optionals are just a variation of Go's interfaces (e.g. io.Reader
versus io.ReadCloser)... and enums are basically typed constants in Go (you
just don't see the name "enum" anywhere).

~~~
TheHydroImpulse
Optionals can't be expressed safely in Go. They have a type of `Option<T>` or
`Maybe<T>`. Swift just has this notion built as an operator.

Traditional enums aren't particularly interesting. What languages like Rust
and Swift have are tagged unions. They let you associate data with each
variant.

Moreover, pattern matching is needed to use tagged unions effectively.

Constants are not "basically" tagged unions or even enums. They are not
grouped into a parent type. For example, if you have a `Foo` enum with `A` and
`B` variants; while matching or accepting this, you can accept a `Foo` which
is guaranteed to be either `A` or `B`.

How would Go typed constants achieve this?

------
jorgecastillo
>I hope they take a look at Swift as it matures in the next few years.

Maybe when binary packages are available for non Ubuntu Linuxes?

~~~
lovelettr
I think that is a valid concern. It is something that is being worked on [1]
by the community. When those things get reasonably stable I think then it will
be time to get those packages accepted by their respective distros.

Though as pointed out in SR-116 without ABI stability (which will not appear
until Swift 3) packages do not necessarily provide a silver bullet of
portability.

I for one have been maintaining a PKGBUILD script for Arch Linux that allows
for a native package to be created. It's currently not working due to some
issues with binutils [2].

[1]
[https://bugs.swift.org/browse/SR-116](https://bugs.swift.org/browse/SR-116)
[2]
[https://bugs.swift.org/browse/SR-1023](https://bugs.swift.org/browse/SR-1023)

------
pcwalton
It's important to not only take compilation speed but also code quality into
account. Swift and Go made very different tradeoffs here with SIL+LLVM
compared to Plan 9.

~~~
oofabz
I think Go hoped GCC would be their high-performance compiler, but it never
got the attention it needed.

GCC has better micro-optimization in gccgo, but the compiler lacks important
features like escape analysis and an up-to-date runtime so it's slower on
real-world code.

~~~
pcwalton
Yeah, it goes to show that you really want a mid-level language-specific IR
(which is what the Plan 9-based compilers have) if your language is at all
high level.

I think the ideal for best performance of generated code is 3 IRs: a mid-level
language-specific IR for high-level optimizations (especially around memory
management and devirtualization), a low-level IR for lower-level optimizations
(e.g. algebraic simplifications), and a codegen IR (for instruction selection
and scheduling). This is what Swift is doing, as far as I can tell.

------
vram22
Only looked at Swift a little so far, but liked something about the syntax.

Seems clean.

Going to check it out more over time. Hope the Linux support improves.

------
ngrilly
What do you mean by "scripting mode"?

------
sdegutis
Off topic rant about Svbtle: While browsing the article, I hovered my mouse
over something, which told me to hold still, and then suddenly it gave the
article an irreversible upvote, which I certainly never intended to give. Now
that poor author thinks another person liked the article. Who knows, maybe all
previous 12 upvotes were the same situation?

Can we go back to Web 1.0 please? Everything was simple, everything worked,
everything was _fast_. Or at least can we compromise and have a few reasonable
design choices from Web 2.0 and Web 3.0 merged back in with Web 1.0, and just
go with that? The current Web is just too broken, but there's nowhere to file
a bug report.

~~~
krapp
>Can we go back to Web 1.0 please? Everything was simple, everything worked,
everything was fast.

No. Software is allowed to evolve, even if you don't like it.

>Or at least can we compromise and have a few reasonable design choices from
Web 2.0 and Web 3.0 merged back in with Web 1.0, and just go with that?

No. People are allowed to make their own decisions about how to design and
build their sites, and they have the freedom to make decisions you disagree
with.

>The current Web is just too broken, but there's nowhere to file a bug report.

It's broken for you, but it's extremely entitled of you to declare it broken
for everyone. Far, far more people would consider "revert to Web 1.0" to be a
broken experience, and the web belongs as much to them as it does to you.

~~~
stcredzero
_> >Can we go back to Web 1.0 please? Everything was simple, everything
worked, everything was fast._

 _> No. Software is allowed to evolve, even if you don't like it._

Translation: Programmer Hubris is a constant.

~~~
krapp
Perhaps. But if it means the internet brings me a far richer set of
experiences and possibilities than simple text and images can allow then I'm
not going to complain about it.

