From Go to Rust: The Two Types of Readable Code(earthly.dev)
earthly.dev
From Go to Rust: The Two Types of Readable Code
https://earthly.dev/blog/readability/
5 comments
Thanks for sharing this! I wrote it.
Here's the idea: Code readability is highly subjective. What looks like gibberish to some is crystal clear to others.
But is readability more than just familiarity?
I think so and I think their is more than one type of readability. Newcomer Readability and Experienced Readability. And sometimes, they clash.
Which one should programming languages prioritize? Newcomer Readability helps adoption and is closely related to familiarity. But Experienced Readability is all about expressiveness.
Here's the idea: Code readability is highly subjective. What looks like gibberish to some is crystal clear to others.
But is readability more than just familiarity?
I think so and I think their is more than one type of readability. Newcomer Readability and Experienced Readability. And sometimes, they clash.
Which one should programming languages prioritize? Newcomer Readability helps adoption and is closely related to familiarity. But Experienced Readability is all about expressiveness.
"Time to reading fluency" is a pretty useful concept for language comparison. Framing it that way reveals an interesting fact: There's more than one way to make your language more readable. One way is by sacrificing information density, giving up Experienced readability in order to optimize for newcomer readability. Go is the posterchild for this approach.
The alternative is to provide better educational tools to increase the speed someone can reach a higher level of fluency. Elixir does a pretty good job of this, by providing a lot of very easily consumed guidance in their documentation (Their language guide [1] is IMO the gold standard for introductions to a language).
[1] https://hexdocs.pm/elixir/introduction.html
The alternative is to provide better educational tools to increase the speed someone can reach a higher level of fluency. Elixir does a pretty good job of this, by providing a lot of very easily consumed guidance in their documentation (Their language guide [1] is IMO the gold standard for introductions to a language).
[1] https://hexdocs.pm/elixir/introduction.html
This is a solid point that I didn't think of. Time to reading fluency. Love it.
> Here's the idea: Code readability is highly subjective
It really isn't. There may be things about it that are subjective, but readability is a fairly straightforward concept to most people.
It's okay to make something less readable, if the tradeoff you get for that is worth it. Sometimes it is, but most of the time it isn't.
It really isn't. There may be things about it that are subjective, but readability is a fairly straightforward concept to most people.
It's okay to make something less readable, if the tradeoff you get for that is worth it. Sometimes it is, but most of the time it isn't.
f(x,y) -> Clear and straightforward - the mark of practical programming.
f x y -> Acceptable in shell scripting, but a bit odd.
(f x y) -> Impossibly puzzling. Approach with caution!
Pretty funny. I'm working with maven at the moment so a function call looks more like :
<plugins> <plugin>execute</plugin> <id>function-f</id> <executions> <execution> <cmd>f</cmd> <arguments> <argument>x</argument> <argument>y</argument> </arguments> </execution> </executions> </plugin>
Pretty funny. I'm working with maven at the moment so a function call looks more like :
<plugins> <plugin>execute</plugin> <id>function-f</id> <executions> <execution> <cmd>f</cmd> <arguments> <argument>x</argument> <argument>y</argument> </arguments> </execution> </executions> </plugin>
> f x y -> Acceptable in shell scripting
Or Haskell (aka: with a good type system). Or even Haskell used for shell scripting[0]. I've used this along with Stack shebang lines to great effect. A 70 line git subcommand script with stronk type checking is amazing. (It's a very workflow-specific script, but the fact that I've never had to debug it because of weird interpolation issues, etc. is amazing.)
[0] https://hackage.haskell.org/package/turtle
Or Haskell (aka: with a good type system). Or even Haskell used for shell scripting[0]. I've used this along with Stack shebang lines to great effect. A 70 line git subcommand script with stronk type checking is amazing. (It's a very workflow-specific script, but the fact that I've never had to debug it because of weird interpolation issues, etc. is amazing.)
[0] https://hackage.haskell.org/package/turtle
Once you start using channels, Go doesn't seem that beginner friendly
Why? It’s quite straightforward
Yes async pin and all that jazz are so easy to understand !
I am writing Rust daily with async, channels and all that jazz and a then some, daily for a year now, but I have only written pin once to wrap existing code that was then refactored with no pin. So yeah I would take types with explicit semantics over arcane CSP syntax any time.
is there a language/runtime where running multithreaded code is easier?
Depends how you define it. If you want fine-grained concurrency, in a large and complex program, then Rust can be easier.
Rust itself is not easy to learn, but once you overcome that, its thread-safety features are amazing, and can catch bugs that could otherwise be very difficult to track down. In Golang you're at risk of forgetting to use a mutex or atomic where necessary, or having some function mutate object you thought was immutable, and the race detector needs to catch such violations at run time, whereas Rust catches them at compile time.
Rust has libraries for multi-threaded jobs (like parallel iterators), while in Golang I see people making ad-hoc DIY versions of these with channels and goroutines, and the simple constructs don't always handle cases like cancellation or panics.
Rust itself is not easy to learn, but once you overcome that, its thread-safety features are amazing, and can catch bugs that could otherwise be very difficult to track down. In Golang you're at risk of forgetting to use a mutex or atomic where necessary, or having some function mutate object you thought was immutable, and the race detector needs to catch such violations at run time, whereas Rust catches them at compile time.
Rust has libraries for multi-threaded jobs (like parallel iterators), while in Golang I see people making ad-hoc DIY versions of these with channels and goroutines, and the simple constructs don't always handle cases like cancellation or panics.
if someone finds go-routines hard I don't think the suggestion is rust.
Go’s difficulty doesn’t come from being too hard to understand, but from being too simplistic to solve problems properly once.
Repetitive code creates more room for simple mistakes. When every case gets an ad-hoc solution it’s natural to cut corners, because it feels wasteful and too noisy to make every boilerplate copy look complicated by handling edge cases.
So you don’t have `parallel for`. Instead, each instance is a hand-rolled combo of channels that may or may not limit maximum concurrency, may not care to preserve order when items take different time to process, may not finish or report failure correctly when one of the tasks panics.
Additionally, goroutines don’t have any thread safety guarantees. Built-in types aren’t safe to share unsynchronized between goroutines, and the language is too basic to prevent accidental sharing or force immutability or synchronization. A too-easy language can put more burden on programmers.
Repetitive code creates more room for simple mistakes. When every case gets an ad-hoc solution it’s natural to cut corners, because it feels wasteful and too noisy to make every boilerplate copy look complicated by handling edge cases.
So you don’t have `parallel for`. Instead, each instance is a hand-rolled combo of channels that may or may not limit maximum concurrency, may not care to preserve order when items take different time to process, may not finish or report failure correctly when one of the tasks panics.
Additionally, goroutines don’t have any thread safety guarantees. Built-in types aren’t safe to share unsynchronized between goroutines, and the language is too basic to prevent accidental sharing or force immutability or synchronization. A too-easy language can put more burden on programmers.
Elixir?
python?
I have a very strong position against comments. Because they're not checked by compiler, they cannot be trusted. And in the places where coee is frequently changing, these comments often detach from their place and get outdated.
This does not relate to function/class/module level docs though, but it also needs to be frequently checked for correctness.
This does not relate to function/class/module level docs though, but it also needs to be frequently checked for correctness.
For the next guy maybe wrong comments are eons better than "no comments, no incorrect comments".
But, ye, writing a mess is job security. I don't blame you.
But, ye, writing a mess is job security. I don't blame you.
min and max functions are now in the standard library as of 1.21.
>Myself, I think expert readability is more important than beginner friendliness.
I think the opposite. beginner friendliness benefits both beginners and experts while expert readability only benefits experts. This is why I stopped using Rust. It hard to get started and even months into learning it and you finally feel productive you step into a new project and it feels like you are going backwards.
I can hop into any Go project and feel productive right away.