What's new in Swift 4.1 | Hacker News Reader

What's new in Swift 4.1

hackingwithswift.com

84 pointsOberstKrueger57 comments

Is this used outside the Apple eco-system much? I admit I haven't looked at Swift in 2 years or more.

I find the omission of features like namespaces really strange. I realize that namespaces don't jive with how Obj-C and Obj-C frameworks see the world and that Swift and Obj-C need to play together, but dealing with global namespace pollution and collisions in 2018 just seems...sad? They're hobbling the language in various ways due to NS*/Cocoa framework stuff.

Another weird omission is lack of any kind of concurrency story. Right now, this just seems like Apple's "me-too" version of Java/C#, but what does it actually bring to the table that would make it a worth-while investment if I'm not an iOS developer?

Most Swift code is divided nicely up into modules, which are compiled together and have their own namespace. https://developer.apple.com/library/content/documentation/Sw...

For some reasons most of the swift code I've seen doesn't use any namespace/prefix when it calls various functions from different "modules". It's used just like C "include"

You only have to qualify what module something is from if it would otherwise be ambiguous.

> Another weird omission is lack of any kind of concurrency story

Grand Central Dispatch (GCD or libdispatch) is generally the concurrency story on Darwin platforms. There has been an ongoing effort to port it to Linux. Not sure how complete that is but I linked the Github below. Swift on Linux still has a lot of rough edges in general.

https://developer.apple.com/documentation/dispatch

https://github.com/apple/swift-corelibs-libdispatch

It's quite complete. Cross-platform Server-Side Swift systems like Kitura use it to do things like multi-threaded HTTP serving.

I imagine if you tried hard enough you could find edge cases that work on macOS but not on Linux, but the Linux support is complete enough for everyday production work.

Hey that's fantastic. It's admittedly been a while (6-12 months) since I've tried to run any non trivial Swift code on Linux.

A good read on the future of Swift concurrency is this from Chris Lattner, https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9.... I think currently still slated for Swift 5

This is going to be very interesting to watch. They decided to add concurrency after having built an extraordinary complex language. Something people like rob pike thought would be very hard to do (and as both a go and a swift coder, i must say i tend to think he's probably got a point).

The concurrency model was planned before the first betas but has been delayed. The devs always knew how they wanted concurrency to work.

I didn't know that, but i'm not surprised because chris lattner clearly knows what he's doing. I'm still curious to see how it ends up integrating in a language that's been evolving a lot since its design.

Saying that they managed to keep concurrency orthogonal to the rest of the language means Rob Pike was "wrong" (or at least what i understood from his point).

However, after reading the conversations around the async proposal, it seems to me on the contrary that it is very tightly related to other parts (such as error throwing mechanism, GCD library and syntax in general).

We'll see. I wish i didn't have the feeling swift core team is understaffed, because at least for iOS development it is really a joy to program with.

gcd still doesn't enable you to properly create mutexes or the equivalent of @synchronized.

Concurrency is still a work in progress in swift, in the most fundamental levels.

    let mutex = DispatchQueue(label: “”)
    mutex.sync { /* protected code here */ }

As for @sychronized, the devs have talked about why it is flawed (requires double locking) and why use should always use a manual mutex scope.

Creating a closure and scheduling it on a queue seems like a pretty heavyweight way to ensure exclusive access (see https://www.cocoawithlove.com/blog/2016/06/02/threads-and-mu... for more).

EDIT: aren't you the one that wrote this article ? :))

An enum with no cases works pretty well as a namespace.

I mean, sure, there are work-arounds I guess. Still weird to rely on work-arounds like this. Also, there are at least 4 different workarounds to this, so imagine working on a large code base where everyone has their preferred approach is...fun. Or it would have been fun in '98 or so, nowadays, for a brand new language - it's just sad.

I can think of three: enum, class, and struct. What’s the fourth? And what’s the big deal if you encounter some code that uses a different one?

Why can't we have just one way of declaring and naming namespaces using something called... namespaces ?

There are probably goos reasons for doing it this way, but it always feels weird having to declare all your namespace's types inside one of its member.

If you allow nesting things inside types, then those act as namespaces, so you’ll always have multiple ways even if one of those ways is explicitly called “namespace.”

I agree the language should have it, but it doesn’t seem like a particularly big deal.

Urgh. Why do stuff like this on a newly designed language? I mean, that sounds like javascript from ten years ago, and I didn't think anyone would like to go back there.

Swift has module-level namespaces and recommends lots of little modules.

in practice "lots of little modules" means something like 10 before your app start time starts to increase dangerously.

This is from 2016 -- Swift and the toolchain has gotten dramatically faster since then, but this is a comparison of server-side swift frameworks with Rails/Laravel/Spring/Nancy/etc: https://medium.com/@qutheory/server-side-swift-vs-the-other-...

...and part 2 here: https://medium.com/@qutheory/server-side-swift-vs-the-other-...

And here's summer 2017 benchmarking/comparing server side Swift frameworks vs. Node: https://medium.com/@rymcol/updated-benchmarks-for-the-top-se...

Swift is a great language.

Hello World in Java:

public class HelloWorld {

    public static void main(String[] args) {
        // Prints "Hello, World" to the terminal window.
        System.out.println("Hello, World");
    }

}

Hello World in Swift:

print("Hello World")

Obviously Hello World is trivial, however that comparison is indicative of the elegance -- it has power similar to C with ease of use similar to scripting languages.

Swift is a terrible language. While the Hello World example seems to show its simplicity, when you actually need to write useful code it’s the opposite of simple. Unnecessary things like var, func, and the terribly named let clutter up the code. Then there is the backwards variable decoration. Oh and the random use of punctuation which makes reading confusing.

In the end, Swift is terrible. If you are developing on MacOS, stick with Objective-C. It’s a much better language.

> what does it actually bring to the table that would make it a worth-while investment if I'm not an iOS developer?

If you're not a Mac or iOS developer, then it doesn't bring anything right now.

IMO, nobody is going to use this cross platform. Some people are trying to make it happen, but I doubt very much that it's going to be popular.

> If you're not a Mac or iOS developer, then it doesn't bring anything right now.

Well… in the sense that it is Yet Another Programming Language, you're right in some regard. Nonetheless…

> IMO, nobody is going to use this cross platform. Some people are trying to make it happen, but I doubt very much that it's going to be popular.

Those "some people" include IBM, who are behind the Kitura framework and are also porting Swift to their heavy PowerPC iron. They seem to be trying to make it into sort of a next-generation Java without the terribleness.

Yeah, it still maybe won't catch on as broadly as Java did, but it already has some enterprisey support outside of Apple. We'll see.

> Those "some people" include IBM...

Never heard of them or used any of their software products. What other popular software have they brought to market?

This is great news for developers who use Apple products.

I'm happy they're trying to improve the cross-platform story but I'm not sure I could ever completely trust the ecosystem when it's so tightly bound to MacOS/iOS (standard library still not complete, 3rd party libraries may only work or be well tested on Apple platforms, new features may take time to land on other platforms.)

> standard library still not complete

Define "complete." I would say if you count the Foundation library - which ships with Swift - as part of the standard library, things are pretty darn complete.

> new features may take time to land on other platforms

Not as far as Swift itself is concerned. Ever since Swift went OSS, new releases land for Linux and macOS at the same time.

Is there already NSURLSession (or Swift's equivalent) for Linux?

Yes, and there has been for a while now.

However, (as you might already know, since you chose the NSURLSession example), it's not 100% feature-complete when compared to the macOS or iOS version.

Here's one example of where you have to do (or at least, I had to do on 2017-07-12)

    #if !os(Linux)

to account for platform differences:

https://github.com/soracom/soracom-sdk-swift/blob/master/Sou...

You will encounter that kind of thing from time to time if you use Swift and Foundation on Linux.

Still, the Foundation library is highly usable on Linux, and is vastly ahead of where I expected they would be by now when they announced it. But there are still some things that are not implemented.

They actually do have a good status page about this topic specifically: https://github.com/apple/swift-corelibs-foundation/blob/mast...

There is a significant amount of functionality in Foundation unavailable on other platforms:

https://github.com/apple/swift-corelibs-foundation/blob/mast...

Numbers-wise, yes. Day-to-day-usage-without-a-trivial-workaround-wise, no.

I hope it becomes great news for all developers. Swift is a dream to work with. It's certainly the closest compiled language I've used to the English language.

conditional conformance is a game changer.

What is it?

The ability to state that a type only conforms to a protocol if its generic parameters satisfy certain bounds. https://swift.org/blog/conditional-conformance/

It let’s you say that e.g. two arrays are equatable if their elements are equatable.

Does that exist in other languages, a quick look doesn't show up anything for python/c++

It might be possible in C++, with some template meta-programing love.

It makes no sense in Python as it's a static typing feature. It makes limited sense for C++ as its generics are structural rather than nominative, though I believe Concepts will (eventually) introduce constrained templates: http://en.cppreference.com/w/cpp/language/constraints [0]

It does already exists in other languages e.g. Haskell or Rust. For instance in Rust Vec's implementation of Eq is defined thus:

    impl Eq for Vec<T> where T: Eq {}

So Eq is implemented on Vec<T> if and only if T implements Eq.

Haskell is similar:

    instance (Eq a) => Eq [a] where (…)

the bit before the "=>" is the constraint.

[0] in current C++, you'd just define an `==` operator on your type, and it would blow up with obscure errors if you tried applying it incorrectly e.g. vector already overrides operator==, if you use it with a type which does not override == you get a few pages of templates garbage (287 lines in g++) boiling down to "==(vector<T>, vector<U>)" requires ==(T, U) but I couldn't find that definition. You can try it live with this (requires C++11):

    #include <iostream>
    #include <vector>

    struct S {
      uint8_t a;
      //bool operator==(const S& other) const {
      //  return this->a == other.a;
      //}
    };

    int main() {
      std::vector<struct S> v1 = { { 3 } };
      std::vector<struct S> v2 = { { 4 } };
      bool r = v1 == v2;
      std::cout << r << std::endl;
    }

uncomment the operator== definition and it'll compile.

Dunno about python (but then again it's a dynamic language...), and it's been an endless discussion for c++ AFAIK.

Other than that it's actually rather common in statically typed languages (except Go ;P). From the top of my head e.g. Java, C#, Typescript, Kotlin, Rust, Haskell all offer constraints for generics.

Add CLU, Eiffel, BETA, Sather, ML to that list. :)

I think your comment is a bit… not sure what the word is, under-appreciating the feature? Over-selling some languages?

Because AFAIK Java (or C#?) does not have constrained interface conformance, it only has bounds on functions (which Swift already had). That is you can say

    static <T extends Comparable<? super T>> void sort(MyList<T> list)

such that you can only sort lists of comparables, but you can't say

    class MyList implements Comparable<T extends Comparable<? super T>>

such that MyList implements comparable IIF its items are comparable.

Agh, yes. I already regret putting Java in that list with its wonky implementation. :)

But it certainly works with others, e.g. something like this:

    public class SortedList<T> : ICollection<T>,IEnumerable<T> where T : IComparable<T>

Is that C#? So it does have optional interface implementation? TIL.

Huh? I'm not sure where you're getting at.

I'm only asking if the snippet you posted is C# or something else, and noting that if it's C# I have learned something new about the language.

Except now that I look at it more specifically, it looks like a bound on the class's generic parameter rather than a condition on the interface implementation?

As in you're defining a SortedList class which implements ICollection and IEnumerable but requires T:IComparable, not defining a SortedList class which implements IEnumerable if T is IComparable.

And if that reading is correct, Java can do it just fine:

    class SortedList<T extends Comparable<T>> implements Collection<T>, Iterable<T>

however it's got nothing to do with conditional conformance.

It is in Rust:

    impl<T> Codable for Array<T> where T: Codable {}

Also synthesized implementations are known in Rust as auto derive (#[derive(Eq, Hash)]).

It's nice to see Swift and Rust agree on such features.

Implementing conditional conformances alone removed a lot of duplicate code from the standard library. I always like to think that the amount of gyb[^1] files in the source code is a good indicator of how far Swift is in its development.

[1]: gyb, a template processor, is a workaround for features that the standard library needs, but that are not (completely) implemented yet.

Can anyone explain whats the reasoning behind renaming flatMap?

The SEP makes it pretty clear: https://github.com/apple/swift-evolution/blob/master/proposa...

Basically, they did not rename flatMap they renamed one specific overload:

    Sequence.flatMap<U>(_: (Element) -> U?) -> [U]

or in Haskell parlance

     mapMaybe :: (a -> Maybe b) -> [a] -> [b]

which filters after mapping more than it flattens (in fact the Rust and OCaml versions are called filter_map). The issue is that due to Optional promotion you could misuse flatMap (where you should have used map I guess) and could get this filtering behaviour unexpectedly instead of the straightforward mapping you would be expecting (it also led to extra branches and optional wrappings and unwrappings).

"things that didn't work before will now"

Just the words I want to hear when I upgrade my programming language by one minor version.

This is in relation to conditional conformance though, and very reasonable in that context.

You are taking something out of context and commenting just to be snarky. This is not a case that you commonly use:

var left: [String?] = ["Andrew", "Lizzie", "Sophie"]

var right: [String?] = ["Charlotte", "Paul", "John"]

left == right

This works fine, for example:

var left: [String] = ["Andrew", "Lizzie", "Sophie"]

var right: [String] = ["Charlotte", "Paul", "John"]

left == right

> Just the words I want to hear when I upgrade my programming language by one minor version

New features are not a breaking change? It will not affect any currently compiling programs.

Also, as others have stated, that is quite a bit out of context.

> Just the words I want to hear when I upgrade my programming language by one minor version.

Would you prefer hearing "We didn't fix anything in this update"?

Reply on news.ycombinator.com