Go 1.13 Released With TLS 1.3, Illumos, Unicode 11 & Other Fun

[phoronix]

Phoronix: Go 1.13 Released With TLS 1.3, Illumos, Unicode 11 & Other Fun

Go 1.13 was released today as Google's latest update to their language and run-time/toolchain...

http://www.phoronix.com/scan.php?page=news_item&px=Golang-1.13-Released

[Jabberwocky]

I welcome hexadecimal and imaginary literals! Still looking forward to [u]int128 support.

[Space Heater]

Did Joyent help with the official Illumos support? I don't know of any other active supporters of illumos in 2019.

[kpedersen]

Go 1.13 now requires macOS 10.11 El Capitan or later; support for previous versions has been discontinued.

Go 1.13 now requires FreeBSD 11.2 or later; support for previous versions has been discontinued. FreeBSD 12.0 or later requires a kernel with the COMPAT_FREEBSD11 option set (this is the default).

Why is Go so unmaintainable? How is it that C++ (GCC, Clang) and Rust, etc, are quite trivial to backport but Go isn't? Does it have inflexible back end? Hopefully it is just a lack of man-power rather than technical problems.

I like Go, it has a good legacy from the original AT&T / Bell Labs guys (though I think they went a bad route with their garbage collection memory management. They could have done better here).

[squash]

Why is Go so unmaintainable? How is it that C++ (GCC, Clang) and Rust, etc, are quite trivial to backport but Go isn't? Does it have inflexible back end? Hopefully it is just a lack of man-power rather than technical problems.

I like Go, it has a good legacy from the original AT&T / Bell Labs guys (though I think they went a bad route with their garbage collection memory management. They could have done better here).

Go has a history of dropping support for operating systems that are no longer supported by their vendors.

FreeBSD 11 ended support this month.
El Capitan ended support in August of 2018

Previously, support for WinXP was dropped in Go 1.10, and Win2k support was dropped in 1.3. Older OSX versions have been losing support over time as well.

You may find that a newer release still works on an old operating system, however it is no longer validated for it and bugs are generally not accepted if they only affect unsupported operating systems, but in some cases they rely on a feature not available in the old version.

GCC has a different idea but they also remove obsolete operating systems and architectures. For example, gcc 9 removed Solaris 10.

Also, their GC is first rate, I"m not sure what you're getting at there. It's extremely fast and has an absurdly small impact on running programs...

[bug77]

Go has a history of dropping support for operating systems that are no longer supported by their vendors.

FreeBSD 11 ended support this month.
El Capitan ended support in August of 2018

Previously, support for WinXP was dropped in Go 1.10, and Win2k support was dropped in 1.3. Older OSX versions have been losing support over time as well.

You may find that a newer release still works on an old operating system, however it is no longer validated for it and bugs are generally not accepted if they only affect unsupported operating systems, but in some cases they rely on a feature not available in the old version.

GCC has a different idea but they also remove obsolete operating systems and architectures. For example, gcc 9 removed Solaris 10.

Also, their GC is first rate, I"m not sure what you're getting at there. It's extremely fast and has an absurdly small impact on running programs...

What he said. Plus Apple is fantastic at updating their hardware, El Capitan is probably running on a handful of Macbooks these days.
I would add a language so young benefits from focus while getting up to speed instead of trying to chase everything. (We tried doing that at a startup once, you've probably never heard of us as a result )

[ssokolow]

Why is Go so unmaintainable? How is it that C++ (GCC, Clang) and Rust, etc, are quite trivial to backport but Go isn't? Does it have inflexible back end? Hopefully it is just a lack of man-power rather than technical problems.

I like Go, it has a good legacy from the original AT&T / Bell Labs guys (though I think they went a bad route with their garbage collection memory management. They could have done better here).

Probably because they go to great lengths to avoid depending on libc (which can lead to really messy bugs when assumptions don't quite line up).

Rust, by contrast, intentionally uses libc as a platform abstraction to make it easier to maintain and port.

[Michael_S]

Also, their GC is first rate, I"m not sure what you're getting at there. It's extremely fast and has an absurdly small impact on running programs...

I'm probably missing some other language runtimes, but as far as I know the work on the Java Virtual Machine G1, ZGC, and Shenandoah garbage collectors and the Go garbage collector are pushing the envelope for efficient production garbage collectors. I'm not aware of other languages that use all of the efficiency and performance tricks they do.

[re:fi.64]

Hmm, not sure how I feel about the error wrapping yet. I feel like errors.Wrap{,f} was harder to screw up / had slightly better compile time safety.

[Lycanthropist]

I don't like about Go that you can't put the '{' on a new line. In my opinion, this doesn't look very nice and as far as I know there is no technical reason for that. I prefer C++ or Rust in that regard.