Browse Source

Merge branch 'release/20190917'

master 20190917
Julio Biason 5 years ago
parent
commit
b504acc165
  1. 82
      content/thoughts/why-rust-and-not-go.md

82
content/thoughts/why-rust-and-not-go.md

@ -90,7 +90,8 @@ 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, _both_ are true.
One could even claim that Python is more boring that Go.
One could even claim that Python is more boring that Go. [^1] And Rust, by the
way.
> do more with less” has proven to be very successful.
@ -105,7 +106,7 @@ mean?
If we point that Rust does exactly what you're saying and _better_ ("enforce"
vs "you need to run something, otherwise nothing changes", which I _will_
point right now), then Rust kills Go in enterprise software, right?
discuss later in this post[^2]), then Rust kills Go in enterprise software, right?
> Enterprise software always has a big scope.
@ -166,7 +167,7 @@ to make here is "worked for Google, will work for you", which is plain wrong.
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. _At all_.
# The Plain Wrong
## The Plain Wrong
> Go is also strict about things that other languages are usually more lax about.
@ -179,7 +180,8 @@ annoyance.
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) or it's very strict (like Rust does).
doing the conversion to you, for example) or it's very strict (like Rust
does).
Also, since you're talking about "strictness", let me ask you this: Have the
Go core devs fixed this?
@ -269,7 +271,7 @@ point below about types and above about compiler strictness).
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.
# The Somewhat Right
## The Somewhat Right
> There are a lot of junior developers
@ -286,7 +288,22 @@ 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.
to learn Go due its syntax than it is to learn Rust. [^3] 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 _any_
language is easy to learn.
[^4] Also, let me point out that Rust have an "Ergonomics Working Group" (now
simply called ["Language Changes RFCs"](https://github.com/rust-lang/rfcs),
which discuss ways to make the language easier to use and there is a whole
["Compiler Errors Working
Group"](https://github.com/rust-lang/rust/labels/WG-compiler-errors) 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?
> This pushes further down technological concerns such as efficiency, and even
> correctness. Don’t get me wrong, the business does care about correctness,
@ -381,7 +398,39 @@ less bugs (personal observation, it actually does!).
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?
# The Things We Don't Talk About
## [^5] Dropping All Euphemisms
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).
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.
Rust, with all its checkers and rules and strictness have a larger TTSIW,
which may cause the release of glucocorticoid -- the stress hormone.
So, the whole point the original post tries to make is "Go gives me
serotonin".
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
_right_ _there_, in front of you, when you're building the system.
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.
And _that's_ 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?
## The Things We Don't Talk About
There is one important piece that is never discussed: Ecosystem.
@ -495,3 +544,22 @@ 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 _any_ accounts.
Want to bash me? Agree with any of the points? Disagree? Come talk to me [on
Functional Cafe](https://functional.cafe/@juliobiason/102804921786785051).
---
[^1]: Added in 2019.09.17.
[^2]: Update in 2019.09.17, pointing that the discussion about this will come
later in the post.
[^3]: 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.
[^4]: 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.
[^5]: Added in 2019.09.17, when I realized what we were really talking about.

Loading…
Cancel
Save