Should I Rust, or Should I Go. Rust быстрее и с большими возможностями, Go проще и лаконичнее.
#go #rust #article
#go #rust #article
Medium
Should I Rust, or Should I Go
“Should I stay, or should I go?” Great song by the band The Clash. I’m listening to it, right now, while I’m writing this article. The song…
fasterthanli.me is a relatively popular blog dedicated to comparing how better Rust is than Go. Well, it's a personal blog of a guy, so it's not dedicated to anything in particular, but feels like this is the main theme for most of the posts. Even if it's about just Rust, comparison with Go will pop up. For example:
+ Lies we tell ourselves to keep using Golang
+ Some mistakes Rust doesn't catch
+ I want off Mr. Golang's Wild Ride
+ Aiming for correctness with types
And you know what? Being an engineer who loves Go and avoids Rust, I agree with most of the things (if not all of them, I don't keep the score). The type system in Go sometimes is too forgiving and even the existing type system could've been used better in stdlib.
A good example (that is also covered in the blog) is having
So, when you write anything on a language with a type checker (in the modern world, it's almost every language), I urge you to create subtypes for things and don't just use strings and integers. It's not so hard and it makes the code so much safer and more readable.
Oh, and I recommend reading this blog, even if you don't care about Rust or code correctness.
#golang #rust
+ Lies we tell ourselves to keep using Golang
+ Some mistakes Rust doesn't catch
+ I want off Mr. Golang's Wild Ride
+ Aiming for correctness with types
And you know what? Being an engineer who loves Go and avoids Rust, I agree with most of the things (if not all of them, I don't keep the score). The type system in Go sometimes is too forgiving and even the existing type system could've been used better in stdlib.
A good example (that is also covered in the blog) is having
string as the type for filesystem paths. It prompts so many bugs, from messing the argument order to concatenating paths as they were just, well, regular strings. And all of it could've been solved just by having type Path string declaration. What's interesting, there is a time.Duration type which does exactly this. Instead of passing time in seconds (Python, C) or microseconds (Erlang, Elixir) and messing with it each time, you explicitly specify the units when building the type. For example, 5 * time.Second. Just beautiful and much safer.So, when you write anything on a language with a type checker (in the modern world, it's almost every language), I urge you to create subtypes for things and don't just use strings and integers. It's not so hard and it makes the code so much safer and more readable.
Oh, and I recommend reading this blog, even if you don't care about Rust or code correctness.
#golang #rust
🦀 The built-in Rust testing framework is alright for small tests, but it quickly falls apart when the project grows. And even for small projects, the tests look messy and the failure output isn't helpful. I haven't found one all-in framework like pytest but there are some small projects that together make something much better:
+ nextest is a fast test runner with a nice colorful output, powerful DSL for filtering tests to be run, and built-in mechanism for detecting slow and flaky tests. And the great thing is that it runs regular Rust tests, so you don't need to change anything in the prject itself to use it.
+ proptest is a hypothesis-inspired framework for writing property-based tests. You tell it what kind of input you want for your test, and it generates random values, trying to cover as many corner cases as possible. When a test fails, it finds a nice and small example for reproducing the failure.
+ rstest is a library that provides pytest-like fixtures and test parametrization (for table-driven testing). I'm not sure if fixtures is a good idea (I wrote pytypest for Python just to fix the mess that pytest fixtures bring in big projects) but parametrization is a must. You can also try test-case library, it looks similar but also lets you to specify a name for each case.
+ k9 provides a macro for snapshot testing. It dumps on disk whatever data you pass into it on the first run, and later on consequent runs compares the new value with the dumped one.
+ A better assert statement is still in question. The built-in
I wonder if the built-in Rust macro system allows making a nice looking assert macro with pytest-like source rewrites. Like a macro that will convert
#rust
+ nextest is a fast test runner with a nice colorful output, powerful DSL for filtering tests to be run, and built-in mechanism for detecting slow and flaky tests. And the great thing is that it runs regular Rust tests, so you don't need to change anything in the prject itself to use it.
+ proptest is a hypothesis-inspired framework for writing property-based tests. You tell it what kind of input you want for your test, and it generates random values, trying to cover as many corner cases as possible. When a test fails, it finds a nice and small example for reproducing the failure.
+ rstest is a library that provides pytest-like fixtures and test parametrization (for table-driven testing). I'm not sure if fixtures is a good idea (I wrote pytypest for Python just to fix the mess that pytest fixtures bring in big projects) but parametrization is a must. You can also try test-case library, it looks similar but also lets you to specify a name for each case.
+ k9 provides a macro for snapshot testing. It dumps on disk whatever data you pass into it on the first run, and later on consequent runs compares the new value with the dumped one.
+ A better assert statement is still in question. The built-in
assert! and assert_eq! do not provide a helpful enoug error message, far cry from what you can see in pytest or ex_unit. k9 and pretty-assertions provide some additional assertions but that's still not enough. In particular, I right away miss something like assert_is_close for comparing floats or an assertion that will show the arguments with which the target function was called. There is approx library just for that but I think adding a library for each assertion type doesn't scale well.I wonder if the built-in Rust macro system allows making a nice looking assert macro with pytest-like source rewrites. Like a macro that will convert
magic_assert!(f(a, b) > x) into assert!(f(a, b) > x, "f({}, {}) > {}", a, b, x).#rust
taplo is a CLI tool (and a Rust library) for working with TOML. It can check TOML files for syntax errors, validate them against JSON schemas, and format.
The best thing about it is the Even Better TOML VSCode plugin wrapping taplo that provides all the same things as CLI plus smart syntax highlighting, navigation, refactoring, and even autocomplete for
#rust
The best thing about it is the Even Better TOML VSCode plugin wrapping taplo that provides all the same things as CLI plus smart syntax highlighting, navigation, refactoring, and even autocomplete for
pyproject.toml, fly.toml, Cargo.toml and a few other formats).#rust