montyedwards

Not disagreeing with you or the postmortem, but:

1. that post is from Feb 8, 2016

2. nanomsg 1.0 was released on June 10, 2016

After nanomsg 1.0 release, recent activity on github includes:

8 days ago -- fixes #828 Add logical connections to UDP RFC

9 days ago -- fixes #827 nanomsg zerotier mapping rfc errors

11 days ago -- fixes #825 Extra tests in pipe.c gdamore committed 11 days ago

15 days ago -- fixes #800 accept4 not implemented on all systems

15 days ago -- fixes #783 WS transport - not connectable from Firefox

16 days ago -- fixes #821 NN_WS_HANDSHAKE_CRLF is silly

And etc.

No idea when LibreSSL will add X25519 or X448, as defined in RFC 7748 - Elliptic Curves for Security.

Here's RFC 7748 https://tools.ietf.org/html/rfc7748

Here's the errata for RFC 7748 https://www.rfc-editor.org/errata_search.php?rfc=7748

I'm currently evaluating LibreSSL for use in data protection software I licensed to a large company.

The optional libtls API bundled with LibreSSL is a really simple wrapper API that is secure by default. And it was a breeze to build on Windows because they use cmake (just need to download released bundle rather than from git to avoid problems.) A couple of the optional libtls functions don't work on Windows (tls_load_file), but 100% of OpenSSL-1.0.1+ api functions I tried so far worked fine.

For me, the biggest downside is LibreSSL doesn't support X25519 yet, while BoringSSL and OpenSSL both support it. And BoringSSL is starting to get easier to use with other software like nginx without messy patches.

Hopefully, X25519 will be added as a beta feature during LibreSSL 2.5.x and released as stable in 2.6.

If you have time, take a look at https://github.com/libressl-portable/openbsd

And email patches to: [email protected]

Edited: tls_load_file instead of tls_read

Swift is good for enterprises that standardized on Macs and ios devices, but there aren't many of those (yet).

I'm pretty sure Swift isn't ready on Windows, which is a shame because most "enterprises" standardized on Microsoft Windows and Active Directory.

Go (golang) has better support for a wider variety of platforms, but it has serious bugs on non-Linux platforms (as of go 1.7.1) that make it unsuitable for the enterprise. Basically, whatever customized Linux distro used at Google will likely get the most time from superstars on the go team. Also, calling C functions and callbacks from C can cause all sorts of issues, and the "cgo isn't go" mantra scares me when considering Windows desktops, etc. as a target platform.

C++ is making a comeback and I like C++14, but backwards compatibility and other factors make it too complex compared to other languages. But at least it supports all the major platforms and there's no worry it'll drop support for one due to vendor politics.

Rust looks promising from a cross-platform perspective like C++, but Rust is still way too new for the enterprise just like Swift. Perhaps in five years, it'll stand a chance in the enterprise (as much as C++) and without the complex baggage from inheriting decades of backward compatibility.

Who knows what'll happen by the time Swift or Rust is considered enterprise ready and truly cross platform -- maybe in 5 years, there will be a cross-platform native compiled F# that doesn't heavily favor one vendor's platform or nim might skyrocket out of obscurity -- who knows, but its fun to imagine and do some coding to make the future brighter.

Nobody is suggesting OpenBSD not being RedHat should be embarrassing.

However, it is not ideal to have a security-focused OS not directly provide binpatches for the base system and core libraries like libressl. Trusting OpenBSD.org is one thing, but trusting additional entities like mtier, etc. just to get security updates without having to compile is another.

FWIW, I think we should feel embarrassed about not giving more funding & time to OpenBSD given everything they already do for us.

http://www.openbsdfoundation.org/campaign2016.html

Maybe someone at OpenBSD Foundation should get itself listed at smile.amazon.com and make it even easier for people to contribute.

Anyone interested in using ECC should take a glance at SafeCurves: choosing safe curves for elliptic-curve cryptography http://safecurves.cr.yp.to/

There's a nice table showing which curves are safe and which curves are not.

Rust has:

- Static typing

- Type inference (and pattern matching)

- No dependency on JVM, .NET, or BEAM

But the number of web frameworks, etc. for Rust sucks compared to that of older languages like Go. Go 1.0 was released in early 2012 and Rust 1.0 in May 2015.

Rust is more verbose than Go, but Go's FFI to functions written in C isn't as efficient and since "cgo isn't go", I'm not sure cgo covered by Go 1.0 compatibility guarantee.

On the other hand, Go has tons of "batteries included" plus web frameworks so that is pretty awesome to have on stable platforms (I don't consider Windows a stable platform for Go and got burned several times, but Go works great on FreeBSD & Ubuntu.)

I suspect Go & Swift won't have robust reliability on Windows (compared to other platforms) but they'll be rock solid on the ones they favor. Rust may have better prospects regarding this, but Rust still too new this year for web server language -- wait until MIR is integrated and a couple more releases after that.

Servo would be more compelling for use with commercial software if had MIT or Apache license. The MPL isn't as bad as GPL but still isn't as generous to the developer as MIT or Apache. With the right license, Servo would be a slam dunk for replacing CEF in commercial software that prohibits reversing or tampering.

I understand, but none of those links are the .NET Core 1.0 release announcements.

And the download page for .NET Core 1.0 doesn't mention FreeBSD at https://www.microsoft.com/net/download#core

I don't see mention of FreeBSD anywhere in the .NET Core 1.0 announcements -- has official support for FreeBSD dropped or been postponed?

I don't see downloads for FreeBSD. CoreCLR (.NET Core) mentions FreeBSD at github, but nothing from Microsoft's announement of RC2.

The Go programming language doesn't compile to C. Compiling Go is faster than compiling C.

If Go transpiled into C code first, and then had to compile resulting C code, then that entire process would be slower.

The Nim programming language compiles to C, so you may want to reach out and ask their community. It used to be called Nimrod, but is now Nim.

The Rust programming language leverages LLVM instead of transpiling to C, so you may want to take a look at how that is done. A recent post about Rust MIR is well-written and is an enjoyable read for anyone interested in compilers.

I'd use OpenBSD if it provided:

1. significantly faster vioscsi(4) driver for VirtIO SCSI adapters -- I can live with vioscsi being up to 2x slower than Ubuntu or FreeBSD, but 5x - 10x slower is probably a deal breaker for some other folks that would like to use OpenBSD on Digital Ocean, Linode, etc.

2. binpatches directly from OpenBSD, similar to the way a third-party is providing them at https://stable.mtier.org/

Other than that, really love OpenBSD and even their man pages are awesome.

I tried TDM-GCC.

In my experience, certain aspects increase risks when using go:

1. go is buggier for Windows than Linux and FreeBSD, even though they are all "first class" platforms in go.

2. cgo is also buggier for Windows than Linux and FreeBSD. cgo is not go, as Rob Pike said, so this is listed separately.

3. 386 was buggier than x64, at least in go 1.2 to 1.3 on Windows. I wish I could ignore 386 and XP but I cannot.

So if a project includes all of the above aspects, well...it wasn't a good outcome for me, so I ended up sticking with C and C++ on Windows for non-hobby software.

However, I've been very happy with go 1.4.3 + cgo + x64 on FreeBSD 10 and will probably update to go 1.6 or 1.7 within a year.

Regarding go on Windows, I'm hoping to see go-sqlite3 issue #272 resolved: https://github.com/mattn/go-sqlite3/issues/272

And go issue #14397 cmd/link, runtime: panic "invalid spdelta" with -ldflags="-linkmode internal"

And go issue #10776 cmd/link: windows cgo executables missing some DWARF information

And go issue #12516 runtime: throw in linked c++ library causes app crash even if caught, on windows platform

And so on...

I really love using go (with cgo) on non-Windows platforms, but I can't see this combo being useful on Windows for mission critical projects for a while. There's so much more to go than the language itself and switching gears to use other languages that don't offer that is painful.

Maybe LXSS.sys will eventually make this irrelevant -- at least for companies that migrate from older versions to Windows 10 or to a non-Windows OS.

The only thing preventing me from using Go on Windows is lack of production quality cgo on Windows x86 and x64.

For example, using external linking should "just work" with recent versions of sqlite3 but it fails on Windows.