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
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.
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.”
The front page is perpetually full of crap. There just aren't always 30 interesting recent articles in the world, and that's fine. Don't worry about it too much.
