Hacker News Reader

Comment by Retric | Hacker News Reader

In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act.

The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.

View on HN

> In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act.

This is the problem though - I think many people expect there to be a "one language to rule them all". Personally I like having lots of different languages that excel at some problems even if that means they fall short at other problems. But I think some people either want to specialise in a specific language, or spend so much time looking for perfection that they miss subtle beauties amongst a forest of flaws.

It's OK to see a language that has certain strengths but also some weaknesses due to the nature of the strengths.

It's sad to see a language that has certain strengths but also some painful weaknesses for no good reason except that it's v.1. So far the best I've heard is something like "We understand there's a problem for certain users, and we don't rule out adding generic types some time later, but it's hard and our priorities are different". It is indeed not easy to do well (though Java has somehow managed to find a satisfactory solution).

Well, I'll wait a few more years.

I think the language that wanted "to rule them all" was C++, and we all know how it ended. C++ can be procedural, oop, functional, you have metaprogramming, generics, everything. Everything. C++ is everything. Every pattern, every design philosophy can be implemented in C++. How much time does it take to compile? How many developers do know every C++ feature and pattern?

I don't really see how Go is, or should be, that limited as a factor of design (in contrast with something like Erlang). It's just that everyone in the ecosystem is focused on on the same things and when people with other use cases, that could benefit from the properties of the language, try to make themselves known it's all "works for me".

Edit: Thanks for proving my point everyone.

Edit2: To be slightly less snarky, despite the article I don't see any reason why Go couldn't be a fit for e.g. an oscilloscope which today is running a complete, often multi-core, linux system with 100k+ lines of code (with help from an ADC and FPGA etc. of course). If it wasn't for the fact that few people would undertake such an effort when that would be akin to swimming upstream against the ecosystem.

By this measure, isn't C worse?

Even with C, you can do some type safeish data structures using macros.

I think that your view, while true, misses the point (or doesn't make it explicit enough): tools are what really matter, languages are simply less important and ultimately interchangeable.

I'm not understanding SQL as an accident of history, can you explain?

SQL was the query language of the first major commercially successful RDBMSs (from IBM, who developed the language, and Oracle) -- which weren't the first two RDBMSs, and were arguably successful for reasons largely unrelated to the query language chosen -- and became the de facto standard because of that. So, yeah, I can see the "historical accident" there.

The ideas behind SQL started with Codd's relational algebra, which has some very large differences from SQL. See https://en.wikipedia.org/wiki/Relational_algebra for more. Query languages were developed based on that.

However as https://en.wikipedia.org/wiki/SQL documents, a team at IBM implemented something called System R (R for Relational) with a query language called SEQUEL that was renamed to SQL for trademark reasons. Then Relational Software (now Oracle) implemented a database that could run on non-IBM software, and made their query language mostly compatible with IBM's so people could port to their database. And everyone who came after has made their implementations compatible for the same market reason that Oracle originally did.

Even today there are people who want to return to some of the ideas that Codd had which SQL does not implement. But there is such momentum around SQL that it is unlikely to ever happen.

Reply on news.ycombinator.com