On Mon, 02 May 2016, Bobby Powers <bobbypow...@gmail.com> wrote: > Go is a _much_ simpler language than C.
And yet it still includes a fair share of insanity. The binary size is not an effect of some random silly magic #ifdef MAKE_BULKY, it's the effect of linking the userspace scheduler, GC, and Ken knows what else in each and every "hello" program. > The _implementation_ of Go is less simple, as it includes a userspace > scheduler and low-latency GC, but I don't know how you would expect to > add seatbelts to C or assembly and not increase _eiter_ the language > _or_ implementation complexity. I did not imply deriving the new hypothetical language directly from C. I did not suggest it would be simpler or equally simple to C or Go or whatever - while there's definitely some stuff you can cut out from C, adding features is adding features; especially if you're talking about making them optional. What I did try to suggest, when calling out Go: - I do not see a scheduler and syntax-level support for green threads, channels, etc as value, only baggage. It's been done as a library long before[1], and it was good enough - I'd even say better in few places; you didn't have to use reflection to alt on an array of channels. - For a language that states as its primary goal to make programs simpler, it fails miserably as soon as you need to introduce custom abstractions. For a tiny, simple, albeit not so close-to-the-metal language that proves even complex custom abstractions can be powered by simple primitives, do check out R5RS[2]. Even C has a standard (if sucky) way of abstracting repetitive code: the preprocessor. Go's current recommendation is to either copy-paste, or push it to the toolchain (see Qt's MOC to get an idea of where the latter leads to). So for the sole purpose of being a saner / safer C, and little else... Go fails. [1]: http://man.cat-v.org/plan_9/2/thread [2]: http://www.schemers.org/Documents/Standards/R5RS/HTML/ Sorry for the rant, I promise my next post will have PoC code in it. K.
