A Go compiler, written in Rust (2016) | Hacker News Reader

A Go compiler, written in Rust (2016)

github.com

85 pointsphilonoist19 comments

I upvoted because this is interesting and I like simple compilers, but unless I'm missing something, this is only a lexer and parser. They mention "rgo was to use LLVM" in the README, and there's no type checker or compiler right now as far as I can tell. See the src directory: https://github.com/yberreby/rgo/tree/master/src

Document states "was to" use, which for me sounds it does not yet use.

Author here. You're correct. I started this when I was getting into formal languages / compiler design, but I couldn't dedicate much time to it after writing the lexer and parser. Later on, I didn't have much interest in finishing it, in large part due to a growing dislike for Go's design philosophy. It was a nice learning experience, though.

Maybe archive the project? No shame in that game it shows clear intent

Good idea. Just did so.

Good to know, thanks. Out of interest, why do you dislike Go's design philosophy? I can guess, but I'm interested to hear your take.

I didn't pay much attention to recent evolutions of the language, so most of what follows is what motivated me to steer clear of Go in the past.

I think the prevalent attitude in the Go community towards complexity is harmful. Trying to get rid of over-abstraction is a laudable goal, but this can backfire when you're dealing with irreducible complexity.

For many years, the standard response when needing genericity was either `go generate`, `interface{}` or "copy-paste and adapt." In my opinion, generating code should be a last resort, because it is too powerful: generated code can do pretty much anything, whereas abstractions encoded in the type system have the benefit of being predictable. `interface{}` means giving up on type safety, and copying and pasting, while it can be justified in simple cases, does not scale. Go's lack of generics became something of a meme or a point of pride, depending on who you ask, and it has gotten more than enough discussion, so I'll leave it at that. N.B.: I'm aware that Go finally ended up implementing generics.

Additionally, after using sum types in other languages (Rust/OCaml/Haskell/Swift), I really miss them whenever I'm using a language that doesn't support them. Not being able to simply encode mutually-exclusive representations using the type system is a shame.

Add to this a general disdain of the community for anything that is perceived as "too abstract" - a sort of reverse-elitism, where reaching for advanced constructs means you're not "in." It's not a bad attitude to fight back against over-engineering, but I think it sometimes goes too far. This is subjective, of course.

What initially got me interested in Go was the promise of a simple, fast, modern language. I think it fulfills the first two criteria rather well, but falls short on the last one. And I don't mean "modernity" in the sense of "whatever's shiny nowadays" - I mean it in the sense of learning from common sources of bugs and giving the programmer tools to avoid them.

Remove too much complexity from the language, and you might just shift it to the programmer.

Also see the more recently updated https://github.com/oxfeeefeee/goscript, “An alternative implementation of Golang specs, written in Rust for embedding or wrapping.”

Could you please post this as your own post as well or permit me to post this as a separate post to be discussed upon?

Try this one: https://news.ycombinator.com/item?id=35851677

Feel free to resubmit, it was submitted in the past. I’m too lazy to submit it as its own post. I'm also not the author.

Should name it blasphemy

gore

Oh yeah, that is good.

Someone just got a Hacker News bingo.

Waiting for a Rust compiler, written in Go.

I think its hard not because Go or Rust is bad, but because there is no standard for rust, but afaik that is being worked on.

Reply on news.ycombinator.com