Hacker News new | ask | show | jobs
by sytelus 2227 days ago
This is very weak argument. Once these restrictions are embedded in language, it cannot be removed by anyone. On the other hand, same thing can be accomplished by using company-wise style enforcers. If you think that is harder, I'd say forcing every project in big company to use same language is even more harder.

My main quip with Go is that its rather more of the same but more poorly done in the name of minimalism. Extreme minimalism is as bad as extreme richness. The entire art of language design is achieving just the right balance for a specific audience and set of goals.

2 comments

But "company wide linters" do carry over to other companies and projects. For Go its already set up, you dont have to think about it. Otherwise youll have a week (or more) discussion for every single quirk in the language and how one would format that and try to apply this to a group of people.

I'd call them more like working standards. Imagine having to discuss how to make a brick wall everytime you need to make one. Things like having a masonry cord (which can equal to a "gutter", line length restriction) and the mixture of the cement, are critical for execution in a team of more than 1 person, and not following standards will make a hacked up job.

s/do carry/do not carry/
> On the other hand, same thing can be accomplished by using company-wise style enforcers

But you can't do that with open-source libraries. When I use an open source library, I can audit its code very easily, and this is not always true with other languages. The more complex the language, the harder it is to audit it. There are many C++ open source libraries (hello Boost) I can't understand because they don't use the dialects I'm used to.