Hacker News Reader

Any complexity not covered over by the language will end up in the user's program.

Any complexity not covered over by the language will end up only in the programs that need it, as opposed to being included in every program. If the complexity is common enough, it's probably worth centralizing (like, say, an object system or type checking), but designing a language so that tricky things that 95% of code doesn't use have special support results in a language that will wow folks on the internet but piss off those using it for real large projects.

Bad culture/developers will screw up a project regardless of what language you use. You cannot prevent this by giving them successively castrated languages. They will still find ways to make things difficult because they don't know what they are doing. I like minimal languages from an aesthetic perspective, but ultimately they're just tools. The second they prevent me from expressing my intent as cleanly as possible, I become much less impressed by any claims they made about purity.

The defer statement is certainly Go-esque, but not as clean as RAII, because I can still forget to write the defer statement after opening a file. This violates DRY when doing file I/O. You can argue that Go never purported to support these concepts in the first place, but, at the end of the day, I'm writing code over and over again needlessly. Not elegant in the slightest.

Disagree and I have a very prominent argument, C.

Reply on news.ycombinator.com