[hnlmorg]

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.

[2ndorderthought]

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

[hnlmorg]

If you believe that then you haven’t spent much time working in different paradigms of programming languages.

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.

[2ndorderthought]

I have written production code in about a dozen languages as well believe it or not.

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.

[hnlmorg]

> I have written production code in about a dozen languages as well believe it or not.

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.

[2ndorderthought]

The number depends on if you count html/css, bash, powershell, etc as programming languages.

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.

[saagarjha]

I would not say that Go and Rust have similar paradigms

[hnlmorg]

You’re conflating paradigms with idioms.

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

[2ndorderthought]

I think this comment weasels around the intent of the poster without acknowledging their meaning.

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.

[hnlmorg]

“Leaning into functional” isn’t a hard thing to learn. However pure functional is when coming from an imperative language.

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?

[2ndorderthought]

I don't think the differences between go and rust are minor.

You aren't starting from scratch in the same way that if you have written javascript you aren't starting from scratch writing c++.

[Ygg2]

They might share some paradigms (focus on low level optimization) but they aren't the same.

Go focuses on heavy runtime, looser type systems, and all the benefits and drawback that brings.

[hnlmorg]

That’s not what people mean when they talk about paradigms in programming languages.

[Ygg2]

Ok, but still they share some programming language paradigm, but not all. They both are imperative, concurrent and functional, but Rust is generic, Go is not. Rust is structured, Go is OO.

[hnlmorg]

...which is basically a convoluted way of agreeing with me that there is shared knowledge one can call upon when moving between those two languages.

[jdub]

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.

[hnlmorg]

> Reading slop code is a terrible way to build a mental benchmark for what's good

The days of AI only being capable of producing unreliable slop code are long gone.

[MrJohz]

And yet the examples in this post are of slop code, so clearly they're not that long gone.

[nothinkjustai]

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

[hnlmorg]

Can you share which parts of the code were bad?

[nothinkjustai]

Basically all of the code they shared in the article.

[hnlmorg]

You’ll need to be more specific than that. Why was it bad? How would you have written it differently?

[nothinkjustai]

Um, it’s pretty obvious why Result<Option<Result<Option<T>>>> or Result<(),()> is bad, I’m not going to spend time explaining when I doubt you’re asking in good faith.

[hnlmorg]

Of course I’m asking in good faith. I wouldn’t have asked how you’d implement the same problem yourself if I wasn’t interested.

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.