31–40 of 79 posts
Earlier quoted context omitted.
Off topic but using “shape” like this is LLM coded
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.
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?
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.
Earlier quoted context omitted.
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.
Go and rust share very few similarities when you consider the syntax.
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 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?
Have you tried? Give it a shot and see for yourself.
The weird-looking Rust isn’t really Rust being weird, it’s the type telling the truth. Result >, 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…
Off topic but using “shape” like this is LLM coded
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?
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
Still better than deciphering C++ soup of characters.
std::expected and the utility functions for it (and_then(), or_else()) are pretty much the same, though? Or am I completely misunderstanding something?
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.
Earlier quoted context omitted.
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.
I would be very surprised if you couldn’t figure out what was happening in one C-derivative language when you’re already competent in another C-derivative language. 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...
Earlier quoted context omitted.
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.
I would not say that Go and Rust have similar paradigms
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