3 ms·

I wonder how many times we'll impl tls, http 2, aes, etc or how many times we'll leverage libs with C ffi. I'm not sure about Swift's CSP support, but I'm begin

I wonder how many times we'll impl tls, http 2, aes, etc or how many times we'll leverage libs with C ffi. I'm not sure about Swift's CSP support, but I'm beginning to think translating Go everywhere, except for some of the core (or other asm-level pieces like constant time byte array actions) that may be language specific, may be a better way to open up tons of libs for use. It's a fairly simple and unchanging source language. I know Haxe has these kinds of goals, but I figure the ecosystem is weaker.

Spartan-S63 8y ago
I don't see Go as a panacea for opening up libraries for use. You're still going to see languages that can export C interfaces for that. It's going to be C, C++, and Rust that are likely to persist as the languages of choice for massively consumable libraries. As long as they can export a C interface, you can get low (or no) overhead interop. Go's biggest disadvantage is that it ships by default with a runtime. I hope I'm understanding your comment correctly.
- bigdubs 8y ago
  C interop can introduce a lot of complexity in the build toolchain. It's nice to have native versions of libraries like this, vs. relying on compiling c/c++/rust versions.
- kodablah 8y ago
  I meant translate the actual Go code to Swift code so it's pure Swift, but the effort to implement the algorithm right is removed. But yes, to support Go's features you will need at least a GC. Once Rust gets async/await down and people run with it, a static lib in Rust w/ an exported C interface might instead be the norm. But in the meantime, it's annoying that the options are to either reuse a complicated/unsafe C/C++ impl or re-impl in each language individually. Go has a terrible C export story with lots of limitations and impedance mismatches so that's not a great approach imo (granted it's what gomobile does iirc).
  - Spartan-S63 8y ago
    Ah, I understand now. Yes, translating from a Go implementation to a Swift one would erase most of the complexity of reimplementing the algorithm (in a potentially error prone way). I agree that once Rust lands async/await and it matures, it could be the go-to for safe, cross-platform libraries. That's my hope, too. I'm selfishly a Rust evangelist.
- pjmlp 8y ago
  On Windows we have better interop story via COM/UWP or .NET. On Android the interop story is Java and on the Web it is going to be either JavaScript or WebAssembly.
brainzap 8y ago
I started using the Go source code to look up how to implement X.
MaxBarraclough 8y ago
> I wonder how many times we'll impl tls, http 2, aes, etc Well, they're not really for production, are they? For production, shouldn't we all be using the fastest, best-tested implementation, presumably in either C or assembly?

Spartan-S63 8y ago

I don't see Go as a panacea for opening up libraries for use. You're still going to see languages that can export C interfaces for that. It's going to be C, C++, and Rust that are likely to persist as the languages of choice for massively consumable libraries. As long as they can export a C interface, you can get low (or no) overhead interop. Go's biggest disadvantage is that it ships by default with a runtime. I hope I'm understanding your comment correctly.

bigdubs 8y ago
C interop can introduce a lot of complexity in the build toolchain. It's nice to have native versions of libraries like this, vs. relying on compiling c/c++/rust versions.
kodablah 8y ago
I meant translate the actual Go code to Swift code so it's pure Swift, but the effort to implement the algorithm right is removed. But yes, to support Go's features you will need at least a GC. Once Rust gets async/await down and people run with it, a static lib in Rust w/ an exported C interface might instead be the norm. But in the meantime, it's annoying that the options are to either reuse a complicated/unsafe C/C++ impl or re-impl in each language individually. Go has a terrible C export story with lots of limitations and impedance mismatches so that's not a great approach imo (granted it's what gomobile does iirc).
- Spartan-S63 8y ago
  Ah, I understand now. Yes, translating from a Go implementation to a Swift one would erase most of the complexity of reimplementing the algorithm (in a potentially error prone way). I agree that once Rust lands async/await and it matures, it could be the go-to for safe, cross-platform libraries. That's my hope, too. I'm selfishly a Rust evangelist.
pjmlp 8y ago
On Windows we have better interop story via COM/UWP or .NET. On Android the interop story is Java and on the Web it is going to be either JavaScript or WebAssembly.

brainzap 8y ago

I started using the Go source code to look up how to implement X.

MaxBarraclough 8y ago

> I wonder how many times we'll impl tls, http 2, aes, etc Well, they're not really for production, are they? For production, shouldn't we all be using the fastest, best-tested implementation, presumably in either C or assembly?