Hacker News Reader

Comment by RcouF1uZ4gsC | Hacker News Reader

To determine how open a language really is look at how many widely used implementations of the compiler there are for the language. If there is only a single implementation of the compiler/interpreter than it is not really open but controlled by that core compiler team.

View on HN

Most languages I can think of have one very dominant implementation and maybe another one or two that few people use. Python, Ruby, Java, C#, Go, Rust, Haskell... C/C++ are the only exception since Clang became serious competition to GCC and Visual Studio. Even Javascript only really has Chrome and Firefox.

So, there's your answer right there.

That's "consumerization of IT" for you. Millenials and younger are used to looking at pretty websites of "language ecosystems" and blogs about trivial programming problems to assess languages, rather than independence, maturity, and long-term viability as they used to before, and as demonstrated by having language specs and multiple interworking implementations, pluralism of APIs, etc.

I don't think the number of implementations correlates strongly with long-term viability. As long as there is at least one FOSS implementation available the language won't die as long as it remains useful.

What about Intel's compiler for C++? Or Borland's? Or EDG's? Or DigitalMars? They were around for a long time.

They fall under "almost nobody uses them".

JS has Safari (JSC) as well.

I don't think that is necessarily true. Rust has only one compiler (and I think adding a second one would be a huge effort with no clear win) yet it is developed by a community that is very welcoming to newcomers. At least, that's been my experience.

It is definitely true. There's virtually no room for improving the underlying compiler toolchain because there's no allowance or support for an alternate implementation (using GCC, for example).

Go at least has gcc-go, which is a compliant implementation that gets some benefits from being part of GCC (like not completely broken support for dynamic link libraries!).

Having a second compiler implementation forces the language grammar and behavior to be specified in a formal manner that allows anyone to understand how it works.

How is there no allowance? A lot of people in the community would love a rust compiler that can compile down to C for instance.

Maybe the tool chain is hardcoded to use the standard compiler? But that's more likely because of YAGNI, not because the rust community hates freedom.

The toolchain is built on top of rustup which very purpose is managing multiple compilers. If one were to build a different rustc it could be swapped in even in the world we have today.

That's cool. I haven't used Rust yet so I didn't know.

I haven't thought consciously about that, but it turns out that I've been doing that kind of validation unconsciously. I didn't get interested in actally using D, for example, until the GDC variant arrived (Dlang-support in the GCC collection).

Gcc compiles Rust fine. Its borrow checker won't bark at you, but that doesn't affect code generation.

OCaml and Haskell are one-horse towns, with substantial history, that are not going away.

But as Stroustrup says, there are languages people complain about, and languages no one uses. You generally end up better off investing your time in mastering a language people complain about. Bitterly. Once that meant FORTRAN.

There are at least four Go compilers: the original one from google, GCC go, gollvm and GopherJS.

The TinyGo project are implementing a Go compiler on top of LLVM, to use Go on very small devices:

https://tinygo.org/

The Go language is defined by a spec with compatibility guarantees, but beyond embedded systems and WASM, there don't seem to be a lot of use cases for alternate implementations.

I haven't looked into compiling Go to JVM bytecode, but a solid way to do that would resolve an ongoing tug-of-war at work, and avoid a lot of résumé-driven development of stuff maven central already had.

Afaik GCC's Go has been pretty complete and up-to-date for a couple of years.

You mean for example various versions of java which are incompatible?! Or java programs said to be mtiplatform loading .so libraries of fixed Ubuntu versions? Well, that's exactly what I hate.

Reply on news.ycombinator.com