You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
561 lines
32 KiB
561 lines
32 KiB
11 months ago
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||
|
|
|
||
|
|
<!-- Enable responsiveness on mobile devices-->
|
||
|
|
<!-- viewport-fit=cover is to support iPhone X rounded corners and notch in landscape-->
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, viewport-fit=cover">
|
||
|
|
|
||
|
|
<title>Julio Biason .Me 4.3</title>
|
||
|
|
|
||
|
|
<!-- CSS -->
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/print.css" media="print">
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/poole.css">
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/hyde.css">
|
||
|
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body class=" ">
|
||
|
|
|
||
|
|
<div class="sidebar">
|
||
|
|
<div class="container sidebar-sticky">
|
||
|
|
<div class="sidebar-about">
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me"><h1>Julio Biason .Me 4.3</h1></a>
|
||
|
|
|
||
|
|
<p class="lead">Old school dev living in a 2.0 dev world</p>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<ul class="sidebar-nav">
|
||
|
|
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/">English</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/pt">Português</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/tags">Tags (EN)</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/pt/tags">Tags (PT)</a></li>
|
||
|
|
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="content container">
|
||
|
|
|
||
|
|
<div class="post">
|
||
|
|
<h1 class="post-title">Why Rust and not Go</h1>
|
||
|
|
<span class="post-date">
|
||
|
|
2019-09-16
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/go/">#go</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/rust/">#rust</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/programming-languages/">#programming languages</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/nitpick/">#nitpick</a>
|
||
|
|
|
||
|
|
</span>
|
||
|
|
<div style="border:1px solid grey; margin:7px; padding: 7px">
|
||
|
|
<p>This is a rebuttal to <a href="https://kristoff.it/blog/why-go-and-not-rust/">Why Go and not
|
||
|
|
Rust?</a>.</p>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
<h1 id="huge-disclaimer">HUGE DISCLAIMER</h1>
|
||
|
|
<p>Before jumping into the discussion, let me put this first: I do write code in
|
||
|
|
Rust (not professionally), I've not written something in Go yet but I keep
|
||
|
|
reading about the language and its ecosystem. I also follow the Rust as a
|
||
|
|
language and its ecosystem.</p>
|
||
|
|
<p>Second, another thing you must know about me: I've been a developer
|
||
|
|
professionally for about 30 years (its no hyperbole here: I did start
|
||
|
|
professionally writing code when I was 12 and didn't leave the field yet).
|
||
|
|
I've written code that run in about 15 different languages, so I have strong
|
||
|
|
opinions about coding after suffering with those languages.</p>
|
||
|
|
<p>Third, I do believe languages do not exist in a vacuum: Besides the language,
|
||
|
|
you have libraries and frameworks; besides the languages and the frameworks,
|
||
|
|
there is dependency control; besides dependency control, there is a community.</p>
|
||
|
|
<p>Fourth, if that's not really clear so far, all this is a matter of opinion --
|
||
|
|
even the original post is, although it doesn't say so.</p>
|
||
|
|
<p>Fifth, yes, I did take things out of order, mostly 'cause I thought some
|
||
|
|
points are scattered around the original text that are complementary.</p>
|
||
|
|
<p>That being said...</p>
|
||
|
|
<h2 id="the-nitpicking">The Nitpicking</h2>
|
||
|
|
<p>(Those are points that just brushed me in the wrong way, but they are not
|
||
|
|
major points and you can really skip this if you don't want to read a bunch of
|
||
|
|
complains.)</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go is fast, but Rust is faster.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>C is even faster. So what?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go has an efficient garbage collector, but Rust has static memory management.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>And so does C and C++. So what?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go has interfaces, but Rust has traits and other zero-cost abstractions</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Well, Go doesn't have interfaces <em>per-se</em>. Their interface is akin to Python
|
||
|
|
"if it has an <code>open()</code>, <code>read()</code> and <code>fseek()</code>, then it's a File-like object",
|
||
|
|
as far as I know. Python even changed that from the "it looks like a
|
||
|
|
file-like" to using the double-dunder functions to fit the interface ("if it
|
||
|
|
has a <code>__len__()</code> method, it is an object with a size").</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go has great support for HTTP and related protocols and it doesn't take long
|
||
|
|
to write a satisfactory web service.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>More satisfactory than <a href="https://palletsprojects.com/p/flask/">Flask</a>, in which
|
||
|
|
you can create a service (a very dumb one, in that) with only 5 lines of code?
|
||
|
|
Does it? Or is it a <em>personal opinion</em>?</p>
|
||
|
|
<p>Honestly, I haven't seen -- even with Rust -- something as dead simple as
|
||
|
|
Flask, so there we have it. If you need performance, one could use
|
||
|
|
<a href="https://github.com/huge-success/sanic">Sanic</a>, which is a uvloop powered
|
||
|
|
server with a syntax that is pretty close to Flask.</p>
|
||
|
|
<p>So, when you say "great support" and "satisfactory" is that a <em>fact</em> or an
|
||
|
|
<em>opinion</em>?</p>
|
||
|
|
<p>Obviously it is an opinion, as much as me saying Flask/Sanic can beat anything
|
||
|
|
Go has, and neither of those are valid for anything. Beauty is in the eye of
|
||
|
|
the beholder.</p>
|
||
|
|
<p>(But if I'm nitpicking, I can throw whatever language I want here.)</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>The creators of Go like to call it a “boring” language.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Weirdly enough, I heard the same thing about Rust. So which one is the
|
||
|
|
"boriest" of them all?</p>
|
||
|
|
<p>This kind of call is akin to the PyPy devs saying that "PyPy is 300% faster
|
||
|
|
than CPython -- for tests written specifically to prove that PyPy is 300% faster
|
||
|
|
than CPython". The same thing can be said here: Go/Rust devs call their
|
||
|
|
language boring 'cause they want to prove their language is boring. Neither is
|
||
|
|
true -- and, weirdly enough, <em>both</em> are true.</p>
|
||
|
|
<p>One could even claim that Python is more boring that Go. <sup class="footnote-reference"><a href="#1">1</a></sup> And Rust, by the
|
||
|
|
way.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>do more with less” has proven to be very successful.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Wait, are you <em>really</em> quoting Dennis Ritchie, in which he was defending C? C
|
||
|
|
has less than Go or Rust, so maybe we should jump back to C? Is that what you
|
||
|
|
mean?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>In truth, none of these things alone is particularly impressive, but they do
|
||
|
|
describe the mindset that Go wants to impose. Many don’t like it but, in my
|
||
|
|
opinion, it’s a killer feature for some types of development, like
|
||
|
|
enterprise software.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>If we point that Rust does exactly what you're saying and <em>better</em> ("enforce"
|
||
|
|
vs "you need to run something, otherwise nothing changes", which I <em>will</em>
|
||
|
|
discuss later in this post<sup class="footnote-reference"><a href="#2">2</a></sup>), then Rust kills Go in enterprise software, right?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Enterprise software always has a big scope.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Yes, and that's why we break this scope -- and some domains and everything
|
||
|
|
else -- into smaller parts that connect to each other. Those are called
|
||
|
|
"microservices" and one thing is that you can write them in whatever, but the
|
||
|
|
scope is always a small one (for different scales of "small") but it won't
|
||
|
|
be something ginourmous like a monolith, in which all the scopes exist in the
|
||
|
|
same place.</p>
|
||
|
|
<p>(I'll make this point again later, but it is weird how the author says one can
|
||
|
|
spin a Go app really fast, but then comes with the sort of points like this
|
||
|
|
that make sense only for monoliths, and I'm not sure which is the real point
|
||
|
|
being pointed in these cases.)</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>To unravel complex domains you need a well-structured process.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>(And then he jumps into discussing about domains and expects and stakeholders)
|
||
|
|
You know what you're talking about? A DSL. You want a DSL to is close to the
|
||
|
|
experts about their domain, you want a DSL so stakeholders can understand
|
||
|
|
what's going on above the code.</p>
|
||
|
|
<p>You want Racket. I've seen things close to this in Rust using macros (which is
|
||
|
|
witchcraft to me) but I'll refrain from saying "Rust has it, and better".</p>
|
||
|
|
<h2 id="the-freaking-cargo-cult">The Freaking Cargo Cult</h2>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go was created at Google to solve Google problems</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>This is something that we, developers, who love and hate <em>any</em> language need
|
||
|
|
to discuss. And it comes in this other point:</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>As I already mentioned, Go was created to solve Google problems, and Google
|
||
|
|
problems are definitely enterprise-scale problems.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>You know who has Google problems? GOOGLE! You know who else has Google
|
||
|
|
problems? NO ONE!</p>
|
||
|
|
<p>No one is a huge search engine that lives capturing peoples data to provide
|
||
|
|
relevant ads (and, sometimes, search results, and shopping lists and
|
||
|
|
whatever).</p>
|
||
|
|
<p>It's the same bullshit people claiming "Netflix has 600+ microservices using
|
||
|
|
Spring, so we should use Spring for our microservices", 'cause you won't have
|
||
|
|
600+ microservices, and most probably none of them are related to providing
|
||
|
|
video streaming.</p>
|
||
|
|
<p>It's the same bullshit people claiming "Amazon deploys a microservice every 11
|
||
|
|
seconds, so we must use microservices too!" 'cause, again, you're not a huge
|
||
|
|
cloud provider with two or three different versions of the same solution.</p>
|
||
|
|
<p>This "Cargo Cult": The idea that if we do the same thing someone else did and
|
||
|
|
it worked, it will work for us too. Enterprises everywhere run Java, for huge
|
||
|
|
scales -- AWS is the first that comes to mind -- but you're not claiming Java
|
||
|
|
can solve "enterprise-scale" problems, are you? The point that you're trying
|
||
|
|
to make here is "worked for Google, will work for you", which is plain wrong.</p>
|
||
|
|
<p>And it doesn't even involve Go or Rust. You're trying to make a point by
|
||
|
|
saying "They use" and that's not a point. <em>At all</em>.</p>
|
||
|
|
<h2 id="the-plain-wrong">The Plain Wrong</h2>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go is also strict about things that other languages are usually more lax about.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Guess you never saw the borrow checker. Or the fact that Rust doesn't allow
|
||
|
|
passing an u32 (unsigned int of 32 bits) as a parameter that requires an u64,
|
||
|
|
even if the later is larger than the former. There is no implicit conversion
|
||
|
|
in Rust and a Rust dev must explicit convert from one type to the other.
|
||
|
|
That's very strict in my opinion, even if you believe this is just an
|
||
|
|
annoyance.</p>
|
||
|
|
<p>You can't have strictness with flexibility. The are opposite points: Either
|
||
|
|
the language is flexible (allowing you to use an u32 in a u64 parameter and
|
||
|
|
doing the conversion to you, for example) or it's very strict (like Rust
|
||
|
|
does).</p>
|
||
|
|
<p>Also, since you're talking about "strictness", let me ask you this: Have the
|
||
|
|
Go core devs fixed this?</p>
|
||
|
|
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>result, err := some_function()
|
||
|
|
</span><span>return result
|
||
|
|
</span></code></pre>
|
||
|
|
<p>What is there to fix? No, it's not the "it should complain that err is never
|
||
|
|
used" (I could replace <code>err</code> with <code>_</code> and the error would still be there). It
|
||
|
|
is <strong>the freaking error treatment</strong>! You can't call a language strict if, in
|
||
|
|
2019, it let this kind of stuff slip by. We learnt, in those last years, that
|
||
|
|
the "not-happy" path happens more often than the happy path. And ignoring such
|
||
|
|
errors is the major cause of headaches we get, and that's why we have those
|
||
|
|
stupid "restart job at midnight" cronjobs or watchdogs that keep checking if
|
||
|
|
the process is running and start it again if it crashes. </p>
|
||
|
|
<p>I can also bring the borrow checker back into this: You see, we don't talk
|
||
|
|
about processor speed anymore these days, we talk about cores. The future (and
|
||
|
|
the present) are multi-thread. I won't deny that launching a concurrent,
|
||
|
|
multi-threaded service in Go is a lot simpler than Rust, but Go doesn't have
|
||
|
|
any validation about the memory usage; it won't prevent you from doing
|
||
|
|
something like sending a structure over a channel and changing that structure
|
||
|
|
<em>in the same thread</em>. So, while Go makes it easier, Rust makes sure you're not
|
||
|
|
shooting yourself in the foot in the long run -- which would require the
|
||
|
|
cronjobs or watchdogs.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go doesn’t want unused variables or imports</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Neither does Rust -- it throws a large, explicative warning right in the
|
||
|
|
middle of your screen -- , so what's the point of this here?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>files belonging to different packages in the same directory</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Hey, do you know that, in Rust, directories <em>are</em> packages, and so you <em>can't</em>
|
||
|
|
put files of different packages in the different directories? In this case,
|
||
|
|
Rust seem more strict than Go, doesn't it?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go also doesn’t want any “fingerprints” in the code, so it enforces a
|
||
|
|
single, universal style via <code>go fmt</code>.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>It doesn't <em>enforce</em> if you have to run this. Rust also have a <code>rustfmt</code>, if
|
||
|
|
that's your point but, besides that, the Rust compiler will complain about
|
||
|
|
things that are not following the coding style. Try to name a variable in
|
||
|
|
camelCase and see what the rust compiler will say.</p>
|
||
|
|
<p>Besides <code>rustfmt</code>, Python has Black (which I hate, but still); before Black,
|
||
|
|
Python have flake8 and pylint, both which would "enforce" the Python style. So
|
||
|
|
this is, again, a moot point.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>The toolchain is very often lousy and/or dated.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>You mean, projects don't have <a href="https://rustup.rs/">rustup</a>, the way Rust has?
|
||
|
|
Crazy!</p>
|
||
|
|
<p>Or even the backwards compatibility, like when Rust changed from the 2015
|
||
|
|
edition to 2018, but you could select which edition (compiler version, AST,
|
||
|
|
and so on) your project would use?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>The Go compiler is fast.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Ah crap, not that shit again.</p>
|
||
|
|
<p>The whole point is "compiler is fast, tests run faster". Well, what if I said
|
||
|
|
the compiler would catch bugs <em>before</em> the tests? That would be even faster,
|
||
|
|
'cause then you can focus your tests on system behaviour, which is way more
|
||
|
|
important than function behaviour or class/structure/module behaviour.</p>
|
||
|
|
<p>We are, once again, discussing <a href="https://www.youtube.com/watch?v=RAxiiRPHS9k">Fast Test, Slow
|
||
|
|
Test</a>, aren't we? Let me write a
|
||
|
|
test for every single function, every single class and oh, look how fast they
|
||
|
|
run, 'cause the compiler is fast! Then we put the "integration tests" in the
|
||
|
|
CI and everybody is happy.</p>
|
||
|
|
<p>Except you wrote tests twice when the only tests that matter are the ones that
|
||
|
|
check the system behaviours.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>With Go, it’s easier as a junior developer to be more productive</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>[Citation needed]. I know this is pretty close a nitpick and I can understand
|
||
|
|
where this is going, but my guess is that, in the long run, when juniors
|
||
|
|
understand why certain snippets don't compile, they can be more productive
|
||
|
|
'cause errors in their code will be caught way earlier in compilation (see
|
||
|
|
point below about types and above about compiler strictness).</p>
|
||
|
|
<p>Also, feel free to call [Citation needed] about my point here too, 'cause we
|
||
|
|
both know we are both pulling data out of our asses.</p>
|
||
|
|
<h2 id="the-somewhat-right">The Somewhat Right</h2>
|
||
|
|
<blockquote>
|
||
|
|
<p>There are a lot of junior developers</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Yes, there are. Also, they are, sadly, not getting that many jobs, 'cause as
|
||
|
|
this point, nobody is hiring juniors. We can go back to the point of "juniors
|
||
|
|
being more productive" and say "Hey, junior dev, if you learn programming
|
||
|
|
language X, you'd get a job, 'cause it's really an easy language" and I'd
|
||
|
|
throw Python here and break your engine.</p>
|
||
|
|
<p>Sure, there <em>may</em> be that Go is simpler than Rust (and I'll outright say that
|
||
|
|
Python <em>is</em> easier than Rust), but we can't say Go is easier than Rust.</p>
|
||
|
|
<p>If I can go into anecdote mode, I could say that I personally find Go code
|
||
|
|
harder to understand than Rust, and no, it's not because I've wrote some Rust
|
||
|
|
code an no code in Go; Go syntax simply does look weird to me, and one can say
|
||
|
|
that is because the order of the languages I learnt. So, for me, it's harder
|
||
|
|
to learn Go due its syntax than it is to learn Rust. <sup class="footnote-reference"><a href="#3">3</a></sup> Does the same apply
|
||
|
|
to junior devs? I'm not sure, but languages are not hard per-se, they may have
|
||
|
|
some weird stuff, but if you describe the building blocks in order, then <em>any</em>
|
||
|
|
language is easy to learn.</p>
|
||
|
|
<p><sup class="footnote-reference"><a href="#4">4</a></sup> Also, let me point out that Rust have an "Ergonomics Working Group" (now
|
||
|
|
simply called <a href="https://github.com/rust-lang/rfcs">"Language Changes RFCs"</a>,
|
||
|
|
which discuss ways to make the language easier to use and there is a whole
|
||
|
|
<a href="https://github.com/rust-lang/rust/labels/WG-compiler-errors">"Compiler Errors Working
|
||
|
|
Group"</a> which
|
||
|
|
discuss how to make the error messages in the compiler easier to understand.
|
||
|
|
With all that, if you junior devs are having issues with the language, they
|
||
|
|
are invited to go there and show the problems they are having with the
|
||
|
|
language -- and the Rust community is really focused on that, and all they
|
||
|
|
need is a Github account, instead of being part of the cabal that decides the
|
||
|
|
changes. Do Go devs have an open, transparent discussion like that?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>This pushes further down technological concerns such as efficiency, and even
|
||
|
|
correctness. Don’t get me wrong, the business does care about correctness,
|
||
|
|
but they have a different definition for it. When you’re thinking about
|
||
|
|
algorithmic correctness, they are thinking about a reconciliation
|
||
|
|
back-office for the operations team they keep in a country where labor is
|
||
|
|
cheap.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Wait, so it is technological but it is not technological? I know, this should
|
||
|
|
be in the nitpick section, but there is another important point here.</p>
|
||
|
|
<p>Thing is, business people do not care about reconciliation; they worry about
|
||
|
|
deliveries and cheap labor <em>and that is</em>. Are they delivering? Are they cheap?
|
||
|
|
Good, case closed. We don't care if there is a problem that will appear in 10
|
||
|
|
months or if they connection is slow between services; it works right now and we
|
||
|
|
saved money right now, so the math is solid.</p>
|
||
|
|
<p>On the other hand, if we are talking about "technological efficiency", you've
|
||
|
|
already said Rust is faster than Go, so it's more efficient (for the level of
|
||
|
|
efficient I want to use to prove that Rust is better than Go -- and I'm being
|
||
|
|
sarcastic here); if we are talking about "technological correctness", we can
|
||
|
|
go down the rabbit hole of Rust types and that, although not close to Haskell
|
||
|
|
types, it forces a good bunch of correctness in your processes. And nothing
|
||
|
|
about Go types (and their correctness) is ever mentioned; wanna guess why?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Software projects quickly become huge and complex for all the wrong reasons.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>I have to agree with this. Yes, software grows beyond maintainability and
|
||
|
|
domains change.</p>
|
||
|
|
<p>On the other hand, we keep pushing microservices in those larger contexts,
|
||
|
|
specially to avoid being stuck in certain domains, 'cause you can just
|
||
|
|
rewrite services (yes, you can) or you break code into different services so
|
||
|
|
they don't go being the maintainability barrier.</p>
|
||
|
|
<p>(This point is also annoying the heck out of me, with the comparison of Go
|
||
|
|
being easy to spin something and then calling monolith problems. Either it is
|
||
|
|
a language consistent to huge deployments, like Java, or it is a language with
|
||
|
|
prospects towards simpler things, like Python. There are drawbacks in both and
|
||
|
|
one can't push towards the to points without breaking everything.)</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go is much easier to learn than Java or C#.</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>Says who? I mean, I don't want to bring the "That's, like, your opinion, man"
|
||
|
|
card again, but I guess one could find a lot more resources about Java or C#
|
||
|
|
than Go.</p>
|
||
|
|
<p>What about Rust? I give that the language is not that easy to pick, but every
|
||
|
|
working group on the Rust community writes their own book, so one could bring
|
||
|
|
those juniors devs into reading the books they will need to use and be done
|
||
|
|
with that.</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>The Go community regards as anti-patterns many abstractions regularly
|
||
|
|
employed by Java / C#</p>
|
||
|
|
</blockquote>
|
||
|
|
<p>And I guess Java and C# regards Go abstraction as anti-patterns too, so what's
|
||
|
|
the point? Any language that has different ways to express abstractions
|
||
|
|
compared to other languages, and they will call the other language
|
||
|
|
abstractions "anti-patterns".</p>
|
||
|
|
<p>Rust will call some Java patterns anti-patterns too and I have to, once again,
|
||
|
|
ask "So what?" Does this makes Rust better than Java if it does? Does it make
|
||
|
|
better than Go if it calls the same Java abstractions "anti-patterns", but has
|
||
|
|
better performance than Go and is more strict than Go?</p>
|
||
|
|
<blockquote>
|
||
|
|
<p>Go is faster than Java</p>
|
||
|
|
</blockquote>
|
||
|
|
<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html">For a very small
|
||
|
|
margin</a>.</p>
|
||
|
|
<p>But I have to pull the <a href="https://en.wikipedia.org/wiki/Moving_the_goalposts">"moving
|
||
|
|
goalpost"</a> card in the
|
||
|
|
blog post here: "Go is simple so that all of this can hold true when
|
||
|
|
confronting the average Go program with the average Java / C# program." So now
|
||
|
|
we are comparing the "average" Go vs the "average" Java/C# (which,
|
||
|
|
surprisingly, are nothing like the "average" Rust program). Except whatever is
|
||
|
|
an "average" Go/Java/C# program is never defined, so we can keep pulling data
|
||
|
|
from our asses and keep saying that the benchmark game isn't valid 'cause the
|
||
|
|
examples are not "average".</p>
|
||
|
|
<p>And whatever I can point as "average", you will point that is not "average",
|
||
|
|
right? That's what a "moving goalpost" means.</p>
|
||
|
|
<p>Oh, you mean, "on all the things, Go is faster". As in "it compiles faster",
|
||
|
|
which we know means nothing, if it doesn't bring the strictness and
|
||
|
|
correctness factors into it (let me write a very fast compiler in Bash that
|
||
|
|
produces code that never runs, but it is <em>fast</em>!); as in "We can fix things
|
||
|
|
faster", in which I can call that Rust is pretty close to Elm, in which "if it
|
||
|
|
compiles, it will run without runtime exceptions", so in actuality, there are
|
||
|
|
less bugs (personal observation, it actually does!).</p>
|
||
|
|
<p>As "average" as in what, actually? As in "whatever point I want to make about
|
||
|
|
Go being better than Java/C#", for absolutely no reason?</p>
|
||
|
|
<h2 id="dropping-all-euphemisms"><sup class="footnote-reference"><a href="#5">5</a></sup> Dropping All Euphemisms</h2>
|
||
|
|
<p>There one point that, if you take the birds-eye view of both posts, is truly
|
||
|
|
being discussed here: TTSIW (Time To See It Working).</p>
|
||
|
|
<p>I'll give it that TTSIW for Go is smaller than Rust, and that seeing something
|
||
|
|
"working" is a huge step in producing serotonin in your system.</p>
|
||
|
|
<p>Rust, with all its checkers and rules and strictness have a larger TTSIW,
|
||
|
|
which may cause the release of glucocorticoid -- the stress hormone.</p>
|
||
|
|
<p>So, the whole point the original post tries to make is "Go gives me
|
||
|
|
serotonin".</p>
|
||
|
|
<p>But after you are in the field for some time, when you have to go back to the
|
||
|
|
office 'cause some service is not working, when you have to stop your leisure
|
||
|
|
time to find out why something is breaking... That's a glucocorticoid release
|
||
|
|
larger than fighting your compiler for 2 hours. In other words: Having to deal
|
||
|
|
with stupid mistakes you left behind 'cause your compiler didn't warn you
|
||
|
|
about them is more stressful than the ones it warned you about, 'cause it is
|
||
|
|
<em>right</em> <em>there</em>, in front of you, when you're building the system.</p>
|
||
|
|
<p>I had a talk with an embedded developer about a month ago. His company was
|
||
|
|
replacing Go applications with Rust, simply because the thing would run for
|
||
|
|
awhile and then crash because there was some lock he should've used and the
|
||
|
|
compiler never told him about it. Replacing with Rust was trading the long
|
||
|
|
term glucocorticoid with a short term glucocorticoid and long term serotonin.</p>
|
||
|
|
<p>And <em>that's</em> what we are talking in those two articles: Do you want a short
|
||
|
|
term pleasure and a long term stress or a short term stress and long term
|
||
|
|
pleasure?</p>
|
||
|
|
<h2 id="the-things-we-don-t-talk-about">The Things We Don't Talk About</h2>
|
||
|
|
<p>There is one important piece that is never discussed: Ecosystem.</p>
|
||
|
|
<p>And no, ecosystem is not simply the number of libraries and packages in the
|
||
|
|
package manager; it is way beyond that: It's about its community and the way
|
||
|
|
the management deals with it.</p>
|
||
|
|
<p>And we have to talk about <code>go dep</code>.</p>
|
||
|
|
<p><code>go dep</code>, the Go dependency tool, is a replacement of the dependency tool
|
||
|
|
created by the community, <code>godep</code>, after a whole year with said community
|
||
|
|
asking for a decent dependency tool, specially compared to the <code>vendor</code>
|
||
|
|
solution. So, without every inquiring the community, the Go core devs decided
|
||
|
|
they know better, made a tool and gave a big "screw you" to the community.</p>
|
||
|
|
<p>Not only that, but just recently the same tool decided to <a href="https://codeengineered.com/blog/2019/go-mod-proxy-psa/">call
|
||
|
|
home</a> by adding a
|
||
|
|
proxy on the call of every package, <em>including your private ones</em>. Why? No
|
||
|
|
real explanation. It simply does. It's not for CDN, 'cause it is just a proxy.
|
||
|
|
It's not for CDN, 'cause other it would require coordination between the
|
||
|
|
package repository and the CDN and none of this is included in this change.
|
||
|
|
Simply, every single install of a package will be captured by Google. For. No.
|
||
|
|
Good. Reason.</p>
|
||
|
|
<p>Not only the situation of the core Go devs going against the wishes of the
|
||
|
|
community, there was even some whisper about forking Go into a community
|
||
|
|
version, so it could run with a core group that would actually <em>listen</em> to the
|
||
|
|
community.</p>
|
||
|
|
<p>And Go is just one year older than Rust. And nobody is saying "Let's fork
|
||
|
|
Rust" -- even if you count <a href="https://twitter.com/withoutboats/">without boats</a>
|
||
|
|
comments about a simpler version of Rust, in which he was talking about
|
||
|
|
<em>another language</em> that would borrow some stuff from Rust, the same way Rust
|
||
|
|
borrowed some stuff from OCaml and other ML languages.</p>
|
||
|
|
<p><a href="https://doc.rust-lang.org/cargo/">Cargo</a> is the Rust counterpart of <code>go dep</code>.
|
||
|
|
Cargo was born in the Rust infancy and it is evolving along the Rust compiler.
|
||
|
|
All discussions about it <a href="https://github.com/rust-lang/cargo/issues/">are done in the
|
||
|
|
open</a> with the community input.
|
||
|
|
Rust itself goes <a href="https://github.com/rust-lang/rust/issues">through the same
|
||
|
|
motions</a> -- and that could be the
|
||
|
|
reason async/await is almost a whole year in the cooking, with discussions
|
||
|
|
about its syntax going through iterations over the issue list.</p>
|
||
|
|
<h1 id="you-have-to-have-a-posture">You Have To Have a Posture</h1>
|
||
|
|
<p>You, the reader, may now be wondering why I brought the <code>go dep</code> discussion
|
||
|
|
into this. You may believe that discussions in the open (and taking longer
|
||
|
|
than they needed) is a big turn off for you 'cause it makes things move
|
||
|
|
slower.</p>
|
||
|
|
<p>But let me ask you this: Which one of those models follow an open source
|
||
|
|
development model? Let's take Mike Hoye, from Mozilla, definition of open
|
||
|
|
source: "I think that openness as a practice – not just code you can fork but
|
||
|
|
the transparency and accessibility of the development process." </p>
|
||
|
|
<p>With that, take a step back and re-read the last point again. Which one of
|
||
|
|
those are really an open project? Is the Go development transparent and
|
||
|
|
accessible?</p>
|
||
|
|
<h1 id="in-closing">In Closing</h1>
|
||
|
|
<p>I have to call the original post completely baloney, mostly 'cause I want this
|
||
|
|
post to end in a lighter mood. I mean, there is a huge confusion of saying "Go
|
||
|
|
is better than Java/C#" while what we are talking about is "Go vs Rust". The
|
||
|
|
whole "Let me take a huge turn here, saying Go is better than Java/C# only to,
|
||
|
|
in the end, say that Go is for Java and Rust is for C++, but I'll never
|
||
|
|
compare Java vs C++ to actually make a point about Go vs Rust with their
|
||
|
|
comparative other languages".</p>
|
||
|
|
<p>And then, when we pick the points in which the author goes straight for the
|
||
|
|
"Go vs Rust" discussion, all the points are wrong or seemed more about opinion
|
||
|
|
than actual facts.</p>
|
||
|
|
<p>So what is actually the point? That Go is better than Java and Rust is better
|
||
|
|
than C++ and, thus, Go is better than Rust? 'Cause I can totally buy in the
|
||
|
|
first part, but the second is bullshit.</p>
|
||
|
|
<p>I won't say Go is a bad language, but Go is in no way a better language than
|
||
|
|
Rust, specially if we consider the future, in which more cores will be
|
||
|
|
available (considering the current trends) and more threaded applications will
|
||
|
|
be more common. I'll say that Rust design decisions give an edge over Go, so
|
||
|
|
Go should seriously go back to the basics of error control and memory
|
||
|
|
protection if it wants to be a language for the future. But being bad managed
|
||
|
|
probably means it would never happen.</p>
|
||
|
|
<p>And those points make Go a bad option for anyone writing something serious. </p>
|
||
|
|
<p>But what do I meant by "badly managed"? Well, as you can see, the core devs
|
||
|
|
don't seem to listen the community on the big issues (one could bring the
|
||
|
|
discussion about a <code>Try</code> operator, which would be a minor change, compared to
|
||
|
|
the dependency control, which the community said no and the core devs agreed
|
||
|
|
but, again, that's a minor thing compared to dependency control tool). The <code>go dep</code> was a complete "ignore whatever the community built, 'cause we know
|
||
|
|
better" and the Google proxy was simple a PSA, not a "let's ask the community
|
||
|
|
what they think about it before doing it so" are two signs that they don't
|
||
|
|
care about what the community wants and that means they can pivot the language
|
||
|
|
in a way that the community <em>doesn't</em> want and there would be nothing one
|
||
|
|
could do.</p>
|
||
|
|
<p>"It's just one tool, not the whole thing!", you're screaming at me. But it is
|
||
|
|
a tool the community seriously wanted (the Go Evangelist inside Microsoft came
|
||
|
|
to her twitter account to loudly say "Go core, fix this or I will stop
|
||
|
|
promoting go inside Microsoft, 'cause it's bad right now") and they were first
|
||
|
|
ignored and then pushed aside.</p>
|
||
|
|
<p>That's not how open source projects should move about.</p>
|
||
|
|
<p>You may not care about this "open source" thingy, and that's ok. You may
|
||
|
|
believe that the core team knows better how Go should move forward than the
|
||
|
|
people actually writing code in Go, and that's ok. But if you're an open
|
||
|
|
source proponent, evangelist or admirer, there is absolutely no reason to
|
||
|
|
defend Go on <em>any</em> accounts.</p>
|
||
|
|
<p>Want to bash me? Agree with any of the points? Disagree? Come talk to me <a href="https://functional.cafe/@juliobiason/102804921786785051">on
|
||
|
|
Functional Cafe</a>.</p>
|
||
|
|
<hr />
|
||
|
|
<div class="footnote-definition" id="1"><sup class="footnote-definition-label">1</sup>
|
||
|
|
<p>Added in 2019.09.17.</p>
|
||
|
|
</div>
|
||
|
|
<div class="footnote-definition" id="2"><sup class="footnote-definition-label">2</sup>
|
||
|
|
<p>Update in 2019.09.17, pointing that the discussion about this will come
|
||
|
|
later in the post.</p>
|
||
|
|
</div>
|
||
|
|
<div class="footnote-definition" id="3"><sup class="footnote-definition-label">3</sup>
|
||
|
|
<p>Added in 2019.09.17, to point that senior devs discussing which language
|
||
|
|
is easier or harder to teach to juniors is a moot point.</p>
|
||
|
|
</div>
|
||
|
|
<div class="footnote-definition" id="4"><sup class="footnote-definition-label">4</sup>
|
||
|
|
<p>Added in 2019.09.17, pointing that even if senior devs discussing if a
|
||
|
|
language is harder or easier for juniors to understand, Rust have an open
|
||
|
|
door policy for this kind of stuff.</p>
|
||
|
|
</div>
|
||
|
|
<div class="footnote-definition" id="5"><sup class="footnote-definition-label">5</sup>
|
||
|
|
<p>Added in 2019.09.17, when I realized what we were really talking about.</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|