4 ms·
From Go to Rust: The Two Types of Readable Code
- adamgordonbell 3y agoThanks 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.
- OkayPhysicist 3y ago"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 https://hexdocs.pm/elixir/introduction.html
- adamgordonbell 3y agoThis is a solid point that I didn't think of. Time to reading fluency. Love it.
- tharne 3y ago> 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.
- bionsystem 3y agof(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>
- Quekid5 3y ago> 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 https://hackage.haskell.org/package/turtle
- impulser_ 3y ago> But Go doesn’t have a way to get the maximum of some ints in the standard library. So I’d have to implement the max function myself 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.
- namaria 3y agoYeah Rust the the language I'd like to know. Go is the language I'd like to use. Especially if I have to work with many other programmers.
- ivanjermakov 3y agoI 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.
- rightbyte 3y agoFor 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.
- udev4096 3y agoOnce you start using channels, Go doesn't seem that beginner friendly
- rastignack 3y agoYes async pin and all that jazz are so easy to understand !
- laerus 3y agoI 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.
- winrid 3y agois there a language/runtime where running multithreaded code is easier?
- udev4096 3y agopython?
- pornel 3y agoDepends 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.