A Gopher Meets a Crab

https://miren.dev/blog/gopher-meets-crab

by radimm • 3 months ago

47 72 3 months ago

joshka3• 3 months ago

The weird-looking Rust isn’t really Rust being weird, it’s the type telling the truth.

   Result<Option<Result<Message, WsError>>, Elapsed>

That’s three independent “not the happy path” channels: timeout, stream closed, and websocket error.

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)?;

The ugly line is what happens when you have not decided where to normalize the shape yet.

loeg2• 3 months ago

  Result<(), ()>

Is pretty weird, though, no? Why would you want a unit value / error type?

tux3• 3 months ago

Sometimes you just want a fancy boolean. The advantage is that Result has all the Result APIs and you can compose it with other Results, but otherwise this is just a success bool.

MrJohz2• 3 months ago

It's basically doing the same thing that, say, `return true` might do to indicate a function succeeded, but with more explicit types. However, because it uses `Result`, it can be used with the `try`/question mark operator which can be convenient in some situations.

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.

stingraycharles• 3 months ago

It’s the equivalent of Haskell’s Either, with Option being the equivalent of Maybe. They’re fairly well-defined idioms.

nasso_dev• 3 months ago

it is indeed pretty weird. clippy has a lint against this iirc. it's recommended to just create a custom error type, even if its just an empty struct or a single-variant enum

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)

simianwords2• 3 months ago

Off topic but using “shape” like this is LLM coded

bobnamob• 3 months ago

I guess I'm an LLM then. I've been referring to the structure of types as "shape" for more than a decade and so have plenty of others

joshka3• 3 months ago

Probably on topic here - I talk like an LLM sometimes, and parse my points through them sometimes. I’d reasonably use that terminology and think nothing of it as it’s precise and correct. That said, this was partially LLM and my thinking here.

asibahi• 3 months ago

No it is not. If you were introduced to the term via LLMs doesnt mean everyone was.

RobotToaster• 3 months ago

Was anyone else expecting OpenClaw over gopher protocol?

coqadoodle• 3 months ago

I was looking forward to retro deep-dive back into the 90s. I just couldn't figure out where the crab fit in.

nothinkjustai6• 3 months ago

Um? Person vibe codes Rust. Output is stupid. The conclusion is either

a) Vibe coding produces bad code

b) Rust is weird

Somehow we’re supposed to accept b as the answer? Give me a break….

2ndorderthought13• 3 months ago

People really are forgetting how to think. While reading this blog post I almost immediately flipped into teaching confused freshmen taking the course that wasn't their major mode.

joshka3• 3 months ago

A much more charitable reading of the article is "here's some observations I found interesting / different". I met the author at the conf and watched their talk. Their perspective was very much in the camp of exploration, learning, wonder, etc. and not in the camp of criticism of either rust or vibe coding practices.

nothinkjustai6• 3 months ago

Interesting that the talk was quite different, because this clearly AI generated article was condescending and infuriating. Quite a difference apparently.

saagarjha4• 3 months ago

I feel like having an LLM write code in a language you aren't familiar with and then inspecting the results is kind of like hiring someone to speak Spanish for you and then being confused at the weird words they are using. Like, what would make you want to do this?

victorbjorklund4• 3 months ago

If you already speak French or another Romance language it isn’t a bad idea to just have a conversation in Spanish directly and then ask for clarifications anytime you don’t understand.

2ndorderthought13• 3 months ago

Which would be all the time? At which point you might be better served by learning from a source that has any guarantees of being correct and doesn't hallucinate. Like text books that have had several editions and are free on the Internet.

hnlmorg15• 3 months ago

Not the author but this seems a good approach to me because you learn more about a language from implementing a project in it. This is especially true when you already have experience in a language from the same paradigm (like Go and Rust are).

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.

2ndorderthought13• 3 months ago

Go and rust share very few similarities when you consider the syntax.

saagarjha4• 3 months ago

I would not say that Go and Rust have similar paradigms

jdub• 3 months ago

Nah, it's an awful way to learn. Especially to learn to be good or great.

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.

nothinkjustai6• 3 months ago

Except it generated bad unidiomatic code, so you’re just learning bad habits.

commandersaki• 3 months ago

Have you tried? Give it a shot and see for yourself.

saagarjha4• 3 months ago

Yeah I have had LLMs write scripts and changes in languages I can't really read for throwaway uses but I have not really found it useful to go and inspect the code because I don't feel I would learn much

atorodius• 3 months ago

That's a terrible analogy:)

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

saagarjha4• 3 months ago

Well it's an LLM so it's more like you ask your uncle Vinny who is pretty good at a bunch of stuff but sawed off their arm the other day

Culonavirus• 3 months ago

It's one of the best use cases for LLMs IMO. Programmers being empowered to do stuff they wouldn't dare before and/or do what they know, but faster. Having a person who never wrote much code (if any) before is a recipe for disaster because LLMs, even latest models with CC/Codex make mistakes and often code where a happy path (kinda) works, but edge cases don't . You have to check and iterate and specify. But also, programmers (seniors at the very least) have an intuition about how the system should work and they know algorithmization in general. They know how to do a thing in pseudocode on paper. In the end, you become kind of an architect of the system. LLMs give you the ability to choose the right tool for the job even if you have suboptimal or even very little experience with the given tool. There are footguns of course and I wouldn't work on say a system handling client money (banks...) this way, but most uses can take it.

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.

wiseowise• 3 months ago

Still better than deciphering C++ soup of characters.

cenamus• 3 months ago

std::expected and the utility functions for it (and_then(), or_else()) are pretty much the same, though? Or am I completely misunderstanding something?

irishcoffee• 3 months ago

No, you’re not, the person you replied to is failing to look at their own criticism objectively.

tialaramex• 3 months ago

It's true that `std::expected` is like if a C++ programmer saw a type like Result in a shop window and copied the parts they understood from that and so certainly if you're a C++ programmer this is superficially satisfying.

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.

xigoi• 3 months ago

Unfortunately, Rust made the great decision to copy most of its syntax from C++.

JKCalhoun• 3 months ago

From vibe coding we now seem to have… tray-table coding?

huqedato2• 3 months ago

Learning Go after five years of professional struggle with Rust was a relief; Go feels designed for humans to just get the job done. (not a Google fan!) I'll get a ton of downvote for this but it's ok.

2ndorderthought13• 3 months ago

I find your experience interesting. People below are saying you can understand rust super easy if you know go. Meanwhile you are saying rust was a struggle and go is a relief.

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.

huqedato2• 3 months ago

Yes: I do say Rust was a struggle and go is a relief. Yes: rust has very little in common with go. Yes: Rust is very explicit and go is not. Yes: Other people find go refreshing because the syntax is more limited and it looks simple on paper. So, you're right.

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

A Gopher Meets a Crab

Related Stories