A Gopher Meets a Crab
miren.dev
miren.dev
This isn’t like learning JavaScript and then expecting to be an expert in Prolog.
Some people adapt to it more easily, especially coming from languages like scala but it has a lot of unique characteristics that aren't in C or are even related. Like lifetimes, dynamic dispatch through enums, the borrowchecker, pattern matching, the ? Operator, etc.
Maybe you all are way smarter than me, super possible, but I wouldn't expect much to translate between go and rust. I think some evidence for that is the blog post here...
But, to be fair to you, I’ve not touched Rust in a couple of years so maybe my memory is fallible here?
Over the years c++ has been influenced to offer things people like from rust. So modern c++ looks a little more like rust. But older c++ really doesn't.
Similarly rusts approach to dynamic dispatch is more like OCAML than c++.
You can use rust and c++ for similar objectives though. Anyone can reduce two technical things until they are identical or expand them until they are completely different.
I think the most sober take is they are sufficiently different from one another.
How much familiarity do you need to be starting from scratch?
In a later comment you said the following:
> You aren't starting from scratch in the same way that if you have written javascript you aren't starting from scratch writing c++.
But I’d argue that you wouldn’t be starting from scratch with C++ as a JS developer either because you already understand all the fundamentals of imperative programming:
- objects, properties and methods
- functions
- iteration (for loops are literally written the same)
- variable assignment
- expression notion and the order of precedence for operators
- global variables vs local variables
And so on and so forth.
Whereas going to ASM, LISP, Forth, or Prolog would require relearning everything you thought you knew about programming.
So to that point, once you learn Go, you could write a function in JS, C, Rust, and so on. You’d know roughly how to structure it and what syntax to use. You might not write the best and most idiomatic version of that function because you might not fully appreciate the differences with type system, variable referencing, macros, and so on. But that’s all knowledge you’d build upon from the experience you already have.
And the reason I make this distinction is because we were specifically talking about using an LLM for teaching.
To learn the nuances between languages of the same paradigm, the best way to learn is to write a project in that language. Whereas when going to something entirely alien like Prolog, you first need to learn the fundamentals (eg “from a book”) before you could even think about starting a project.
And what this guy did was work with an LLM on a project to learn the differences between Go and Rust.
So my point was those two languages are similar enough that the authors approach seems very reasonable to me. Whereas if he’d tried to do this with (for example) Haskell, then I’d have agreed with the naysayers.
Now do the same with typescript. I bet they have a fighting chance.
Do I know exactly why X was choosen instead of Y? Do I know best practices? Do I know best libs etc? No, that is the reason to ask about it.
So getting an LLM to write an example project then dissecting the code and interrogating those choices, seems like a very good way to learn the idioms of another language.
Syntax is the easy stuff to learn. It’s any shifts in paradigms (eg pure functional vs imperative vs logic… etc) that takes time to learn.
And I say this as someone who’s written professional software in well over a dozen different languages. So I understand well the challenges learning something new.
I have also trained people who were good to decent software engineers in other languages to write rust. The syntax is nontrivial for a lot of people. There are a lot of people who gave up trying to learn rust, especially before the rust book became what it is today.
People typically fight the borrowchecker until it clicks. Learning from an LLM and reading only means you have to be as good as the rust compiler without any experience writing the language. It's got to be way harder that way.
You said 6 in your other comment. Which is half a dozen.
But I take your point about the syntax being complex. That was the main reason I stopped coding in Rust: not because I couldn’t learn the language but because I didn’t enjoy the complexity. To me it felt like it needed someone to reign in design choices (Python is suffering from this problem now too).
On a slight tangent: one of my pet peeves is feature creep in programming languages. It makes it harder to learn the language. Harder to agree on coding styles in teams. Easier to fuck up and thus requires you to be on your A-game when writing code for it. I don’t always agree with Go’s choices, but I respect that the language is conservative in what gets approved into the language. This is a takeaway more languages need to learn from.
Anyway, back on topic: I don’t agree that the syntax and borrow checker constitutes as “a different paradigm”. But I’ll concede that I might be overstating how easy it is for others to learn these idioms.
I don't blame your choice to walk away from rust. It is more complex than other languages. I like it because it makes the complexity explicit. Other people really do not. Both views are valid.
I think that explicit nature for memory handling is a paradigm change. Though I do understand that the definition of programming paradigms isn't really inclusive of that. But it introduces changes to how the language is composed, run, and compiles that aren't a part of other paradigms necessarily.
Eg, It's not a lint to have a use after free for rust. It's part of the acceptable subset of the language and must be expressed in the code.
Go and Rust have different idioms and syntax. But they occupy broadly similar paradigms.
For example, you don’t need to relearn how to do iteration like you would with a logic or pure functional language. You wouldn’t need to concepts like methods, like you would if you were coming from a stack based language. Etc
Go and rust have very little in common. If you consider them to be the same paradigm that's fine. But I don't think most people would as rust leans more functional.
And that’s the point I was always making. Rust takes inspiration from different languages than Go. But there is a huge amount of borrowed experience you can lean on when switching between Go and Rust. You’re not starting from scratch.
Perhaps the real problem here is that developers stick to a subset of similar imperative languages and then moan that minor differences are hard to reason about?
You aren't starting from scratch in the same way that if you have written javascript you aren't starting from scratch writing c++.
Go focuses on heavy runtime, looser type systems, and all the benefits and drawback that brings.
When you start reading, it helps to have some guidance towards good and relevant books, from e.g. school, mentors, criticism, etc. Then, when you encounter a "bad" book, you have some benchmarks from which you can build your capacity for analysis and critique. (Testing your analysis and critique with others helps, too.)
If you start with "bad" books, your concept of quality and what's possible is constrained. (Like when teenage boys read Atlas Shrugged.)
Reading slop code is a terrible way to build a mental benchmark for what's good, what's possible, what's elegant, and writing good code that is respectful to your fellow human beings.
The days of AI only being capable of producing unreliable slop code are long gone.
But you also have to understand that it’s very easy for people to say “x is bad” when actual real world problems sometimes require a small smattering of ugly code. So it’s not unreasonable for me (or anyone else) to ask how you’d write a solution to the same problem.
Now what I’m trying to understand is whether the examples highlighted by the author as ugly, was ugly because it’s bad code. Or ugly because it was the right solution which lead to ugly code. Which is why I was asking for your preferred solution.
let msg = timeout(Duration::from_secs(2), receiver.next()).await.ok()??;
// not shown in article, but next line of code
let Message::Text(frame) = msg_result.ok()? else {
return None;
};
It is more like you wanting to build a bed out of wood so you hire a carpenter and watch them and ask questions about every step and maybe help a bit at the end.
I find it amazing to learn new programming things
As far as being taught a new language and its ecosystem through an LLM, is SO much faster than reading a book + documentation, it's like asuperpower.
a) Vibe coding produces bad code
b) Rust is weird
Somehow we’re supposed to accept b as the answer? Give me a break….
The blog post uses, among other things, the Try operator ? and pattern matching, neither of which are available in C++ and both of which make the Result type much nicer to use than std::expected. There have been similar "I saw it in a shop window" proposals for both these in C++, and I expect that pattern matching in particular will be attempted again targeting C++ 29.
So which is it?
The answer is rust has very little in common with go. Rust is very explicit and go is not. Some people find the explicit nature of rust and it's guarantees refreshing. Other people find go refreshing because the syntax is more limited and it looks simple on paper.
IMO: Go is a very "productive" and clean lang/platform when comparing to Rust. It's depends what you're using it for. In my case (for concurrent backends) Go came as a bliss. And that was before AI (vibecoding).
Result<Option<Result<Message, WsError>>, Elapsed>
The nicer version is not a cleverer match. It’s choosing a domain error shape and converting into it one layer at a time:
let timed = tokio::time::timeout(duration, receiver.next()).await;
let next = timed.map_err(|_| ReceiveError::Timeout)?;
let item = next.ok_or(ReceiveError::Closed)?;
let msg = item.map_err(ReceiveError::WebSocket)?;
Result<(), ()>
That said, a couple of the examples here feel a bit strange - they're clever things you can do, but they're not necessarily things you often have to do, particularly for a relatively simple task like this. I think the problem with the author's approach is that they can't distinguish between "weird because Rust is weird" and "weird because the LLM generated bad code", because they (understandably) don't have enough experience in what good Rust code looks like.
this lets you implement `std::error::Error`, which you really should to make it less painful when you want to erase the type (`std::error::Error` is `dyn`-compatible)