forked from wezm/wezm.net
Add first-3-weeks-of-professional-rust post
This commit is contained in:
parent
7cc2622fbe
commit
ac9650d7cc
6 changed files with 159 additions and 4 deletions
|
@ -181,6 +181,9 @@ footer
|
||||||
.align-top
|
.align-top
|
||||||
vertical-align: top
|
vertical-align: top
|
||||||
|
|
||||||
|
.with-border
|
||||||
|
border: 1px solid #D8D8D8
|
||||||
|
|
||||||
.no-border
|
.no-border
|
||||||
border: none
|
border: none
|
||||||
text-decoration: none
|
text-decoration: none
|
||||||
|
|
141
content/technical/2019/03/first-3-weeks-of-professional-rust.md
Normal file
141
content/technical/2019/03/first-3-weeks-of-professional-rust.md
Normal file
|
@ -0,0 +1,141 @@
|
||||||
|
For the last 15 years as professional programmer I have worked mostly with
|
||||||
|
dynamic languages. First [Perl], then [Python], and for the last 10 years or so
|
||||||
|
[Ruby]. I've also been writing [Rust] on the side for personal projects for
|
||||||
|
nearly four years. Recently I started a new job and for the first time I'm
|
||||||
|
writing Rust professionally. Rust represents quite a shift in language
|
||||||
|
features, development process and tooling. I thought it would be interesting to
|
||||||
|
reflect on that experience so far.
|
||||||
|
|
||||||
|
_Note that some of my observations are not unique to Rust and would be equally
|
||||||
|
present in other languages like [Haskell], [Kotlin], or [OCaml]._
|
||||||
|
|
||||||
|
## Knowledge
|
||||||
|
|
||||||
|
In my first week I hit up pretty hard against my knowledge of [lifetimes in
|
||||||
|
Rust][lifetimes]. I was reasonably confident with them conceptually and their
|
||||||
|
simple application but our code has some interesting type driven zero-copy
|
||||||
|
parsing code that tested my knowledge. When encountering some compiler errors I
|
||||||
|
was fortunate to have experienced colleagues to ask for help. It's been nice to
|
||||||
|
be extending my knowledge and learning as I go.
|
||||||
|
|
||||||
|
Interestingly I had mostly been building things without advanced lifetime
|
||||||
|
knowledge up until this point. I think that sometimes the community puts too
|
||||||
|
much emphasis on some of Rust's more advanced features when citing its learning
|
||||||
|
curve. If you read [the book] you can get a very long way. Although that will
|
||||||
|
depend on the types of applications or [data structures][linked-list] you're
|
||||||
|
trying to build.
|
||||||
|
|
||||||
|
## Confidence
|
||||||
|
|
||||||
|
In my second week I implemented a change to make a certain pattern more
|
||||||
|
ergonomic. It was refreshing to be able to build the initial functionality and
|
||||||
|
then make a project wide change, confident that given it compiled after the
|
||||||
|
change I _probably_ hadn't broken anything. I don't think I would have had the
|
||||||
|
confidence to make such a change as early on in the Ruby projects I've worked
|
||||||
|
on previously.
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
I cringe whenever I see proponents of statically typed languages say things
|
||||||
|
like, "if it compiles, it works", with misguided certainty. The compiler and
|
||||||
|
language do eliminate whole classes of bugs that you'd need to test for in a
|
||||||
|
dynamic language but that doesn't mean tests aren't needed.
|
||||||
|
|
||||||
|
Rust has great built in support for testing and I've enjoyed being able to
|
||||||
|
write tests focussed solely on the behaviour and logic of my code. Instead of
|
||||||
|
behaviour and logic in addition to ensuring there are no syntax errors, or that
|
||||||
|
`nil` is handled safely, etc.
|
||||||
|
|
||||||
|
## Editor and Tooling
|
||||||
|
|
||||||
|
[Neovim] is my primary text editor. I've been using [vim] or a derivative since
|
||||||
|
the early 2000s. I have the [RLS] set up and working in my Neovim environment
|
||||||
|
but less than a week in I started using [IntelliJ IDEA][IntelliJ] with the Rust
|
||||||
|
and Vim emulation plugins for work. A week after that I started trialling
|
||||||
|
[CLion] as I wanted a debugger.
|
||||||
|
|
||||||
|
<figure>
|
||||||
|
<img class="with-border" src="/images/2019/jetbrains-clion.png" alt="JetBrains CLion IDE" />
|
||||||
|
<figcaption>JetBrains CLion IDE</figcaption>
|
||||||
|
</figure>
|
||||||
|
|
||||||
|
The impetus for the switch was that I was working with a colleague on a
|
||||||
|
change that had a fairly wide impact on the code. We were practicing
|
||||||
|
[compiler driven development] and were doing a repeated cycle of fix an error,
|
||||||
|
compile, jump to next top most error. Vim's [quickfix] list + [:make] is
|
||||||
|
designed to make this cycle easier too but I didn't have that set up at the
|
||||||
|
time. I was doing a lot of manual jumping between files, whereas in IntelliJ I
|
||||||
|
could just click the paths in the error messages.
|
||||||
|
|
||||||
|
It's perhaps the combination of working on a foreign codebase and also trying
|
||||||
|
to maximise efficiency when working with others that pushed me to seek out
|
||||||
|
better tooling for work use. There is a ongoing to work to improve the RLS so I
|
||||||
|
may still come back to Neovim and I continue to use it for personal
|
||||||
|
projects.
|
||||||
|
|
||||||
|
Other CLion features that I'm enjoying:
|
||||||
|
|
||||||
|
* Reliable autocomplete
|
||||||
|
* Reliable jump to definition, jump to impl block, find usages
|
||||||
|
* Refactoring tooling (rename across project, extract method, extract variable)
|
||||||
|
* Built in debugger
|
||||||
|
|
||||||
|
[VS Code] offers some of these features too. However, since they are built on
|
||||||
|
the RLS they suffer many of the same issues I had in Neovim. Additionally I
|
||||||
|
think the Vim emulation plugin for IntelliJ is more complete, or at least more
|
||||||
|
predictable for a long time vim user. This is despite the latter actually using
|
||||||
|
Neovim under the covers.
|
||||||
|
|
||||||
|
## Debugging
|
||||||
|
|
||||||
|
In Ruby with a gem like [pry-byebug] it's trivial to put a `binding.pry` in
|
||||||
|
some code to be dropped into a debugger + REPL at that point in the code. This
|
||||||
|
is harder with Rust. `println!` or `dbg!` based debugging can get you a
|
||||||
|
surprisingly long way and had served me well for most of my personal projects.
|
||||||
|
|
||||||
|
When building some parsing code I quickly felt the need to use a real
|
||||||
|
debugger in order to step through, and examine execution of a failing test.
|
||||||
|
It's possible to do this on the command line with the `rust-gdb` or `rust-lldb`
|
||||||
|
wrappers that come with Rust. However, I find them fiddly to use
|
||||||
|
and verbose to operate.
|
||||||
|
|
||||||
|
CLion makes it simple to add and remove break points by clicking in the gutter,
|
||||||
|
run a single test under the debugger, visually step through the code, see all
|
||||||
|
local variables, step up and down the call stack, etc. These are possible with
|
||||||
|
the command line tools (which CLIon is using behind the scenes), but it's nice
|
||||||
|
to have them built in and available with a single click of the mouse.
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
So far I am enjoying my new role. There have been some great learning
|
||||||
|
opportunities and surprising tooling changes. I'm also keen to keep an eye on
|
||||||
|
the frequency of bugs encountered in production, their type (such as panic or
|
||||||
|
incorrect logic), their source, and ease of resolution. I look forward to
|
||||||
|
writing more about our work in the future.
|
||||||
|
|
||||||
|
<div class="seperator"><hr class="left">✦<hr class="right"></div>
|
||||||
|
|
||||||
|
Previous Post: [A Coding Retreat and Getting Embedded Rust Running on a SensorTag](/technical/2019/03/sensortag-embedded-rust-coding-retreat/)
|
||||||
|
|
||||||
|
|
||||||
|
[:make]: https://neovim.io/doc/user/quickfix.html#:make
|
||||||
|
[CLion]: https://www.jetbrains.com/clion/
|
||||||
|
[compiler driven development]: https://doc.rust-lang.org/book/ch20-02-multithreaded.html#building-the-threadpool-struct-using-compiler-driven-development
|
||||||
|
[linked-list]: https://rust-unofficial.github.io/too-many-lists/
|
||||||
|
[Haskell]: https://www.haskell.org/
|
||||||
|
[IntelliJ]: https://www.jetbrains.com/idea/
|
||||||
|
[Kotlin]: https://kotlinlang.org/
|
||||||
|
[lifetimes]: https://doc.rust-lang.org/book/ch19-02-advanced-lifetimes.html
|
||||||
|
[Neovim]: https://neovim.io/
|
||||||
|
[null]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
|
||||||
|
[OCaml]: https://ocaml.org/
|
||||||
|
[Perl]: https://www.perl.org/
|
||||||
|
[pry-byebug]: https://github.com/deivid-rodriguez/pry-byebug
|
||||||
|
[Python]: https://www.python.org/
|
||||||
|
[quickfix]: https://neovim.io/doc/user/quickfix.html
|
||||||
|
[RLS]: https://github.com/rust-lang/rls
|
||||||
|
[Ruby]: https://www.ruby-lang.org/en/
|
||||||
|
[Rust]: https://www.rust-lang.org/
|
||||||
|
[the book]: https://doc.rust-lang.org/book/index.html
|
||||||
|
[vim]: https://www.vim.org/
|
||||||
|
[VS Code]: https://code.visualstudio.com/
|
|
@ -0,0 +1,10 @@
|
||||||
|
---
|
||||||
|
title: My First 3 Weeks of Professional Rust
|
||||||
|
extra: Reflecting on the first 3 weeks of writing Rust in my new job.
|
||||||
|
kind: article
|
||||||
|
section: technical
|
||||||
|
created_at: 2019-03-24 09:45:00.000000000 +11:00
|
||||||
|
#updated_at: 2019-03-23T13:16:07+11:00
|
||||||
|
keywords:
|
||||||
|
- rust
|
||||||
|
short_url:
|
|
@ -42,8 +42,8 @@ microcontroller the SensorTag also add a bunch of sensors, including:
|
||||||
temperature, humidity, barometer, accelerometer, gyroscope, and light.
|
temperature, humidity, barometer, accelerometer, gyroscope, and light.
|
||||||
|
|
||||||
<figure>
|
<figure>
|
||||||
<img src="/images/2019/sensortag.jpg" width="400" alt="Two SensorTags. One with it's rubberised case removed and debugger board attached" />
|
<img src="/images/2019/sensortag.jpg" width="400" alt="Two SensorTags. One with it's rubberised case removed and debugger board attached" />
|
||||||
<figcaption>Two SensorTags. One with it's rubberised case removed and
|
<figcaption>Two SensorTags. One with it's rubberised case removed and
|
||||||
debugger board attached.</figcaption>
|
debugger board attached.</figcaption>
|
||||||
</figure>
|
</figure>
|
||||||
|
|
||||||
|
@ -230,6 +230,7 @@ next year.
|
||||||
<div class="seperator"><hr class="left">✦<hr class="right"></div>
|
<div class="seperator"><hr class="left">✦<hr class="right"></div>
|
||||||
|
|
||||||
Previous Post: [Rebuilding My Personal Infrastructure With Alpine Linux and Docker](/technical/2019/02/alpine-linux-docker-infrastructure/)
|
Previous Post: [Rebuilding My Personal Infrastructure With Alpine Linux and Docker](/technical/2019/02/alpine-linux-docker-infrastructure/)
|
||||||
|
Next Post: [My First 3 Weeks of Professional Rust](/technical/2019/03/first-3-weeks-of-professional-rust/)
|
||||||
|
|
||||||
[cargo-binutils]: https://crates.io/crates/cargo-binutils
|
[cargo-binutils]: https://crates.io/crates/cargo-binutils
|
||||||
[carmack]: https://www.facebook.com/permalink.php?story_fbid=2110408722526967&id=100006735798590
|
[carmack]: https://www.facebook.com/permalink.php?story_fbid=2110408722526967&id=100006735798590
|
||||||
|
|
|
@ -4,7 +4,7 @@ extra: I attended a small coding retreat with some friends and worked on running
|
||||||
kind: article
|
kind: article
|
||||||
section: technical
|
section: technical
|
||||||
created_at: 2019-03-12 19:45:00.000000000 +11:00
|
created_at: 2019-03-12 19:45:00.000000000 +11:00
|
||||||
updated_at: 2019-03-23T13:16:07+11:00
|
updated_at: 2019-03-24T13:01:51+11:00
|
||||||
keywords:
|
keywords:
|
||||||
- rust
|
- rust
|
||||||
- embedded
|
- embedded
|
||||||
|
|
BIN
output/images/2019/jetbrains-clion.png
Normal file
BIN
output/images/2019/jetbrains-clion.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 616 KiB |
Loading…
Reference in a new issue