Re: [dev] Let's talk about Go, baby

From: Ciprian Dorin Craciun <ciprian.craciun_AT_gmail.com>
Date: Sat, 26 Jan 2019 23:34:12 +0200

On Sat, Jan 26, 2019 at 9:46 PM Anselm Garbe <garbeam_AT_gmail.com> wrote:
> > What are your concerns about Rust?
>
> The language itself is certainly better than C++ or Java and avoided
> many mistakes (like exceptions and going to far with OO). On the other
> hand the typesystem isn't great and much more complex than golang's
> approach.


Although I follow this mailing list from the "shadows", I would like
to contribute on the topic of Go and Rust as "saner" programming
language alternatives.

First of all I've programmed both in Go and Rust and, if I need a
"native" executable, I can say this:
* I'll resort to Go if it's a prototype / one-off project or if it is
heavily concurrent; (although if I can get away with a Python script
I'll do that;)
* on the other hand I'll look towards or Rust if the project is more
"involved" (i.e. more complex, or with high-performance requirements),
but not too concurent;
* I would never resort to C++ (which can easily be replaced by Rust);
* I would skip C if it doesn't require too much OS-related
interaction; in fact if I do need OS interaction, Rust is a better
alternative than Go, due to Go's goroutine runtime which, as a
previous poster noticed, doesn't play nice with the standard C
library;


On the other hand comparing the two languages (as in syntax and
features) is not enough; one has to look at their ecosystem, better
said the tooling, documentation, and third-party libraries (and
dependency management tooling).

I would like to touch especially on the third-party libraries and
dependency management:
* Go's approach (until lately) was, how to put it, "non-existent";
you would have a `src` folder where you've let `go get` checkout your
dependencies at whatever version their `master` branch was at, hoping
for the "best"; **there is no concept of version** (therefore there
are a lot of competing "vendoring" tools;)
* Rust's on the other hand went the Java / NPM / Ruby / Python way in
providing a centralized repository, explicit versions, explicit
dependencies, etc.;

All in all, each has its strengths and weaknesses, and I would say
Go's approach better resembles the UNIX world in which you'll have to
maintain a coherent development environment. However in the current
development landscape (with frequent chances) I am always amazed how
the whole things still works...
(For example in Go, I'm yet to find a good way to fork a library,
patch it, publish it under my own GitHub account, and still be able to
use it without changing all the imports to the "forked" location...)


Regarding the type systems you can't actually compare them: Go is to
Rust, as C is to C++.
(However please take into account that I've developed a large-ish (for
a single person) Rust-based project and **never** had a segmentation
fault / null-pointer-exception. I can't say the same about Go.)


And lastly there is a hidden pitfall with Go, which Rust solves it
"better", in the case of high-performance use-cases: heap-based
allocation of what "seems" to be a stack-based allocation (especially
in the case of buffers).

Go's compiler tries its best to use stack-based allocation, however it
throws the towel whenever it encounters a interface. For example say
you want to implement a simple tool that computes the
cryptographic-hash for the input stream. You'll just use the `Hash`
interface, declare a buffer of "enough" size, and loop through
read-hash. Unfortunately because we use the `Hash` interface Go's
compiler can't keep the buffer on stack, but instead it allocates it
on the heap. However one allocation is not that bad, unless you've
decided to declare the buffer inside the loop (just before the read),
instead of outside the loop; in the former case you'll end up with as
many allocations as there are iterations... In Rust on the other
hand, being explicit about allocation, you don't have to "hunt" for
such places in your code.

(The previous is not a "made-up" story. I encountered this in a real
project which involved writing a high-performance HTTP server in Go...
The solution let's say was not that pretty...)




> Besides this it's the hipster environment of Rust that is putting me
> off.


I am truly curious what contributes to this "hipster" perception?
(I myself find that the old web site was "better" than the current
"color-fest" site... However if you look past that I find it quite
"serious looking", or at least as "serious" as Go's ecosystem...)



> the main ideas that resulted into Go
> are clearly footprints of Bell Labs.


Sometimes I would say that perhaps in Go there is too much "Bell Labs"
heritage... (For example the `Dial` function name... What's wrong
with `Connect`?)



> In Rust I do miss this influence
> -- there seems more influence in Rust from the 'functional'
> programming folks - which have also worsened Java dramatically since
> the Java 6 days (lambdas, weird container/collection programming
> paradigms etc.).


I do acknowledge that sometimes "functional pipelines" seem more
closely to badly written Perl code; however I do miss (in Go) the
ability to `v.map(|x| x*2)`...



> When looking at Rusts' experiemtal features such as future, intrinsics
> etc. I have the feeling that adopting it might lead to a big regret in
> the mid term, which is why I would stay away ;)


Indeed Rust (as a language) seems to become larger and larger with
each new release. Even as it stands today it is a daunting task to
learn, and indeed it took me more time to learn Rust than Go.

On the other hand, a plus on its side, Go seems to invest more in
tooling and libraries than in language features.



Thus my bottom line about the two would be: I like them both (perhaps
Rust a little bit more), but each has it's own use-cases which don't
overlap much.



And being on the subject of programming languages, I understand why
this community dislikes (initially I wrote "hates") Java / Python /
Ruby / PHP / etc., my take being that they don't fit the main
use-cases of this community. However I am yet to find a large
"enterprise-ish" / user-interacting system written in C / Go / Rust;
and in fact at the moment if I were to start a large "enterprise-ish"
project (especially of the "book-keeping" kind) I would choose Java
without a regret...

Moreover, last week I've played with HHVM (Facebook's PHP execution
environment), and I would say that in this configuration (i.e. HHVM as
the "PHP execution environment") and with simple PHP code (without
frameworks which try to mimic Ruby's Rails) the result could be quite
"suckless" and UNIX-y in nature.

BTW, does one know of a "suckless" CGI HTTP server? (Perhaps written
in Go?) :)
(And `Caddy` doesn't fit the bill as it has almost everything but it's
own TCP/IP stack and file-system...)

Ciprian.
Received on Sat Jan 26 2019 - 22:34:12 CET