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

[ssokolow]

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.

Matter of taste indeed. I rarely use rustfmt because, even when making use of nightly-only config options, it's clearly written by people with taller monitors than mine and it's not enjoyable to get everything committed, run rustfmt, and then cherry-pick the lines I agree with and revert the rest using git gui.

If the reverse were true and Rust forced { onto its own line, I'd write a preprocessor and integrate it into my just build task.

[kpedersen]

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...

The fact that GC's cannot be made 100% portable (they always have to make some assumptions on the platform) just doesn't sit right with me. It means that Go as an embedded language will always be relatively 2nd tier.

Yes, I understand there are technical benefits to GCs (such as freeing in large batches, etc) however I also prefer something a little bit more mechanical and deterministic. GCs also make inevitable binding to C awkward because you need to pin memory etc.

Also, like I said, they have a fantastic team there; I kinda just wish they came up with something a bit more innovative and different for the memory management. Something a bit more "Plan 9"

[Lycanthropist]

Yes, I understand there are technical benefits to GCs (such as freeing in large batches, etc) however I also prefer something a little bit more mechanical and deterministic. GCs also make inevitable binding to C awkward because you need to pin memory etc.

Same here. I very much prefer the deterministic nature of reference counting (like the smart pointers in C++ or Rust).

[bug77]

The fact that GC's cannot be made 100% portable (they always have to make some assumptions on the platform) just doesn't sit right with me. It means that Go as an embedded language will always be relatively 2nd tier.

Yes, I understand there are technical benefits to GCs (such as freeing in large batches, etc) however I also prefer something a little bit more mechanical and deterministic. GCs also make inevitable binding to C awkward because you need to pin memory etc.

Also, like I said, they have a fantastic team there; I kinda just wish they came up with something a bit more innovative and different for the memory management. Something a bit more "Plan 9"

Well, Go isn't meant for embedded. Go is simply meant to give you the productivity of Python and the performance of Java. And it does that really well.
It can be used on embedded, but using the wrong tool for a job is nothing new

[Michael_S]

Well, Go isn't meant for embedded. Go is simply meant to give you the productivity of Python and the performance of Java. And it does that really well.
It can be used on embedded, but using the wrong tool for a job is nothing new

Embedded doesn't mean the same thing 15 years ago that it does today. If you're trying to do something useful on an Arduino, Go doesn't work. But a Raspberry Pi Zero will run Go just fine.

[bug77]

Embedded doesn't mean the same thing 15 years ago that it does today. If you're trying to do something useful on an Arduino, Go doesn't work. But a Raspberry Pi Zero will run Go just fine.

Fair enough, but I don't think kpedersen was talking about RPi Zero.
Also, "work" is a big word. We had Java "working" on a first gen RPi (single core). If you didn't mind waiting 3 minutes for it to start up

[Michael_S]

Fair enough, but I don't think kpedersen was talking about RPi Zero.
Also, "work" is a big word. We had Java "working" on a first gen RPi (single core). If you didn't mind waiting 3 minutes for it to start up

Ouch - yeah, sounds unpleasant.

You probably know this, but for long-running processing tasks Java matches Go most of the time. But Java has a crazy heavy amount of startup overhead in disk reads, memory requirements, and CPU work relative to most other languages, even Perl or Python have much lighter startup overhead. On my desktop class machine:

"Hello World" in Go executes in 0.001 seconds and has max resident memory of 1.6MB.
"Hello World" in Java executes in 0.050 seconds and has max resident memory of 28.7MB.
"Hello World" in Perl executes in 0.002 seconds and has max resident memory of 5.0MB.

If I was running a web server, that startup difference between Go and Java wouldn't factor in the decision. But I suspect on a Raspberry Pi Zero a lot of small Go applications in sequence would finish before the first Java equivalent was finished starting. Perl might even be more practical than Java, depending upon what you're doing on the low resource machine.

[bug77]

Ouch - yeah, sounds unpleasant.

You probably know this, but for long-running processing tasks Java matches Go most of the time. But Java has a crazy heavy amount of startup overhead in disk reads, memory requirements, and CPU work relative to most other languages, even Perl or Python have much lighter startup overhead. On my desktop class machine:

"Hello World" in Go executes in 0.001 seconds and has max resident memory of 1.6MB.
"Hello World" in Java executes in 0.050 seconds and has max resident memory of 28.7MB.
"Hello World" in Perl executes in 0.002 seconds and has max resident memory of 5.0MB.

If I was running a web server, that startup difference between Go and Java wouldn't factor in the decision. But I suspect on a Raspberry Pi Zero a lot of small Go applications in sequence would finish before the first Java equivalent was finished starting. Perl might even be more practical than Java, depending upon what you're doing on the low resource machine.

Hehe, our app started in 3 minutes only because we started it in client mode (we added spring, drools and few other things in there for good measure). So no jitting everything at startup, thus the performance struggled for "a bit" more than 3 minutes.
So yeah, the right tool for the job is not just an expression...

[Michael_S]

Hehe, our app started in 3 minutes only because we started it in client mode (we added spring, drools and few other things in there for good measure). So no jitting everything at startup, thus the performance struggled for "a bit" more than 3 minutes.
So yeah, the right tool for the job is not just an expression...

Why would you run Drools on a Pi? What would you do with it? Just curious.

[bug77]

Why would you run Drools on a Pi? What would you do with it? Just curious.

It was introduced to get rod of some spaghetti code... And it was used for event processing.