Uh, what? Haskell already compiles to native code, and is faster than Go in many cases.
Also, if you were implementing a programming language, there are much better languages to do it in than Go.
Also, if you want to implement a compiler, and not an interpreter, the host language having GC is not very useful to get GC.
Haskell is going to make working with ASTs much easier and safer. It also has a superset of the concurrency features of Go.
http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go
Also, the type-switch on interface {} is ugly.
Consider how an AST looks like in Haskell:
data AST
= LiteralInt Int
| LiteralFloat Float
| List [AST]
...
case ast of
LiteralInt int -> ...
LiteralFloat float -> ...
List nodes -> ...
Also, if you add an annotation to each AST element (e.g: inferred types), you can very easily and safely map over them, etc.
Well, not that small, i guess :-)
You also don't have the ability to write a GC-less language, because there is no practical way to write non-GCed Go code.
>you can incorporate a few nice concurrency features with little effort
You also can't implement any custom OS-level concurrency features.
True, so you probably don't want to do that.
You also can't implement any custom OS-level concurrency features.
True. But for "journeyman" level language implementation, the toolset is quite good.
No, you really don't. The built-in GC is nothing like the GC needed for lots of other languages.
Don't write those languages in Go.
Not to mention that to use the GC, you'd have to carry the whole baggage of Go's runtime with you in the new language. And that's Go's GC is not that good in the first place.
* the indexing makes a map[something]boolean act like a set. Sets and maps are so similar it always felt wrong for them to be two separate constructs.
* making exported functions/vars/etc begin with a capital letter. When naming important stuff, it's a relief not worrying about naming conflicts with keywords. When naming locals, just use i,j,p,q,p2 anyway.
* using defer and recover instead of catch and finally. The catch clause is really two functionalities rolled into one and using defer and recover decomplects them.
Other languages should copy those.
What I'm concerned about...
* printf and regex notation are used so much they're really part of the language, but have an entirely separate syntax embedded within strings which must be learnt. But unlike the rest of Go's syntax, they're unintuitive, especially regexes for Unicode. Unicode is meant to be one of Go's strengths. I understand quick parsing is one of Go's primary reason's for existing, but the regex and printf notations could have been cleaner. When you think about it, why are the arithmetic and bitwise operators generally part of a language's primary syntax, but string matching and formatting delegated to sub-languages?
* statements, like if/else and ++/--, don't return values in Go which is hard to get used to. I understand making statements generally be shorter so the code looks good after running through gofmt could have motivated this.
Overall, I think Go's a systems language intended for quick parsing and eliminating C++'s complexity, and the author's comparing it to languages with far higher level constructs. The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible.