> 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.
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).
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 :
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.)
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.
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.
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.
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.
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.