News for hackers. Stuff that matters.
Re:A Proposal for Package Versioning in Go by ngrilly on Wednesday March 28, 2018 @05:13AM (#16696440)
You're right about the issue I mentioned which is irrelevant since there is no overloading in Go. Thanks for pointing it out.

I didn't know you worked on Rust and now on Swift :-)

What strategy does Swift use to compile a generic function or method? Does it generate only one polymorphic version of the code, or multiple specialized versions for each expected parameter types (often called code specialization or monomorphization)?

Re:A Proposal for Package Versioning in Go by dbaupp on Wednesday March 28, 2018 @05:57AM (#16696577)
One polymorphic version, like OCaml or Haskell, not specializing like C++ or Rust.

The compiler can and does specialize functions as an optimization, but that's not necessary nor part of the semantic model.

Re:A Proposal for Package Versioning in Go by ngrilly on Wednesday March 28, 2018 @07:30AM (#16696887)
I always thought that generating one polymorphic version would be a better fit for Go than generating multiple specialized versions.

It's interesting that Swift adopted this approach and confirms what you said earlier about Swift having essentially the same constraints as Go and being a good source of inspiration of Go.

What's the status of Swift on Linux, to write web services and connect to databases?

Re:A Proposal for Package Versioning in Go by dbaupp on Wednesday March 28, 2018 @08:25AM (#16697139)
There's lots of testing for Swift on Linux (e.g. every pull request runs tests on macOS and Linux), and Apple recently announced https://github.com/apple/swift-nio which seems to have been very well received, e.g. the Vapor framework is completely switching to it for Vapor 3.
Re:A Proposal for Package Versioning in Go by ngrilly on Wednesday March 28, 2018 @09:00AM (#16697331)
Thanks for the link. Does Swift provide something similar to goroutines?