Rust GCC backend: Why and how

172 pointsposted 15 hours ago
by ahlCVA
(blog.guillaume-gomez.fr)

97 Comments

mastax

14 hours ago

> On that note: GCC doesn't provide a nice library to give access to its internals (unlike LLVM). So we have to use libgccjit which, unlike the "jit" ("just in time", meaning compiling sub-parts of the code on the fly, only when needed for performance reasons and often used in script languages like Javascript) part in its name implies, can be used as "aot" ("ahead of time", meaning you compile everything at once, allowing you to spend more time on optimization).

Is libgccjit not “a nice library to give access to its internals?”

compiler-guy

11 hours ago

To use an illustrative (but inevitably flawed) metaphor: Using libgccjit for this is a bit like networking two computers via the MIDI protocol.

The MIDI protocol is pretty good for what it is designed for, and you can make it work for actual real networking, but the connections will be clunky, unergonomic, and will be missing useful features that you really want in a networking protocol.

aargh_aargh

6 hours ago

Or, the obligatory RFC 1149 (IP over Avian Carriers).

jacquesm

6 hours ago

Oh come on, SLIP over MIDI is tried and true.

compiler-guy

6 hours ago

Note the word order here.

Googling “slip over midi” gives a lot of fashion blogging about mini dresses and slips that one wears under them, so I’m not quite sure what you mean.

But if you mean “midi over slip”, then that is the inverse case from what I am suggesting. Midi over slip (and slip could be any tcpip substrate, such as ethernet) has midi messages as the payload, carried via tcpip.

I’m talking about using midi messages to carry tcpip payloads. You can absolutely do it, but it isn’t really what the protocol is designed for.

jacquesm

3 hours ago

No, I meant it exactly like that SLIP over MIDI. I know there are plenty of MIDI over TCP/IP and UDP implementations but that's not what I had in mind.

And what google turns up when you enter those exact three words in a row is really none of my business.

https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

https://en.wikipedia.org/wiki/MIDI

compiler-guy

20 minutes ago

I used SLIP all the time back in the day, and I use MIDI all the time in my home music setup. The wikipedia articles don't tell me anything I don't already know.

I suppose someone somewhere has done it (and I have always said that you can), but my best internet searches with a wide variety of terms don't show any old tutorials or products that explain how. Nor can I find anything else that uses MIDI to send tcpip packets over the MIDI connection. Not even a mention.

My Google-fu may be totally weak, but whatever.

I freshly, happily and totally concede that people have in the past used MIDI to send SLIP packets. Great. You are totally correct.

But all of this just proves the original point--given that no one does it any more. And apparently this either precedes anything on the internet today, or is so obscure that no search engine can find it, I think it is pretty fair to conclude that it is rather unergonomic, and hacky, and doesn't provide all the features one really wants in a network connection.

No one uses it unless they don't have another alternative.

saghm

14 hours ago

I could be wrong, but my surface level understanding is that it's more of a library version of the external API of GCC than one that gives access to the internals.

LukeShu

11 hours ago

libgccjit is much higher level than what's documented in the "GCC Internals" manual.

keyle

15 hours ago

If the author reads this...

I'd be very interested if the author could provide a post with a more in depth view of the passes, as suggested!

petcat

14 hours ago

> Little side-note: If enough people are interested by this topic, I can write a (much) longer explanation of these passes.

Yes, please!

grokx

13 hours ago

When I studied compiler theory, a large part of the compilation involved a lexical analyser (e.g. `flex`) and a syntax analyser (e.g. `bison`), that would produce an internal representation of the input code (the AST), used to generate the compiled files.

It seems that the terminology as evolved, as we speak more broadly of frontends and backends.

So, I'm wondering if Bison and Flex (or equivalent tools) are still in use by the modern compilers? Or are they built directly in GCC, LLVM, ...?

eslaught

12 hours ago

The other answers are great, but let me just add that C++ cannot be parsed with conventional LL/LALR/LR parsers, because the syntax is ambiguous and requires disambiguation via type checking (i.e., there may be multiple parse trees but at most one will type check).

There was some research on parsing C++ with GLR but I don't think it ever made it into production compilers.

Other, more sane languages with unambiguous grammars may still choose to hand-write their parsers for all the reasons mentioned in the sibling comments. However, I would note that, even when using a parsing library, almost every compiler in existence will use its own AST, and not reuse the parse tree generated by the parser library. That's something you would only ever do in a compiler class.

Also I wouldn't say that frontend/backend is an evolution of previous terminology, it's just that parsing is not considered an "interesting" problem by most of the community so the focus has moved elsewhere (from the AST design through optimization and code generation).

nextaccountic

9 hours ago

Note that depending on what parsing lib you use, it may produce nodes of your own custom AST type

Personally I love the (Rust) combo of logos for lexing, chumsky for parsing, and ariadne for error reporting. Chumsky has options for error recovery and good performance, ariadne is gorgeous (there is another alternative for Rust, miette, both are good).

The only thing chumsky is lacking is incremental parsing. There is a chumsky-inspired library for incremental parsing called incpa though

estebank

8 hours ago

If you want something more conservative for error reporting, annotate-snippets is finally at parity with rustc's current custom renderer and will soon become the default for both rustc and cargo.

ajb

9 hours ago

GLR C++ parsers were for a short time in use on production code at Mozilla, in refactoring tools: Oink (and it's fork, pork). Not quite sure what ended that, but I don't think it was any issue with parsing.

fithisux

12 hours ago

I disagree. It is interesting, that is why there many languages out there without an LSP.

brooke2k

13 hours ago

Not sure about GCC, but in general there has been a big move away from using parser generators like flex/bison/ANTLR/etc, and towards using handwritten recursive descent parsers. Clang (which is the C/C++ frontend for LLVM) does this, and so does rustc.

afdbcreid

10 hours ago

I don't know a single mainstream language that uses parser generators. Python used to, and even they have moved.

AFAIK the reason is solely error messages: the customization available with handwritten parsers is just way better for the user.

gpderetta

13 hours ago

I believe that GCC also moved to a handwritten parser, at least for c++, a couple of decades ago.

pklausler

12 hours ago

Table-driven parsers with custom per-statement tokenizers are still common in surviving Fortran compilers, with the exception of flang-new in LLVM. I used a custom parser combinator library there, inspired by a prototype in Haskell's Parsec, to implement a recursive descent algorithm with backtracking on failure. I'm still happy with the results, especially with the fact that it's all very strongly typed and coupled with the parse tree definition.

astrange

5 hours ago

Compiler theory a) doesn't seem to have much to do with production compilers b) is unnecessarily heavyweight and scary about everything.

In particular, it makes parsing everything look like a huge difficult problem. This is my main problem with the Dragon Book.

In practice everyone uses hacky informal recursive-descent parsers because they're the only way to get good error messages.

jojomodding

10 hours ago

This was in the olden days when your language's type system would maybe look like C's if you were serious and be even less of a thing when you were not.

The hard part about compiling Rust is not really parsing, it's the type system including parts like borrow checking, generics, trait solving (which is turing-complete itself), name resolution, drop checking, and of course all of these features interact in fun and often surprising ways. Also macros. Also all the "magic" types in the StdLib that require special compiler support.

This is why e.g. `rustc` has several different intermediate representations. You no longer have "the" AST, you have token trees, HIR, THIR, and MIR, and then that's lowered to LLVM or Cranelift or libgccjit. Each stage has important parts of the type system happen.

quamserena

13 hours ago

Not really. Here’s a comparison of different languages: https://notes.eatonphil.com/parser-generators-vs-handwritten...

Most roll their own for three reasons: performance, context, and error handling. Bison/Menhir et al. are easy to write a grammar and get started with, but in exchange you get less flexibility overall. It becomes difficult to handle context-sensitive parts, do error recovery, and give the user meaningful errors that describe exactly what’s wrong. Usually if there’s a small syntax error we want to try to tell the user how to fix it instead of just producing “Syntax error”, and that requires being able to fix the input and keep parsing.

Menhir has a new mode where the parser is driven externally; this allows your code to drive the entire thing, which requires a lot more machinery than fire-and-forget but also affords you more flexibility.

wrs

11 hours ago

If you're parsing a new language that you're trying to define, I do recommend using a parser generator to check your grammar, even if your "real" parser is handwritten for good reasons. A parser generator will insist on your grammar being unambiguous, or at least tell you where it is ambiguous. Without this sanity check, your unconstrained handwritten parser is almost guaranteed to not actually parse the language you think it parses.

peterfirefly

5 hours ago

Mostly because that's the part that had the best developed theory so that's what tended to be taught.

The rest of the f*cking owl is the interesting part.

umanwizard

12 hours ago

"Frontend" as used by mainstream compilers is slightly broader than just lexing/parsing.

In typical modern compilers "frontend" is basically everything involving analyzing the source language and producing a compiler-internal IR, so lexing, parsing, semantic analysis and type checking, etc. And "backend" means everything involving producing machine code from the IR, so optimization and instruction selection.

In the context of Rust, rustc is the frontend (and it is already a very big and complicated Rust program, much more complicated than just a Rust lexer/parser would be), and then LLVM (typically bundled with rustc though some distros package them separately) is the backend (and is another very big and complicated C++ program).

MerrimanInd

5 hours ago

Another reason to have a second compiler is for safety-critical applications. In the assessment of safety-critical tools if something like a compiler can have a second redundant version then each one of them can be certified to a lower criticality level since they'll crosscheck each other. When a tool is single-sourced the level of qualification goes up quite significantly.

steveklabnik

2 hours ago

rustc (via Ferrocene) is already being qualified, and form what I hear it’s been fairly easy to do so, for various reasons.

MerrimanInd

an hour ago

Yeah it is and that's a great effort, I've worked with that team on various things. But the industry is still itching for a second compiler with no crossover (can't just be another LLVM frontend or rustc fork) for those certification reasons. Not that people want to replace rustc! It's just a cert requirement.

notepad0x90

8 hours ago

I would just like to encourage all Rust devs to distribute binaries. No matter what compiler you choose, or what Rust version, users shouldn't have to build from source. I mostly see this with small projects to be fair.

MangoToupe

15 hours ago

I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.

1718627440

13 hours ago

It is a political not a technical decision. Essentially the same like the Linux kernel not encouraging the use of out-of-tree kernel modules. https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html

surajrmal

13 hours ago

And it shows how silly the idea is. gcc still sees plenty of forks from vendors who don't upstream, and llvm sees a lot more commercial participation. Unfortunately the Linux kernel equivalent doesn't exist.

leoc

11 hours ago

It's also nakedly hypocritical behaviour on Stallman's part. Hoping (whether in vain or not) that GCC being Too Big to Fork ( https://news.ycombinator.com/item?id=6810259 ) will keep people from having access to the AST interface really isn't substantially different from saying "why do you need source code, can't you just disassemble the binary hahaha".

eikenberry

10 hours ago

I wouldn't call Linux's stance silly. A working OS requires drivers for the hardware it will run on and having all the drivers in the kernel is a big reason we are able to use Linux everywhere we can today. Just like if they had used a more permissive license, we wouldn't have the Linux we do today. Compare the hardware supported by Linux vs the BSDs to see why these things are important.

hedgehog

13 hours ago

There are several open BSDs.

umanwizard

13 hours ago

AFAIK there's no evidence to suggest that permissive vs. copyleft license is the reason for the relative lack of success of the BSDs vs. Linux.

chuckadams

10 hours ago

Linux's position is more like "your out-of-tree code is not our problem". Linus didn't go out of his way to make out-of-tree modules more difficult to write.

pjmlp

14 hours ago

LLVM wasn't the first modularization of codegen, see Amsterdam Compiler Kit for prior art, among others.

GCC approach is on purpose, plus even if they wanted to change, who would take the effort to make existing C, C++, Objective-C, Objective-C++, Fortran, Modula-2, Algol 68, Ada, D, and Go frontends adopt the new architecture?

Even clang with all the LLVM modularization is going to take a couple of years to move from plain LLVM IR into MLIR dialect for C based languages, https://github.com/llvm/clangir

ayende

15 hours ago

Isn't that very much intentional on the part of GCC?

colejohnson66

15 hours ago

Somewhat. Stallman claims to have tried to make it modular,[0] but also that he wants to avoid "misuse of [the] front ends".[1]

The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds. But because of that, the mingling of the front and back ends ended up winning out over attempts to stay modular.

[0]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

[1]: https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

phkahler

15 hours ago

>> The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds.

Valid points, but also the reason people wanting to create a more modular compiler created LLVM under a different license - the ultimate GPL runaround. OTOH now we have two big and useful compilers!

Croak

14 hours ago

When gcc was built most compilers were proprietary. Stallman wanted a free compiler and to keep it free. The GPL license is more restrictive, but it's philosophy is clear. At the end of the day the code's writer can choose if and how people are allowed to use it. You don't have to use it, you can use something else or build you own. And maybe, just maybe Linux is thriving while Windows is dying because in the Linux ecosystem everybody works together and shares, while in Windows everybody helps together paying for Satya Nadellas next yacht.

Y_Y

12 hours ago

> At the end of the day the code's writer can choose if and how people are allowed to use it.

If it's free software then I can modify and use it as I please. What's limited is redistributing the modified code (and offering a service to users over a network for Afferro).

https://www.gnu.org/philosophy/free-sw.en.html#fs-definition

giancarlostoro

14 hours ago

That sounds like Stallman wants proprietary OSS ;)

If you're going to make it hard for anyone anywhere to integrate with your open source tooling for fear of commercial projects abusing them and not ever sharing their changes, why even use the GPL license?

dhosek

12 hours ago

This is a big part of why I’ve always eschewed GPL.

colechristensen

15 hours ago

Good lord Stallman is such a zealot and hypocrite. It's not open vs. closed it's mine vs. yours and he's openly declaring that he's nerfing software in order to prevent people from using it in a way he doesn't like. And refusing to talk about it in public because normal people hate that shit "misunderstanding" him.

--- From the post:

I let this drop back in March -- please forgive me.

  > Maybe that's the issue for GCC, but for Emacs the issue is to get detailed
  > info out of GCC, which is a different problem.  My understanding is that
  > you're opposed to GCC providing this useful info because that info would
  > need to be complete enough to be usable as input to a proprietary
  > compiler backend.
My hope is that we can work out a kind of "detailed output" that is enough for what Emacs wants, but not enough for misuse of GCC front ends.

I don't want to discuss the details on the list, because I think that would mean 50 messages of misunderstanding and tangents for each message that makes progress. Instead, is there anyone here who would like to work on this in detail?

bigfishrunning

14 hours ago

He should just re-license GCC to close whatever perceived loophole, instead of actively making GCC more difficult to work with (for everyone!). RMS has done so much good, but he's so far from an ideal figure.

tovej

11 hours ago

How in the world would you relicense GCC

colechristensen

2 hours ago

Most contributions are required to assign copyright to the FSF, so it's not actually particularly open.

If the FSF is the sole copyright owner they're free to relicense it however they please, if no one else has any controlling interest of the copyright, the GPL doesn't restrict you from relicensing something you're the sole owner of (and it's doubtful there's a legal mechanism to give away rights to something you continue to own)

Again, the FSF under Stallman isn't about freedom it's about control.

wahern

14 hours ago

Not anymore. Modularization is somewhat tangential, but for awhile Stallman did actively oppose rearchitecting GCC to better support non-free plugins and front-ends. But Stallman lost that battle years ago. AFAIU, the current state of GCC is the result of intentional technical choices (certain kinds of decoupling not as beneficial as people might think--Rust has often been stymied by lack of features in LLVM, i.e. defacto (semantic?) coupling), works in progress (decoupling ongoing), or lack of time or wherewithal to commit to certain major changes (decoupling too onerous).

torginus

14 hours ago

Personally, I think when you are making bad technical decisions in service of legal goals (making it harder to circumvent the GPL), that's a sure sign that you made a wrong turn somewhere.

1718627440

13 hours ago

Why? When your goal is to have free software, having non-free software with better architecture won't suit you.

bigstrat2003

13 hours ago

I would describe this more as "trying to prevent others from having non-free software if they wish to", which is a lot more questionable imo.

LeFantome

7 hours ago

Some in the Free Software community do not believe that making it harder to collaborate will reduce the amount of software created. For them, you are going to get the software and the choice is just “free” or not. And they imagine that permissively license code bases get “taken” and so copyleft licenses result in more code for “the community”.

I happen to believe that barriers to collaboration results in less software for everybody. I look at Clang and GCC and come away thinking that Clang is the better model because it results in more innovation and more software that I can enjoy. Others wonder why I am so naive and say that collaborating on Clang is only for corporate shills and apologists.

You can have whatever opinion you want. I do not care about the politics. I just want more Open Source software. I mean, so do the others guys I imagine but they don’t always seem to fact check their theories. We disagree about which model results in more software I can use.

1718627440

7 hours ago

I am maybe part of the crowd you describe, but I don't disagree so much with you.

I just think, that:

> I happen to believe that barriers to collaboration results in less software for everybody.

is not a bad thing. There is absolutely no lack of supply for software. The "market" is flooded with software and most of it is shit. https://en.wikipedia.org/wiki/Sturgeon%27s_law

LeFantome

6 hours ago

No argument that there is a lot of bad software.

I am not as much on the bandwagon for “there is no lack of supply for software”.

I think more software is good and the more software there is, the more good software there will be. At least, big picture.

I am ok with there being a lot of bad software I do not use just like I am ok with companies building products with Open Source. I just want more software I can use. And, if I create Open Source myself, I just want it to get used.

Analemma_

12 hours ago

This argument has been had thousands of times across thousands of forums and mailing lists in the preceding decades and we're unlikely to settle it here on the N + 1th iteration, but the short version of my own argument is that the entire point of Free Software is to allow end users to modify the software in the ways it serves them best. That's how it got started in the first place (see the origin story about Stallman and the Printer).

Stallman's insistence that gcc needed to be deliberately made worse to keep evil things from happening ran completely counter to his own supposed raison d'etre. Which you could maybe defend if it had actually worked, but it didn't: it just made everyone pack up and leave for LLVM instead, which easily could've been predicted and reduced gcc's leverage over the software ecosystem. So it was user-hostile, anti-freedom behavior for no benefit.

1718627440

7 hours ago

> the entire point of Free Software is to allow end users to modify the software in the ways it serves them best

Yes?

> completely counter to his own supposed raison d'etre

I can't follow your argument. You said yourself, that his point is the freedom of the *end user*, not the compiler vendor. He has no leverage on the random middle man between him and the end user other than adjusting his release conditions (aka. license).

Analemma_

7 hours ago

I'm speaking here as an end user of gcc, who might want e.g. to make a nice code formatting plugin which has to parse the AST to work properly. For a long time, Stallman's demand was that gcc's codebase be as difficult, impenetrable, and non-modular as possible, to prevent companies from bolting a closed-source frontend to the backend, and he specifically opposed exporting the AST, which makes a whole bunch of useful programming tools difficult or impossible.

Whatever his motivations were, I don't see a practical difference between "making the code deliberately bad to prevent a user from modifying it" and something like Tivoization enforced by code signing. Either way, I as a gcc user can't modify the code if I find it unfit for purpose.

pessimizer

11 hours ago

I have no idea what you think "gcc's leverage" would be if it were a useless GPL'd core whose only actively updated front and back ends are proprietary. Turning gcc into Android would be no victory for software freedom.

pessimizer

10 hours ago

Yes, the law made a wrong turn when it comes to people controlling the software on the devices they own. Free Software is an ingenious hack which often needs patching to deal with specific cases.

demurgos

15 hours ago

It is intentional to avoid non-free projects from building on top of gcc components.

I am not familiar enough with gcc to know how it impacts out-of-tree free projects or internal development.

The decision was taken a long time ago, it may be worth revisiting it.

janc_

7 hours ago

Over the years several frontends for languages that used to be out-of-tree for years have been integrated. So both working in-tree & outside are definitely possible.

1718627440

13 hours ago

I don't necessary like the focus on Rust, but if it happens, then we need to have support in the free compiler!

lionkor

13 hours ago

Why not? Like what about the technology or ecosystem do you disagree with

throwaway17_17

12 hours ago

Not parent, but I share the ambivalence (at best) or outright negativity (at worst) toward the focus on Rust. It is a question of preference on my part, I don’t like the language and I do not want to see it continue to propagate through the software I use and want to control/edit/customize. This is particularly true of having Rust become entrenched in the depths of the open-source software I use on my personal and work machines. For me, Rust is just another dependency to add to a system and it also pulls along another compiler and the accompanying LLVM. I’m not going to learn a language that I disagree with strongly on multiple levels, so the less Rust in my open source the more control I retain over my software. So for me the less entrenched Rust remains the more ability I keep to work on the software I use.

That said, if Rust is going to continue entrenching itself in the open source software that is widely in use, it should at least be able to be compiled with by the mainline GPL compiler used and utilized by the open source community. Permissive licenses are useful and appreciated in some context, but the GPL’d character of the Linux stack’s core is worth fighting to hold onto.

It’s not Rust in open source I have a problem with, it is Rust being added to existing software that I use that I don’t want. A piece of software, open source, written in Rust is equivalent to proprietary software from my perspective. I’ll use it, but I will always prefer software I can control/edit/hack on as the key portions of my stack.

danudey

12 hours ago

> I don’t like the language and I do not want to see it continue to propagate through the software I use and want to control/edit/customize.

This is how I feel about C/C++; I find Rust a lot easier to reason about, modify, and test, so I'm always happy to see that something I'm interested in is written in Rust (or, to a far lesser extent, golang).

> So for me the less entrenched Rust remains the more ability I keep to work on the software I use.

For me, the more entrenched Rust becomes the more ability I gain to work on the software I use.

> if Rust is going to continue entrenching itself in the open source software that is widely in use, it should at least be able to be compiled with by the mainline GPL compiler used and utilized by the open source community

I don't see why this ideological point should have any impact on whether a language is used or not. Clang/LLVM are also open-source, and I see no reason why GCC is better for these purposes than those. Unless you somehow think that using Clang/LLVM could lead to Rust becoming closed-source (or requiring closed-source tools), which is almost impossible to imagine, the benefits of using LLVM outweigh the drawbacks dramatically.

> A piece of software, open source, written in Rust is equivalent to proprietary software from my perspective.

This just sounds like 'not invented here syndrome'. Your refusal to learn new things does not reflect badly on Rust as a technology or on projects adopting it, it reflects on you. If you don't want to learn new things then that's fine, but don't portray your refusal to learn it as being somehow a negative for Rust.

> I will always prefer software I can control/edit/hack on as the key portions of my stack

You can control/edit/hack on Rust code, you just don't want to.

To be blunt, you're coming across as an old fogey who's set in his ways and doesn't want to learn anything new and doesn't want anything to change. "Everything was fine in my day, why is there all this new fangled stuff?" That's all fine, of course, you don't need to change or learn new things, but I don't understand the mindset of someone who wouldn't want to.

pessimizer

10 hours ago

>> I don’t like the language and I do not want to see it continue to propagate through the software I use and want to control/edit/customize.

> This is how I feel about C/C++; I find Rust a lot easier to reason about, modify, and test, so I'm always happy to see that something I'm interested in is written in Rust (or, to a far lesser extent, golang).

You have to do better than "NO U" on this. The comparison to C/C++ is silly, because there is no way you're going to avoid C/C++ being woven throughout your entire existence for decades to come.

> I don't see why this ideological point should have any impact on whether a language is used or not. Clang/LLVM are also open-source, and I see no reason why GCC is better for these purposes than those.

I hope you don't expect people to debate about your sight and your imagination. You know why people choose the GPL, and you know why people are repulsed by the GPL. Playing dumb is disrespectful.

> don't portray your refusal to learn it as being somehow a negative for Rust.

But your sight, however, we should be discussing?

edit: I really, really like Rust, and I find it annoying that the clearest, most respectful arguments in this little subthread are from the people who just don't like Rust. The most annoying thing is that when they admit that they just don't like it, they're criticized for not making up reasons not to like it. They made it very clear that their main objection to its inclusion in Linux is licensing and integration issues, not taste. The response is name calling. I'm surprised they weren't flagkilled.

keybored

6 hours ago

> edit: I really, really like Rust, and I find it annoying that the clearest, most respectful arguments in this little subthread are from the people who just don't like Rust.

Keywords right there. People who don’t-like-Rust are the most coddled anti-PL group. To the extent that they can just say: I really need to speak my mind here that I just don’t like it. End of story.

I don’t think anyone else feels entitled to complain about exactly nothing. I complain about languages. In the appropriate context. When it is relevant or germane to the topic.

A “genius” Rust program running on a supercomputer solving cancer would either get a golf-clap (“I don’t like Rust, but”) or cries that this means that the contagion is irreversibly spreading to their local supercomputer cluster.

One thing is people who work on projects where they would have to be burdened by at least (even if they don’t write it themselves) building Rust. That’s practical complaining, if that makes sense. Here people are whining about it entrenching itself in muh OSS.

throwaway17_17

6 hours ago

As I think I conveyed in my original post, I am not against anyone using whatever language they want to make their software. If a "genius" Rust program 'solved' cancer I would be exceptionally impressed by the PROGRAMMER's work, the language they used would not make a difference. Although I would be more excited to get the source code for the program if it was in a language I already knew and used routinely. My objection is to Rust being imported into software that I already use and is not currently written in Rust, and that is a very different thing.

pdimitar

12 hours ago

We are on a fairly technical thread and me coming here, I expect to see interesting technical arguments and counter-arguments.

You started your comment with "I don't like the language". I can't find any technical or even legal-like argumentation (there is zero legal encumbering for using Rust AFAIK).

Your entire comment is more or less "I dislike Rust".

Question to you: what is the ideal imagined outcome of your comment? Do you believe that the Rust community will collectively disband and apologize for rubbing you the wrong way? Do you expect the Linux kernel to undo their decision to stop flagging Rust as an experiment in its code base?

Genuine question: imagine you had all the power to change something here; what would you change right away? And, much more interestingly: why?

If you respond, can we stick to technical argumentation? "I don't like X" is not informative for any future reader. Maybe expand on your multiple levels of disagreement with Rust?

throwaway17_17

6 hours ago

I am not certain that technical argumentation is required on many, many threads on HN. In fact, TFA is just a blog post about the concept of compiler backends generally. Also, the comment I replied to was not a technical question so I just wrote the response in the same tone. I will maintain that it is absolutely alright to just dislike a programming language for any reason and those reasons if they exist outside of aesthetics don't have to be well formed or technical. But assuming your assertion of genuineness was intended to mean you want a response to those questions:

1) I had no ideal imagined outcome to writing that comment. The parent asked what the GP meant by not liking Rust but that at least Rust could be compiled by gcc. I was just explaining why it may be preferable to someone that does not use (or in this case "like" Rust) to see it able to be compiled by a GPL piece of software that has been a part of the Linux core for almost all of Linux's existence. As to the rest of that question, of course, I don't think that anyone using/enjoying/designing/supporting Rust in any way would be convinced by anything I think or say (I'm just some guy on HN).

2) If I had the power to change what? The issue with Rust not being able to compile using gcc or more broadly concerning change things regarding Rust? I don't think a list of changes I'd make to Rust is what you wanted, so I'll assume you meant regarding compiling Rust via gcc. If I had the power to change Rust from being only compiled using rustc and moved to primarily gcc based I would. And the why is not particularly interesting, I will always prefer actions and decisions that take mind and market share away from anything that can be used to advance the interest of multi-national conglomerate corporations via permissive licensing of the core technologies of computing.

I know that is not a technical argument, but it is the reason I'd make the change. I will assert that such a reason is absolutely valid, but I don't take disagreement with my position to be a character flaw in someone.

pdimitar

5 hours ago

> I will maintain that it is absolutely alright to just dislike a programming language for any reason and those reasons if they exist outside of aesthetics don't have to be well formed or technical.

I too am just one guy on HN but when I go to certain threads, I do expect no emotional and preference comments because I want to fill up my blind spots and emerge better educated. Obviously that does not mandate anything from you but since we are expressing preferences, that's mine.

RE: the rest, I am trying to understand your POV but can't. Is your issue with the difference between GPL and whatever Rust is licensed under?

That I could somewhat understand. But your rather emotionally loaded language against Rust itself I simply cannot and will not take seriously. Apparently Rust has an unique talent to tick people off on HN would be my tongue-in-cheek conclusion here because it has been years since I saw what we might call a "zealot fiercely arguing in favor of Rust" here, so the reason should be somewhere else.

Feel free to elaborate on that, though I am fairly sure such a discussion would not go anywhere. Emotion resents reason; emotion just wants to express itself.

But I do get weirded out how many people treat Rust like it's coming to eat their kids and puppies.

throwaway17_17

5 hours ago

I laid out three examples of issues I have with Rust in a sibling comment (which I can never remember how to link), those weren’t exhaustive, merely illustrative. The Rust zealot posting (if they ever really existed) have certainly not been very present in recent years. To your final statement, for me, it is not a Rust specific issue. I would not be in favor of Scala being brought into software I use. As an example, Scala also has characteristics, semantic and syntactic that I strongly oppose and so I ‘don’t like’ the language. Other than the saying I don’t like Rust I can not think of the language above as being emotional. Maybe the communication barrier of text on HN is too much to overcome for a discussion about subjective programming language preferences.

As to your, somewhat rhetorical seeming, question about my issue pertaining to GPL vs ‘whatever Rust is licensed under”. Yes I have an issue regarding licensing. But it pertains primarily to LLVM in this instance. LLVM is permissive licensed vs gcc being GPL. I am firmly opposed to the core executables/artifacts of computational technology (compilers, OS, drivers, ISAs, hardware interface standards) being anything other than copyleft. However, I would be willing to adapt to a more restrictive “open source” that allowed for limiting use of software for the betterment of the whole.

If I could immediately change anything, it would be to see LLVM stripped of its importance and dominance and put all those resources into copyleft software forcing profligate consumers of technical advancement to ‘pay it forward’ if they want the product of our collective minds and effort.

pdimitar

5 hours ago

Thanks, that's actually helpful (your entire reply).

What's your preference about copyleft about? Is it that you don't want corporations to keep leeching off of open source? But they do that already! And of course will do their best to hide it. What some license somewhere says bears nearly zero significance. Even if you catch them red-handed and can prove it in court (a very unlikely and rare combination) it would still take like 5 years for any conclusion to be reached... and it will likely end with financial settlement and no real negative outcome for the corporation. So that battle has IMO been lost already.

But if you have something else in mind, I am actually interested to hear it. I am rather cynical and not very well informed on licenses. To me they simply have no real teeth and that's why I lost interest in knowing more. Still, not taking an interest in something innately means that one is having a rather big blind spot. I recognize that about myself.

--

RE: Rust / Scala etc., thanks, that puts things into better context. But I still don't get why would you be against a language becoming more pervasive. Are you maybe convinced that the PL is only driven by hype and not merit? Or is it some other reservation / protest / consideration?

throwaway17_17

3 hours ago

I’ll answer what I think is the more interesting topic first (i.e. licensing is discussed at the bottom):

To start, for Rust to a larger degree than Scala, I certainly don’t think the language lacks merit. I am convinced the hype around Rust and its momentum in conversation did it a tremendous favor as it was coming up to 1.0 and as it went through ~2021. I do have some serious technical issues with choices Rust as a programming language made, but while I believe a change in direction for Rust would be beneficial, the ecosystem advancement and entrenchment of Rust makes it basically a non-starter as of 2025.

From a philosophical perspective (and I know I am an extreme outlier) I think, in the large, society and industry would be better served by having no ‘large’ programming languages. If every company was use to and had to invent at a minimum their own dialect of a broadly defined language types and then train employees to function within their language environment I would be thrilled.

The above would do a considerable amount to stop corporations from treating programmer like replaceable/disposable cogs in a machine. It would also end the ability of conglomerates from stealing the work of others wholesale as there wouldn’t be a single JavaScript, but a fleet of JavaScript suited to developing different classes of frontends. And hopefully, if a language was never as widespread as C, then hardware manufacturers would not be catering ISAs to fit the mythical ‘C Programmer’s’ model of how a computer works, thereby allowing for actually useful low level languages to be developed to fit the evolving features of what hardware actually does. (This point is basically a rip off of Chisnall’s “C is not a low level Language” article)

The lack of widely popular languages would also prevent the situation I see with Rust, which is really a first to market and good enough problem. I could go on at length about Rust’s commitment to the ownership semantics and its coupling with single mut XOR multi immut, but where it really hurts for me is that Rust’s pervasiveness prevents moving to a better option in the space due to moneyed interest and cultural buyin.

However, neither of the above are meant to fault Rust’s use for software engineering. It seems to be a good tool for many and is seeing acceptance at a rate that seems miraculous. My dislike of the language may result from fundamental disagreements about programming, type theory, and language “culture” but I have never said people should not build new software using Rust (although without using Cargo, info had a say).

—-

As to licensing, I agree with your general thought that I am basically tilting at windmills with my stance toward non-copyleft licensing. I think you are accurately describing the current state of affairs as well. However, a more vicious form of licensing, source broadcasting, literal viral attestation code, alteration aware self destructs, etc. I routinely refuse to give legal advice on licensing because it is such an untested and nearly unenforceable area of contract law, but I can’t help but feel there is some way to legally (or at least dangerously) put some teeth into software that is being exploited.

lionkor

12 hours ago

> I disagree with strongly on multiple levels

Fair enough, but what are those disagreements? I was fully in the camp of not liking it, just because it was shoved down every projects throat. I used it, it turns out its fantastic once you get used to the syntax, and it replaced almost all other languages for me.

I just want to know if there are any actual pain points beyond syntax preference.

Edit: I partially agree with the compiler argument, but it's open source, and one of the main reasons the language is so fantastic IS the compiler, so I can stomach installing rustc and cargo.

coldpie

12 hours ago

> A piece of software, open source, written in Rust is equivalent to proprietary software from my perspective.

Unlike a project's license, this situation is entirely in your control. Rust is just a programming language like any other. It's pretty trivial to pick up any programming language well enough to be productive in a couple hours. If you need to hack on a project, you go learn whatever environment it uses, accomplish what you need to do, and move on. I've done this with Python, Bash, CMake, C++, JavaScript, CSS, ASM, Perl, weird domain-specific languages, the list goes on. It's fine to like some languages more than others (I'd be thrilled if C++ vanished from the universe), but please drop the drama queen stuff. You look really silly.

IshKebab

11 hours ago

It's pretty disappointing when people like him try to block new technology just because they don't want to learn any more... but there's absolutely no way anyone is going to be productive in Rust in "a couple of hours".

throwaway17_17

10 hours ago

Just be clear, it is not a case of I don’t want to learn anymore. That’s actually pretty far from the case. As an example and sticking to programming languages, I am currently putting Koka and Eff through their paces and learning a decent amount about the incorporation of algebraic effects into languages at scale, I’m also working my way through Idris 2’s adoption of Quantitative Type Theory. I genuinely enjoy learning, and particularly enjoy learning in the comp sci field.

But, that doesn’t have any bearing on my lack of desire to learn Rust. Several other comments basically demand I justify that dislike, and I may reply, but there is nothing wrong with not liking a language for personal or professional use. I have not taken any action to block Rust’s adoption in projects I use nor do I think I would succeed if I did try. I have occasionally bemoaned the inclusion of Rust in projects I use on forums, but even that isn’t taken well (my original comment as an example).

JoshTriplett

8 hours ago

There's nothing wrong with disliking something. It's more that your dislike alone is not going to convince anyone else. Supporting arguments might either result in one or more of 1) people agreeing with you, or 2) you learning something that helps address your concern, or 3) Rust being improved to address your concern.

throwaway17_17

6 hours ago

Of the three options you presented as being potential results of putting forward arguments supporting my dislike of Rust, the third is interesting. I am quite sure that a vast majority of actual Rust programmers would consider addressing my concerns to be an active degradation of the language. Somewhat related is that I'm not particularly concerned with people (particularly Rust users) agreeing with me, nor do I think that would be a plausible result. So, that leaves the potential for being shown information that would "address [my] concern" as a potential result. So...

I have relatively strong opinions about quite a few areas that Rust, as a language and accompanying programming & tooling philosophy touch on, so I'll just do a few as examples:

1) I am strongly adverse to package managers (I didn't pick this example to get a rise out of you in particular) and their usage by programming languages. I am hostile toward the trend toward more and more dependencies in a given executable, which is only made worse by the industry adoption of languages that support and promote the "find a crate/get from NPM" attitude toward incorporation of dependencies. I don't know if there is evidence of a exponential explosion of transitive dependency in languages relying and building on a package manager ecosystem, but I wouldn't be surprised if it worked toward that point. I know that one does not have to use Cargo and the crate ecosystem, but it is a huge point of pride for the community and is THE idiomatic way to handle dependencies in Rust.

2) I have strong philosophical disagreements with ad-hoc polymorphism in general and with Rust's choice of pervasive reliance on its trait system all through the standard library and all examples of idiomatic code. At this point in development I don't even think there is a means to remove the ad-hoc polymorphism from Rust's implementation as a language. This point in particular I can not see any active Rust user being seen as an improvement of the language. Further, and although Rust does not have a definition of the language or a formalization of the type theory used by the language, I can not see a world where Rust adopts Haskell's position on the typeclass system being a convenient syntax sugar for a non-primitive and more explicit semantic form.

3) I am both practically and philosophically opposed to the usage/presence of 'ownership semantics' as a core part of the semantics of a programming language. Note, that I don't oppose the encoding of the commonly used meaning of 'ownership' at the type level via expressive types, as it can be an accurate description of the relationship between various data in a program. I do object to 'ownership' being the foundational semantic understanding of all programs and data used therein. There is a chance that Rust could incorporate a sophisticated type theory in a future release that relegates the current imposition of universal ownership semantics into a constrained area and allows for alternative semantics to be used in appropriate places, but I think it is nearly impossible to do and maintain validity for any prior programs.

So, do any of those three example look particularly appealing? I know you, only by reputation and seeing previous comments on HN, and know you are fairly involved in the development of Rust from several directions. Can you see Rust becoming a language with very limited ad-hoc polymorphism, a strong break away from the ownership semantics used today, and a language that does not place a package manager in a place of importance for idiomatic development?

Of those three examples the only one I can see anything being said that would alleviate my dislike is to just not use Cargo and build everything from scratch or find and download tarballs, which I would probably do and not complain if I had to use Rust. Thanks for your response being not particularly aggressive, I appreciate any time you gave to read this wall of text.

aw1621107

4 hours ago

> I have strong philosophical disagreements with ad-hoc polymorphism in general

What disagreements are those, if you don't mind typing more? PL design is something I'm interested in but not particularly experienced with so more perspectives are always nice to hear.

> I can not see a world where Rust adopts Haskell's position on the typeclass system being a convenient syntax sugar for a non-primitive and more explicit semantic form.

As someone who isn't familiar with Haskell, do you mind elaborating on Haskell's syntax sugar and what it reduces to?

throwaway17_17

3 hours ago

My problem with ad-polymorphism is primarily that it encourages more generic-ness in authoring code, which I am aware is often lauded as a positive characteristic of a given program. Taken to the extreme, there are whole communities of developers that pride themselves of writing the most generic code possible. I hold the opinion that all code should be clearly specified and particularized to processing the actual data required by the specification of the problem domain. I am certainly on the extreme end of the spectrum of generic to highly specified, but I genuinely feel that better code and the resulting programs come from a low level and data specific design ethos.

Additionally, and more relevant to Programming Language Theory, the entanglement between ad-hoc polymorphism implementations and the detention of a programming language are a huge mistake from my perspective. This is where Haskell becomes relevant, because although there are some differences (implicit self, orphan issues, etc) between Rust traits and Haskell’s typeclasses, they are an extremely similar mechanism for achieving ad-hoc polymorphism. At this point in its development, and due to the pervasiveness of usage throughout the stdlib, I see it as almost certain that Rust will attempt to kludge traits into a formal definition of its type theory and language definition making any attempts at coexisting with other language in a single application more difficult. Comparably, in Haskell, typeclasses are merely syntactic sugar allowing for a better developer experience using ad-hoc polymorphism. Specifically, Haskell, the language as defined, achieves ad-hoc polymorphism by passing a dictionary parameter to functions using overloaded function names. This is done using the standard terms in Haskell and has a clear denotaional semantics for such terms. Rust usage of traits is talked about and reasoned about as a more primitive part of the language, not just a pretty piece of sugar with a more basic existence in the formally defined core of a programming language.

If ad-hoc polymorphism is something a language designer wants to incorporate into the usage of a language, my position is that defining a typeclass style sugar over a clearly defined set of terms in the core, formally defined language would be at least a method of prohibiting issues with the resolution, definition, and various methods of implementation of ad-hoc polymorphism polluting the syntax and semantics of the language itself. But the above requires a firm definitional boundary between what is the language and what is syntactic sugar to be built into the definition of the language and built into the compiler infrastructure.

A more out of band way to achieve ad-hoc polymorphism would be to have a pre-processor that is a part of the language distribution and maintained by the language designer/org that does the resolution/solving of the ad-hoc polymorphism and then presents the compiler with source text with no overloading.

There are also type theoretic solutions to ad-hoc polymorphism l, but that’s a little outside the scope (even if it my personal solution to having and limiting ad-hoc polymorphism in a language).

umanwizard

5 hours ago

NB: I'm not the person you were responding to.

> I am strongly adverse to package managers

This has nothing to do with Rust the language, other than the incidental fact that cargo happens to be bundled with Rust. There are no cargo-specific concepts whatsoever in the Rust language, just like there are no Cmake-specific concepts in C++. I know you alluded to this in your post; I just want to make sure it's crystal clear to everyone reading.

Consequently, people can, and do, use Rust without Cargo. That is obviously not what the majority does, because cargo is so easy to use with rust, but it is certainly possible both in theory and in practice.

If it's a "point of pride in the community" and "idiomatic" -- who cares? Rust is a general-purpose systems programming language. You can use it however you want, without listening to what people on Twitter think about it.

This particular complaint strikes me as social/cultural rather than technical -- "people who like Rust do something I find annoying, therefore I must conclude that they're not of my tribe, and reject rust". That is very understandable human nature, but not logically justified.

As for your other two complaints, you are correct that they are fundamental to the language and will never change for at least as long as the language is called "rust".

But since these complaints are totally subjective (a reasonable person might like or dislike them), it doesn't really seem fair to bitch about a language existing and becoming popular that has these properties.

For example, I complain about Go because I think it has actual defects that make it harder to use for almost any competent programmer. I also don't like Python, but I think the tradeoffs it chose to make are at least intelligible and some people prefer the Python style, so it would make no sense for me to complain that other people use it in their projects.

throwaway17_17

4 hours ago

My reason for citing the package manager (and its popularity) as a reason I dislike Rust is because the language org that oversees the language oversees Cargo and its ecosystem. It’s not a tribal thing, it’s a “I feel like this choice enable the active pursuit of a societally/industry detrimental practice”. But I did and do concede that the package manager is not likely to be a part of an eventual formal definition of Rust.

Regarding that it might not be fair to ‘bitch’ about a language ‘existing and becoming popular’ over subjective disagreements: as I’ve said in other comments, and other places, I do not have any issue with developers using or enjoying Rust in their work, I’m all for people making software that is more economical in its usage of hardware and associated/entailed resources. I just don’t want Rust to be imported into existing codebases in other languages (and certainly not into software where it adds a non-copyleft dependency to a GPL’d core).

JoshTriplett

8 hours ago

Productivity is incremental. In a couple of hours, you could figure out enough to clone a repository of a project you care about, build it successfully, and make a trivial change (e.g. improve an error message, or add an alias to a command-line argument). That doesn't mean you know enough to start using Rust for your next project.

keybored

6 hours ago

> It's pretty disappointing when people like him try to block new technology just because they don't want to learn any more...

This is an irrelevant and disingenious hacker jab (oh look, they’re not a “real hacker”).

umanwizard

13 hours ago

Rustc (+ LLVM) already is a free compiler.

pessimizer

10 hours ago

Almost the only thing I don't like about Rust is that a bunch of people actively looking to subvert software freedom have set up shop around it. If everything was licensed correctly and designed to resist control by special interests, I'd be a lot happier with having committed to it.

The language itself I find wonderful, and I suspect that it will get significantly better. Being GPL-hostile, centralized without proper namespacing, and having a Microsoft dependency through Github registration is aggravating. When it all goes bad, all the people silencing everyone complaining about it will play dumb.

If there's anything I would want rewritten in something like Rust, it would be an OS kernel.

JoshTriplett

8 hours ago

> actively looking to subvert software freedom

Never attribute to malice that which can be adequately explained by apathy. We have, unfortunately, reached a point where most people writing new software default to permissive and don't sufficiently care about copyleft. I wish we hadn't, but we have. This is not unique to Rust.

Ironically, we're better off when existing projects migrate to Rust, because they'll keep their licenses, while rewrites do what most new software does, and default to permissive.

Personally, I'm happy every time I see a new crate using the GPL.

> GPL-hostile

Rust is not GPL-hostile. LLVM was the available tool that spawned a renaissance of new languages; GCC wasn't. The compiler uses a permissive license; I personally wish it were GPL, but it isn't. But there's nothing at all wrong with writing GPLed software in Rust, and people do.

> having a Microsoft dependency through Github registration is aggravating

This one bugs a lot of us, and it is being worked on.

timeon

8 hours ago

> GPL-hostile

Not sure if it is particularly hostile. There are several GPL crates like Slint.

> Microsoft dependency through Github registration is aggravating

This one is concerning.