Hacker News Reader

Comment by rayiner | Hacker News Reader

Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes. GCC has a ton of development resources behind it; processor makers are familiar with it and often turn to it to bring up new processors and ISAs, etc. Having a GCC front end is a big step in Rust becoming more popular as a systems language.

View on HN

This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

Oh, “only C/C++ people.” I.e. the people who wrote almost all the systems code in the last 40 years. Just those people.

> Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes.

I think that's what the parent was replying to, not somehow claiming C/C++ people are insignificant.

The catastrophe was that the C/C++ specification left too many things open for interpretation. Regarding "Only C/C++ people": there is at least one more language (Go) that has two implementations (the gc compiler and a gcc backend).

I didn't say only C/C++ had several implementations, I said that only the C/C++ communities care about their alternate implementations. The python community looks at pypy like a weird novelty and doesn't use it. The JavaScript community is often actively hostile to SpiderMonkey (firefox) and JavaScriptCore (Safari). As far as I've seen, GccGo is mostly ignored.

Somehow Python people, Java people, Ruby people, JavaScript people managed to produce multiple independent high-quality implementations.

On top of that, there so many lisp implementations, it's not even funny anymore.

python has 1.5 implementations pypy is close, but not that close to being a complete implementation.

Jython is pretty complete though, and IronPython is not completely dead.

Micropython can be counted as 0.25 or something :)

There's a difference between having multiple implementations, even high quality ones, and caring about it. Python is all about the reference implementation, as much as I wish that people cared about pypy and the JS community has always been openly hostile to SpiderMonkey compatibility and only cares about V8 in my experience. And Java is all about different forks of the same jdk, even if several actually independent different ones used to exist.

I will admit to not being familiar enough with Ruby to say anything about that

> This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

This comment is so blatantly wrong and detached from reality that it makes me wonder if it's just a good old fashioned troll.

You'd be hard-pressed to find any production programming language which does not have multiple independent implementations.

> Because single implementation languages are toys

‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

> ‶Toys″ like Go

https://gcc.gnu.org/onlinedocs/gccgo/

Honestly curious, I know it exists, just like there used to be GCJ, but have you seen it being actually used?

Go has a GCC implementation (which I use).

PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho.

Kotlin runs on JVM, which has at least three fully compliant implementations.

Erlang is a specialized language and telecommunications platform. It’s something different.

> PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho.

Well, if they are not public, it does not really have any influence on language specification.

> Kotlin runs on JVM, which has at least three fully compliant implementations.

And Rust runs on x86 which has myriad of implementations; still, we're talking about the language compiler, not the underlying runtime.

> Erlang is a specialized language and telecommunications platform. It’s something different.

How so? It's a language built over a runtime, just like Java. I don't see how the specifics of the runtime have to do with anything.

For PHP, there is HVVM which, AFAICT, can run vanilla PHP and is open.

TruffleRuby is a thing, as is JRuby.

Implementing Erlang without implementing its VM and the whole infrastructure, which is a much larger task than merely a VM like Python's.

HHVM dropped vanilla-PHP compatibility after PHP7 started coming close to it in performance (which was the top reason anyone used HHVM to serve vanilla-PHP code) - now they’re focussing on Hacklang which, no longer shackled by the need to be bug-compatible with PHP’s awful design decisions, is free to become a better language

Also artichoke ruby https://www.artichokeruby.org/

Kotlin is a prime example. You have to download the vendor implementation. There's no way to bootstrap. It's horrible from a tooling perspective.

Any single-implementation language inevitably degrades to the point where the implementation becomes the specification. Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors. That's a bad situation to be in.

I don't see how the bootstrapping problem is linked to multiple implementations.

> Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors.

Perl, well-known for being an iffy language to install and running on a restricted set of OS/architectures.

Multiple implementations brought only trouble and frustration to the masses and endless opportunities for companies to exploit feature lock-ins (borland anyone?) . If anything drives people mad more than anythong are gcc vs clang vs msvc vs this or that issues. Just the whole complex numbers or quad precision issue is the best example from math handling. It is basically very unsuccessful stakeholder management to say the least. One of the main reasons for us to switch to Rust is not having multiple implementations.

Reply on news.ycombinator.com