Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Gopher Meets a Crab

miren.dev

Post reply on HN
Print view View original

51–60 of 79 posts

Re: A Gopher Meets a Crab

#51

Post by 2ndorderthought »

hnlmorg wrote: post #48
2ndorderthought wrote: post #47

Earlier quoted context omitted.

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.

“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 su…

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

Re: A Gopher Meets a Crab

#52

Post by 2ndorderthought »

huqedato wrote: post #50
2ndorderthought wrote: post #45

Earlier quoted context omitted.

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 l…

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 c…

I am glad you found something that works for you. Go forth and gopher it up

Re: A Gopher Meets a Crab

#53

Post by jdub »

hnlmorg wrote: post #27
saagarjha wrote: post #12

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.

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.

Re: A Gopher Meets a Crab

#54

Post by 2ndorderthought »

saagarjha wrote: post #44
atorodius wrote: post #36

Earlier quoted context omitted.

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

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

After sawing off his arm while assembling an barstool he also gives advice about assembling rocket engines without any loss in confidence. Good old uncle Vinny always there when you need him.

Re: A Gopher Meets a Crab

#55

Post by 2ndorderthought »

hnlmorg wrote: post #43
2ndorderthought wrote: post #38

Earlier quoted context omitted.

The first time I looked at rust code that wasn't in tutorial I was pretty confused. Things I thought I understood I really didn't. I knew maybe 6 programming languages including some c. A lot of people struggle to learn rust because it's an ML as in OCAML and really isn't much like C at all. Some people adapt to it more easily, especially coming from languages like scala but it has a lot of unique characteristics tha…

Scala is a great language. And Rust definitely has noticeable influences from ML. But I’d say Rust is closer to C++ than it is to ML. But, to be fair to you, I’ve not touched Rust in a couple of years so maybe my memory is fallible here?

I don't think it's a memory thing. The original rust compiler was written in OCAML. I think it's closer to an ML personally because of the strong focus on the type system rather than the chr* magic of c/c++.

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.

Re: A Gopher Meets a Crab

#56

Post by hnlmorg »

jdub wrote: post #53
hnlmorg wrote: post #27

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.

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"…

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

Re: A Gopher Meets a Crab

#57

Post by hnlmorg »

2ndorderthought wrote: post #55
hnlmorg wrote: post #43

Earlier quoted context omitted.

Scala is a great language. And Rust definitely has noticeable influences from ML. But I’d say Rust is closer to C++ than it is to ML. But, to be fair to you, I’ve not touched Rust in a couple of years so maybe my memory is fallible here?

I don't think it's a memory thing. The original rust compiler was written in OCAML. I think it's closer to an ML personally because of the strong focus on the type system rather than the chr* magic of c/c++. 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 O…

I think the crux of our disagreement is this:

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.

Re: A Gopher Meets a Crab

#58

Post by Ygg2 »

hnlmorg wrote: post #39
saagarjha wrote: post #32

Earlier quoted context omitted.

I would not say that Go and Rust have similar paradigms

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

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.

Re: A Gopher Meets a Crab

#59

Post by Culonavirus »

saagarjha wrote: post #12

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

Re: A Gopher Meets a Crab

#60

Post by hnlmorg »

Ygg2 wrote: post #58
hnlmorg wrote: post #39

Earlier quoted context omitted.

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

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.

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