[sa-code]

> Basically, why try to make Go more like Rust when Rust is right there?

The avg developer moves a lot faster in a GC language. I recently tried making a chatbot in both Rust and Python, and even with some experience in Rust I was much faster in Python.

Go is also great for making quick lil CLI things like this https://github.com/sa-/wordle-tui

[thomashabets2]

No doubt a chatbot would be built faster if using a less strict language. It wasn't until I started working on larger Python codebases (written by good programmers) that I went "oh no, now I see how this is not an appropriate language".

Similar to how even smaller problems are better suited for just writing a bash script.

When you can have the whole program basically in your head, you don't need the guardrails that prevent problems. Similar to how it's easy to keep track of object ownership with pointers in a small and simple C program. There's no fixed size after which you can no longer say "there are no dangling pointers in this C program". (but it's probably smaller than the size where Python becomes a problem)

My experience writing TUI in Go and Rust has been much better in Rust. Though to be fair, the Go TUI libraries may have improved a lot by now, since my Go TUI experience is older than me playing with Rust's ratatui.

[LtdJorge]

I've also found that traversing a third-party codebase in Python is extremely frustrating and requires lots of manual work (with PyCharm) whereas with Rust, it's just 'Go to definition/implementation' every time from the IDE (RustRover). The strong typing is a huge plus when trying to understand code you didn't write (and I'm not talking LLM-generated).

[phplovesong]

sounds like a ide-noob theme song

[zozbot234]

> moves a lot faster in a GC language

Only in the old "move fast and break things" sense. RAII augmented with modern borrow checking is not really any syntactically heavier than GC, and the underlying semantics of memory allocations and lifecycles is something that you need to be aware of for good design. There are some exceptions (problems that must be modeled with general reference graphs, where the "lifecycle" becomes indeterminate and GC is thus essential) but they'll be quite clear anyway.

[wavemode]

> Only in the old "move fast and break things" sense

No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes.

I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax type systems where you have to tiptoe around nulls. Many are quite strict and are definitely not "move fast and break things" type if languages.

[bigbadfeline]

Rust does have GC in external crates, one was used for implementing Lua in Rust.

A Lua interpreter written in Rust+GC makes a lot of sense.

A simplified Rust-like language written in, and compiling to, Rust+GC makes a lot of sense too.

A simplified language written in Rust and compiling to Go is a no-go.

[thomashabets2]

Well if you think Java doesn't have a sufficiently good type system, then surely Go is even further from one?

Not saying those are the only two GC languages, just circling back to the post spawning these comments.