Rust front-end merged in GCC trunk • Hacker News Board

Re: Rust front-end merged in GCC trunk

#131

Post by Shish2k » Thu, Dec 15, 2022, 8:58 PM UTC

nine_k wrote: post #87

bayindirh wrote: post #80

Earlier quoted context omitted.

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.

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

Re: Rust front-end merged in GCC trunk

#132

Post by 3836293648 » Fri, Dec 16, 2022, 11:47 PM UTC

nine_k wrote: post #83

3836293648 wrote: post #69

Earlier quoted context omitted.

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.

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

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

Re: Rust front-end merged in GCC trunk

#133

Post by 3836293648 » Sat, Dec 17, 2022, 11:59 PM UTC

rob74 wrote: post #73

3836293648 wrote: post #69

Earlier quoted context omitted.

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.

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.

Re: Rust front-end merged in GCC trunk

#134

Post by nbjoerg » Sun, Dec 18, 2022, 5:22 PM UTC

m_nyongesa wrote: post #90

bayindirh wrote: post #60

Earlier quoted context omitted.

It's mostly a personal choice. Any piece of software I write is opened up, and licensed with GPL. I don't want my software dependent on a non-GPL toolchain to ensure its long term sustainability. I also try to choose GPL licensed libraries, and include everything required to build my code (incl. external libraries) inside my repository. In the end I want someone to be able to just clone the repo, and run make, or GCC…

I upvoted you. I have no idea why your comment received downvotes. I responded in a similar way to a conversation about Julia less than a week ago. For people who have trouble understanding this reasoning, a message from the GCC mailing list ( https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html ) provides some of the explanation, which I reproduce here: In the free software movement, we campaign for the freedom o…

The irony of Richard's decision and justification is how misguided it was (and is) on multiple fronts.

First, GCC as a whole has never been technically superior to the commercial competition. The reason why GCC was popular outside the GNU crowd and received as much funded development is that it was the best compiler across a range of popular platforms and had the best price, too.

Second, one of the main drivers behind the creation of clang has been the hostility to making the C/C++ frontend of GCC usable as a standalone tool. Richard explicitly wanted to force everyone to either deal with the GPL and his interpretation of what is derived work, or shell off the bucks for the Edision Design Group. This was a calculated choice as no one would want to invest the time to write another C/C++ frontend, right? He intentionally ignored all other use cases for C/C++ parser as a library (Language server, anyone? Refactoring tools?) and thereby actually hurt the user base on the GNU platform just as well. It can not be understated how disruptive clang was as a set of libraries outside the LLVM/clang compiler.

Third, GCC had as middle and backend compiler always was moderately accessible, but by structure somewhat harder to access for researchers or people wanting on special purpose tools like optimized code generation for computational kernels on matrixes.

GCC was forced to acknowledge the competition by finally getting a plugin interface in the GCC 4.5 days, but at that point, the cat was out of the bag.

Re: Rust front-end merged in GCC trunk

#135

Post by mlindner » Mon, Dec 19, 2022, 6:17 AM UTC

c0l0 wrote: post #94

Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?

I would naively assume that it doesn't affect it at all. Compiling with GCC doesn't magically make dynamic linking better. The limitation in dynamic linking is an element of language design.

I'd also note that any Rust you compile with GCC probably shouldn't be dynamically linked with Rust code compiled with rustc.