
From Python to Go to Rust: an opinionated journey (2018) - snth
https://tech.allo-media.net/point/of/view/2018/03/22/from-python-to-go-to-rust.html
======
Townley
As a Python dev getting into more Rust development, I'm surprised whenever I
hear of this as a progression towards better tools, rather than a way of
adding new tools into my belt.

Django/Flask are great tools for spinning up a CRUD application with
authentication/authorization, API endpoints, and a template language if I
don't want to build out a React or Vue SPA.

Rust is a great language that's opened me to new domains of programming, and
also gives me the ability to write more performant, hardened API endpoints at
the expense of productivity in hours (this gap will definitely shrink as I get
better and as rust frameworks mature, but I'd be surprised if it went away
entirely)

If a developer views a suite of tools they know very well as "something they
used to use", they're more likely to make future architectural decisions based
on incorrectly viewing framework-powered python as a relic of the past, rather
than a viable (and often preferred, if hours of work are factored in)
alternative.

~~~
atoav
I get the fascination people have with Rust and I love to use Rust myself.
Part of the fascination certainly _is_ it’s tooling and that Rust nearly seems
to force you to make the right decisions. I’ve never wrote in a language were
I were so focused on the structure of my program rather than hammering in what
I felt. And when you hit compile and it works, it usually does so flawlessly.

However I use Python very often still, just not for every task. Just like you
said: Rust is another tool in the tool box and it isn’t that single purpose
machine that you buy and use once for a single project, it is that japanese
handsaw that is incredible useful and powerful in the hands of the right
person. But sometimes you just need to make many cuts fast and then the
handsaw (no pun intended) doesn’t cut it.

Python certainly has it’s place for me, but so does have Rust..

------
dev_dull
> _I compiled the code and … no error message. Everything went fine. But?! I
> just added a field to a struct, the compiler should say that my code is not
> good anymore because I’m not initializing the value where it should be!_

This is your big hangup with Go? You added a new field, didn’t use that field
anywhere, and the compiler didn’t complain? I’ve heard a lot of valid
criticisms of the language but this is a new one for me.

~~~
sytelus
I wouldn't have left Go just because of these but before you write this off as
minor thing, I would suggest you look this as one of the core language design
decision. It reveals two important language philosophies:

1\. Go doesn't follow "you pay for what you use" model.

2\. Go isn't too deeply invested in compilation as means for catching errors.

Above are not binary language decisions. If you go in one direction strongly
then there are consequences in other. Therefore all languages chose some
balance point (aka compromises). Go has chosen a balance point that is weaker
than Rust (and may be even C++) but stronger than Python.

~~~
rhinoceraptor
> 2\. Go isn't too deeply invested in compilation as means for catching
> errors.

Except when you've imported a package you're not currently using, that is a
mortal sin :)

------
ngngngng
I've yet to try Rust. But Go is the best and worst thing to happen in my
career. Best because it's amazing, worst because now I don't like working in
other languages.

I'm trying elixir currently, and it makes me want to rip my hair out. No for
loops, no typed parameters, implied returns. Who in the world though any of
this was a good idea? IO.puts() refuses to print certain objects (list of
ints) and just prints a newline, making it useless for debugging.

I'm very very excited to try Rust, and I'm glad I've been able to choose the
languages I work with up to this point in my career.

~~~
quaunaut
Just wanted to correct some things, as a fan of both Elixir and Rust.

> No for loops

But we do have for loops? That's what comprehensions are: [https://elixir-
lang.org/getting-started/comprehensions.html](https://elixir-lang.org/getting-
started/comprehensions.html)

> no typed parameters

But if you need types on your parameters, you have Guards, which... check for
type? Sure, you don't type every last parameter, but if you want that you can
upgrade to Dializer and get that feature too. It's just not as useful as you
likely treat it.

> implied returns

I understand that some may not like this, but it comes out of the idea that
generally, you want to avoid "side effects"\- ie, things in code that happen
without anyone but the original function causing them being able to tell.
Elixir doesn't completely lack them, as that would be pretty unreasonable, but
it does at least ask that you're clear about the purpose of functions by
having them always return _something_.

> IO.puts() refuses to print certain objects (list of ints) and just prints a
> newline, making it useless for debugging.

This seems like something must be going wrong. `IO.puts` certainly prints
lists of ints, however, it might also be mistaking them for a charlist, which
is definitely a concern. That's why generally, you want to use `puts` for
text, and `IO.inspect` for data structures. As an added convenience, if you
want to annotate your data structure with text, you can modify `IO.puts` like
so: `IO.puts "List: #{inspect(list_of_numbers)}"`. That will parse the list to
the inspect version and insert it into your `puts` line.

For the record, I'm not saying any of these necessarily shouldn't be a reason
to not like Elixir- we all have our preferences, but the reason behind many of
these choices is philosophical, and I'd be happy to explain anything else that
has puzzled you, if you're still interested in learning more about Elixir.

------
danielecook
I went from python to go to nim. Actually I still like go - but nim is an easy
transition from python.

I think nim is the best thing out there for building tiny CLI utilities. It’s
a fun language to code in.

~~~
coffeescripter
Nim is very nicel Not that it matters much in most cases, but the compiled
binary sizes are also quite low compared to Rust.

~~~
AlchemistCamp
Do you ever regret choosing "coffeescripter" as your handle? I loved CS and
contributed to the CoffeeScript Redux compiler but the language is definitely
pretty hated these days...

------
cdelsolar
That's a bizarre reason to stop using Go. I can't really think of many
realistic instances where that would bite you.

------
Evidlo
I was working on a simple Rust CLI program to parse JSON from the Github API,
but I got turned off by some of the unfriendliness of the available http libs.
One http library pulled in dozens of other crates and turned my 10 line
program into a 50MB binary [0], while another had an unpleasant api [1].

[0]
[https://docs.rs/reqwest/0.9.18/reqwest/](https://docs.rs/reqwest/0.9.18/reqwest/)

[1]
[https://docs.rs/hyper/0.12.29/hyper/client/index.html](https://docs.rs/hyper/0.12.29/hyper/client/index.html)

Maybe I have too much desire for instant gratification, but it sucked the fun
out of the project.

~~~
0815test
"Crates" are just compilation units. Do you feel "turned off" if a C/C++
library includes "dozens" of source code files, some of which might come from
outside projects? (A sibling comment mentioned --release already, which is
obviously something that one should be familiar with when discussing Rust's
performance.)

------
tptacek
The “zero value of a type should be useful” concept is pretty fundamental to
Go’s design. You can imagine compiler tooling that didn’t alter the language
allowing you to catch unintended uninitialized values, but a language that
changed the underlying default would no longer be Go.

------
slx26
rust is great if you have enough experience to pick it up without dying
trying. and you need to start reading the book. the enforced safety helps even
experienced devs with a formal background to reinforce and see some concepts
more clearly.

all that said, when you have to do advanced things and go unsafe, it can feel
really annoying (fighting the compiler) and limiting. most common problems can
be modeled in rust without issue, but if you have a clear idea of something
that you want to do that's more advanced... the language will actively work
against you, that's its goal. that has both a good and a bad side. maybe it
will get better in the future. still an awesome language today.

------
bibyte
I went through the same path as OP. But instead of discarding them I am still
using all three of them. And at least for me Python and Rust don't even
compete with each other.

------
hansdieter1337
Biggest issue for me is the compile time. Especially in comparison to Go it's
a huge difference. At work we have a huge codebase with over 1M LOC. I guess
for bigger projects you need proper interfaces so you can split up your code
into multiple libraries.

------
lymitshn
I would suggest F# to the op. Even though I have limited practical experience
with it, from what I've read and see it checks op's checkboxes.

------
stcredzero
_> This was the show stopper for me. I realized that I couldn’t rely on the
compiler to get my back when I was doing mistakes._

No! One shouldn't mindlessly rely on the compiler "to get your back." Instead,
one should code (or alter code) so that you've manipulated the situation, such
that the compiler will flag any errors. With a language like golang, this
means that you should make sure that the "zero values" are always copacetic.
(Analogous to crash-only software.)

------
ddss
python

