> 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?”
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.
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.
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.
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, and it is well understood how. Great. You are totally correct.
But all of this just proves the original point. It either precedes anything on the internet today, or is so obscure that no search engine can find it. Either way, if no one uses it or even bothers to explain how, 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.
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.
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, ...?
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).
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
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.
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.
"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).
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.
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.
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.
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.
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.
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.
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".
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.
PlayStation and macOS kind of show what happens with upstream.
As did all the UNIXes that used to rule before companies started sponsoring Linux kernel development, and were quite happily taking BSD code into them, alongside UNIX System V original code.
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.
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
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.
>> 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!
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.
> 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).
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?
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.
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.
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?
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).
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.
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.
> 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).
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.
> Either way, I as a gcc user can't modify the code if I find it unfit for purpose.
...What? It's licensed under the GPL, of course you can modify the code if you find it unfit for purpose. If it weren't Free Software you might not have been able to do so as the source code might be kept from you.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
>> 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.
> 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.
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.
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?
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.
> 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.
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.
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?
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.
Thanks for entertaining the discussion, the civility and your willingness to expand is very welcome.
> 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
May I ask why? I think I am gathering from your comment that you think the language is too big (which I don't understand, could you please clarify?) and that maybe we as an area become too dependent on too few PLs / frameworks? Is your worry an increasing centralization perhaps?
> 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.
I was not there but I heard from folks on HN that during the LISP era a good amount of companies did this: they built their own DSL that described their business perfectly (on top of LISP) and then even taught business people how to modify parts of the system by giving them access to only some modules. Result was reported to be a crushing success.
But if we go by your reservations, would you then say LISP is too big and at a risk to entrench itself everywhere (I mean if you were there back then)?
> The above would do a considerable amount to stop corporations from treating programmer like replaceable/disposable cogs in a machine
I would really _love_ for that to be true but I remain skeptical. In my 24 years of career I have only always noticed how businesses always work hard trying to replace us. It's a constant tug of war and we are more or less tolerated because they can't do without us. The moment they feel that they could, most of us would be fired in a heartbeat -- and some of that, in a much smaller scale than they wanted, already happened with the advent of good-ish coding LLM agents.
> 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
Here we agree at 100%. I do like Rust a lot (though I don't work with it for a while now, I keep using it for personal projects and a little bit of portfolio work) but I believe it's a local maxima that we would all be stuck with for a while.
But that's not an indictment on Rust in particular IMO; it's a judgement towards the risk-averse nature of the area and something I personally don't blame people for (you should not rewrite your business code once every 5 years after all).
--
All that being said, to me Rust is an objective improvement of the state of affairs. It's going to be the new C++ and maybe even the new C, we'll see. And I agree with you that it's not without faults (`async` could have been done better; it's a huge slog to learn it properly and that really did not need to be the case).
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.
> 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.
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".
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).
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.
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.
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.
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).
Working on adding that to the standard library, along with a handful of other "you should be able to do this without a dependency" things. We're being very cautious to not fall into the trap of "the standard library is where code goes to die", which is the problem some languages' standard libraries have had. But there are more things we should add, nonetheless.
From the outside looking in, it seems that despite trends in language development to the contrary, Rust has taken an extremely conservative stance on the inclusions into and the evolution of its standard library. I applaud the decision and the will of the core teams for sticking to their guns in this area. I had assumed that the reasons you give above were the motivating factors for being vigilant about the slower cadence of development and smaller ‘size’ of additions/alterations/removals to the standard library . But having it confirmed makes it very comfortable for me to think it is a nearly unqualified positive stance for the language to take.
I have seen your talk about the long future of Rust and I think there is the implication that you and the other Rust language developers are looking toward a 25-30 year timeframe (which encompasses nearly every language in wide spread use today) as the minimum expected lifespan of the language, with a view to be responsive and flexible enough to see the language continue to adapt and evolve throughout a longer period as well. With that type of longevity as an active consideration in planning the language’s growth/evolution I think Rust is setting a good precedent for non-BDFL style governance and stewardship of programming languages. I would hope a more long term compatible view takes hold in programming language development particularly, but general software development could probably stand to benefit if the time horizon was lengthened well beyond what seems to be standard today.
Thank you very much; all of that is very gratifying to hear.
And yes, being conservative about what we add to the standard library is a very deliberate decision. We also try not to do novel design in the standard library; design and iteration should happen in the ecosystem.
There are also some things that we're unlikely to ever add, such as cryptographic algorithms, precisely because we wouldn't be confident that we could fix issues with them without breaking compatibility. Crates in the ecosystem get to have a 2.0; the standard library doesn't. (Editions give us some ability to evolve the standard library, but the standard library still has to support every past edition.)
Also: I wish this level of discourse were what we could have with everyone who expresses a dislike of Rust. This has been an entirely pleasant experience, and I appreciate your feedback. Even if Rust isn't your particular cup of tea and you'd prefer to write your own code in something else, I'm gratified to know that things like this make it more tolerable. We often have to deal with code in languages that aren't our first choice.
How is it any harder than using C? Sure, the C standard library gives you random numbers, but it doesn't, for example, give you any containers (hash maps, vectors etc.) which are needed even more often.
> Generate a random number.
Well, obviously, I would use cargo and pull in the `rand` package, because I'm not an anti-dependencies ideologue. Cargo makes it easier to depend on third-party code; that's the whole point. But the OP explicitly doesn't want that, so presumably he'd write his own RNG from scratch, or download a tarball of the `rand` package and build it manually without cargo. None of this is any harder in Rust than it would be in C or C++.
> 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?
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).
Woah! Thank you for taking the time to explain your perspective and thoughts! It's a lot of food for thought. I wish I had the background and knowledge to discuss things on equal footing :(
Just a few additional questions/comments:
> 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.
Would it be accurate to say that Swift's non-monomorphized generics are more along the lines of the Haskell approach you prefer (i.e., single function implementation with a separate parameter for additional type info)?
And a bit more hand-wavey, but IIRC Rust's generics were defined in such a way that monomorphization is technically an implementation detail; in other words, I want to say a Haskell-like approach isn't strictly ruled out. I'd take that with a large grain of salt, though.
> 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.
Might MiniRust [0] be something along the lines of what you would desire? It seems to fit the general idea of a smaller formally-specified "core" language. There's also this bit about traits specificlaly from the readme:
> That translation [from Rust to MiniRust] does a lot of work; for example, traits and pattern matching are basically gone on the level of MiniRust.
Swift is a good reference point in this area because Swift essentially took the dictionary-passing approach of Haskell and added the ‘low level’ type information like bit-width, offsets, etc as a Type Metadata parameter. The big upside is that Swift gets a good deal of performance boost compared to Haskell and other languages that have uniform datatypes (boxed values). So to extend the concept I was describing from Haskell to Swift would be creating concrete syntax for the language, which has no semantic identity outside those already existing in the semantics of Witness Tables. Sometimes the term “derived form” is used to talk about syntax like this. It is the term for concrete syntactic forms that are only defined in terms of syntax forms in the base/core language. It is, for the most part, correct to view derived forms as macros or as a more general metaprogramming construct, but but in Haskell’s case the macros are implemented in the compiler and expanded in a particular phase of compilation.
Swift is also good touch point for considering what the compiler does with the actual implementation of ad-hoc polymorphism. Swift is optimizing to monomorphized instances of a generic function give some heuristics about expect performance gains by specializing the function for a given type (Haskell also does this in GHC, but still pays a performance price for using boxed values).
So to answer the question: the part of Haskell’s implementation of typeclasses that I think is the correct method is that it is merely a derived syntactic form that is expanded by the compiler into Haskell’s actual language (its abstract syntax as encoded as ghc-core in GHC in particular). From this perspective Swift doesn’t provide the derived form, it just provides the implementation directly for developers to use omitting the sugar that Haskell provides. I tend towards explicitness as a strong default in language design.
Rust doesn’t have a formal semantics currently, so they could certainly adopt a derived form approach to traits, but I don’t know enough Rust to be able to determine what issues existing thoughts, assumptions, and type theory ‘commitments’ would act as obstacles to such a semantic.
As to MiniRust, Ralf Jung (at ETH Zurich) has done some excellent work, along with some of his students (Max Vistrup’s recent paper on Logics a la Carte is very, very good). MiniRust does attempt to be comparable to Haskell’s GHC-core. So in the sense of being or approaching what I would view as the (excluding type theory based options) correct way to implement ad/hoc polymorphism, yes, to sum: MiniRust as the semantic definition of a derived syntactic form and a compilation phase for ‘expansion’ of the trait macro.
Those explanations aside, my issues with ad-hoc polymorphism do not go away under this implementation, I’m generally opposed to generic functions (especially function name overloading). But I think that if a language is pursuing ad-hoc polymorphism as a feature they should pursue it in a well founded and formal manner.
Both of the example things you picked are generic types, and container-esque types at that. I think that my opposition to generics in general is a scale of dislike for different uses of generics. So, an off the cuff scale from (well founded and acceptable in certain cases) to (a strict negative in nearly all cases) would be:
Polymorphic Types
Parametricly Polynorphic functions
‘Well Motivated’ Ad-hoc Polymorphism
Basic Function overloading
Basic ‘Operator Overloading’
Function overloading for symbols that are treated as ‘special’ by the compiler
I think the hashmap case is illustrative for my general perspective. I do see the value in being able to have polymorphism for function arguments which are generic in a type parameter. However, consider that the ideal/most performant hashing function for keys differs not just based on general types (int vs string) but can differ based on something like string length or bit width or signededness. My position is that a language should prioritize the ability to encode those exact requirements in a data structure and difficulties for achieving generic-ness be damned. Each function taking a hashmap as argument should be tied to the optimizations and low level considerations intended by the developer.
I am not opposed to some duplication of code where it produces the appropriate code for the problem being solved. My generalized dislike of ‘generics’ is there, but in my comment above I was mostly discussing ad-hoc polymorphism as a means of enforcing some general reasoning ability onto function name overloading. And as I implied in my scale above I find it particularly distasteful (basic function name overloading), if not actively harmful.
For generics there are two areas often conflated in conversation that I find to be wildly different in formalizations of type theories and languages: first, there is static phase type application associated with System F and higher order polymorphic lambda calculus more broadly. I obviously would like to see a more specific and limited implementation of generics at all levels of abstraction, but the higher the abstraction goes the more ‘sense’ generic-ness makes. Second, there is generics as a name for function name overloading, which is distinct from parametricly polymorphic function as well as distinct from generic types. I really dislike this usage of generics and do not think it is a good practice for developing quality software or for readability, maintainability, or efficient optimization. Obviously this is a scale as well. I would put Swift in the lead with Witness Table semantics for generics, then typeclasses and traits, then any less structured implementations at the bottom.
That's a helpful explanation, thank you. I do generally agree that overuse of generics can produce bad interfaces. I also agree that generics tempt people to assume that the type fully determines the desired behavior, rather than giving any other means of selecting it.
(It's worth noting, for instance, that HashMap lets you replace the hasher, if you have some strings with a property that make them more hashable. But if we didn't have that, then the generic would force a given type to have only one hasher, and force a newtype wrapper to change the hasher, which would make for suboptimal designs.)
I agree there are significant costs to generics (especially readability), but there are large classes of problems that are a right pain without them. Even Go added them eventually.
In (2), I'm surprised to hear your description of Rust's generics as "ad-hoc polymorphism". I tend to hear that term used to describe non-trait based systems, like C++ generics (in the absence of "concepts"), which act like a compile-time version of duck typing. I think of Rust's generics as trait-based polymorphism, not ad-hoc polymorphism, and I prefer the former over the latter. To a first approximation, I see Rust's generics system as somewhat related to Haskell's. I would be interested to better understand how you see the differences.
From the way you're describing it, it sounds like you might not fundamentally object to generics in general, just to the idea of doing it through monomorphization rather than "dyn Trait"-style vtables? If so, then that's understandable. I like that Rust has both options, but I can absolutely appreciate preferring to do everything via vtables, which has both advantages (code size, one kind of conceptual simplicity) and disadvantages (more difficult to do per-implementation optimization, without doing devirtualization which amounts to monomorphization anyway).
We do have some forms of first-class "type functions" or "type constructors" or "rank-2 polymorphism", in the style of Haskell, so that you can be generic over something like `Vec`. It's a little indirect at the moment, going through traits with associated types, and I'd love to see a more direct version where you can literally write `Something<HashMap>` or `Something<BTreeMap>` and have those be type functions of one parameter (Haskell "kind" star -> star).
In any case, we have talked many many times about the idea of having more global options to say "don't monomorphize by default, do everything with trait objects". We also are likely to build a stable ABI atop trait objects and vtables eventually, so that it's possible to pass around pointers to data structures and their associated functions, without relying on the layout of the structure.
For (1), I do think we need some mechanism to integrate dependencies. I can appreciate the aversion to the default of "get things from the network". We do try to have good support for vendoring and similar, and this is critical for many projects (e.g. Rust in the Linux kernel, or Rust in CPython, are not going to allow downloading dependencies from the network). All that said, there is a tradeoff between "one first-class package manager and build system" and "lackluster support for various build systems", and Rust picked the former deliberately. We do like being able to implement things in rustc and plumb them through Cargo, so that they're available through the whole stack when that's necessary to make a feature useful. But we also have many users who need to use rustc without cargo, and who ensure that rustc features work with other build systems, notably large corporate monorepo build systems.
As for (3), fair enough, that is very much a philosophical difference between you and Rust, and Rust isn't likely to change that. I do think we're going to make ever more sophisticated ownership semantics in the future (e.g. making self-referential data structures possible), but I doubt Rust's model will stop fundamentally being based around ownership and borrowing.
I just wanted to drop a quick comment to clear up your first question. The term ad-hoc polymorphism to describe both Haskell and Rust’s typeclasses/traits is taken directly from Wadler and Blott’s paper which introduces the idea/concepts of type classes to Haskell. The name of that paper is ‘How to make Ad-Hoc Polymorphism less Ad-hoc’. This paper laid the groundwork for the implementation Rust uses and it is a mechanism for restraining ad-hoc polymorphism. But I think the term still applies to both Haskell and Rust’s typeclasses. Ad-hoc polymorphism is not a derisive term (when used as a term of art in discussions of implementations of programming languages), it is merely the PLT way of saying function name overloading. Rust and Haskell use very similar system to impose restrictions and semantic guiderails on ad-hoc polymorphism, but both languages still have it. To sum, I certainly do not mean any negative connotation with the term, I feel I am using it appropriately and as intended in this domain of discourse.
PS. I intend to write a more substantive reply to your comment, but didn’t think I should leave this unsaid.
I didn't take it as having a negative connotation; I just didn't interpret it in the manner referenced in that paper, and instead interpreted it as being not based on traits/concepts. Even given that, I didn't take it as negative; some people prefer the C++-style model, just as some people prefer dynamic typing.
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.
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.
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.
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.
> 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?”
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.
Or, the obligatory RFC 1149 (IP over Avian Carriers).
Oh come on, SLIP over MIDI is tried and true.
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.
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
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, and it is well understood how. Great. You are totally correct.
But all of this just proves the original point. It either precedes anything on the internet today, or is so obscure that no search engine can find it. Either way, if no one uses it or even bothers to explain how, 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.
I think you are taking this all way too seriously. Think IP over avian carriers.
You got whooshed pretty hard here. The post you were responding to was a joke.
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.
libgccjit is much higher level than what's documented in the "GCC Internals" manual.
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!
> Little side-note: If enough people are interested by this topic, I can write a (much) longer explanation of these passes.
Yes, please!
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, ...?
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).
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
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.
Will migrating to annotate-snippets change rustc/cargo formatting of errors in any way?
Also, in what sense it is more conservative?
The output will cause no user visible change.
It uses ASCII for all output, replaces ZWJs to have consistent terminal output in the face of multi codepoint emoji for two out of the top of my head.
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.
Not just C++. Even C parsing is context-dependent because of typedef. Requires a bit of hackery to parse in a conventional LL/LARL/LR parser.
I disagree. It is interesting, that is why there many languages out there without an LSP.
"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).
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.
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.
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.
I'll let you decide whether it counts as "mainstream", but the principal implementation of Nix has a very old school setup using bison and flex:
https://github.com/NixOS/nix/blob/master/src/libexpr/parser....
https://github.com/NixOS/nix/blob/master/src/libexpr/lexer.l
It shows, even as a Nix fan. The errors messages are abysmal
Ruby also used to use Bison, uses its own https://github.com/ruby/lrama these days.
I believe that GCC also moved to a handwritten parser, at least for c++, a couple of decades 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.
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.
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.
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.
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.
I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.
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
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.
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".
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.
There are several open BSDs.
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.
PlayStation and macOS kind of show what happens with upstream.
As did all the UNIXes that used to rule before companies started sponsoring Linux kernel development, and were quite happily taking BSD code into them, alongside UNIX System V original code.
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.
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
Isn't that very much intentional on the part of GCC?
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...
>> 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!
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.
> 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
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.
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?
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.
How in the world would you relicense GCC
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.
"Most" is not all, and I doubt rights have been turned over since the beginning.
Either way, it would just create a GPL fork.
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?
This is a big part of why I’ve always eschewed GPL.
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).
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.
Why? When your goal is to have free software, having non-free software with better architecture won't suit you.
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.
> 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).
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.
> Either way, I as a gcc user can't modify the code if I find it unfit for purpose.
...What? It's licensed under the GPL, of course you can modify the code if you find it unfit for purpose. If it weren't Free Software you might not have been able to do so as the source code might be kept from you.
> Which you could maybe defend if it had actually worked
It did work, though, for 15 years or so. Maybe that was or wasn't enough to be worth it, I don't know.
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.
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.
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.
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
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.
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.
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.
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.
A perhaps naive question: does it have a chance to be faster than LLVM backend?
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.
rustc (via Ferrocene) is already being qualified, and form what I hear it’s been fairly easy to do so, for various reasons.
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.
Yeah certainly wouldn't hurt :)
[flagged]
I don't necessary like the focus on Rust, but if it happens, then we need to have support in the free compiler!
Why not? Like what about the technology or ecosystem do you disagree with
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.
> 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.
>> 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.
> 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.
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.
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?
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.
> 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.
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.
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?
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.
Thanks for entertaining the discussion, the civility and your willingness to expand is very welcome.
> 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
May I ask why? I think I am gathering from your comment that you think the language is too big (which I don't understand, could you please clarify?) and that maybe we as an area become too dependent on too few PLs / frameworks? Is your worry an increasing centralization perhaps?
> 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.
I was not there but I heard from folks on HN that during the LISP era a good amount of companies did this: they built their own DSL that described their business perfectly (on top of LISP) and then even taught business people how to modify parts of the system by giving them access to only some modules. Result was reported to be a crushing success.
But if we go by your reservations, would you then say LISP is too big and at a risk to entrench itself everywhere (I mean if you were there back then)?
> The above would do a considerable amount to stop corporations from treating programmer like replaceable/disposable cogs in a machine
I would really _love_ for that to be true but I remain skeptical. In my 24 years of career I have only always noticed how businesses always work hard trying to replace us. It's a constant tug of war and we are more or less tolerated because they can't do without us. The moment they feel that they could, most of us would be fired in a heartbeat -- and some of that, in a much smaller scale than they wanted, already happened with the advent of good-ish coding LLM agents.
> 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
Here we agree at 100%. I do like Rust a lot (though I don't work with it for a while now, I keep using it for personal projects and a little bit of portfolio work) but I believe it's a local maxima that we would all be stuck with for a while.
But that's not an indictment on Rust in particular IMO; it's a judgement towards the risk-averse nature of the area and something I personally don't blame people for (you should not rewrite your business code once every 5 years after all).
--
All that being said, to me Rust is an objective improvement of the state of affairs. It's going to be the new C++ and maybe even the new C, we'll see. And I agree with you that it's not without faults (`async` could have been done better; it's a huge slog to learn it properly and that really did not need to be the case).
> 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.
> 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.
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".
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).
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.
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.
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.
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).
I do write a lot of Rust. Without cargo, it can be a pain in the ass, because nobody designed it to be used without cargo.
Generate a random number.
> Generate a random number.
Working on adding that to the standard library, along with a handful of other "you should be able to do this without a dependency" things. We're being very cautious to not fall into the trap of "the standard library is where code goes to die", which is the problem some languages' standard libraries have had. But there are more things we should add, nonetheless.
From the outside looking in, it seems that despite trends in language development to the contrary, Rust has taken an extremely conservative stance on the inclusions into and the evolution of its standard library. I applaud the decision and the will of the core teams for sticking to their guns in this area. I had assumed that the reasons you give above were the motivating factors for being vigilant about the slower cadence of development and smaller ‘size’ of additions/alterations/removals to the standard library . But having it confirmed makes it very comfortable for me to think it is a nearly unqualified positive stance for the language to take.
I have seen your talk about the long future of Rust and I think there is the implication that you and the other Rust language developers are looking toward a 25-30 year timeframe (which encompasses nearly every language in wide spread use today) as the minimum expected lifespan of the language, with a view to be responsive and flexible enough to see the language continue to adapt and evolve throughout a longer period as well. With that type of longevity as an active consideration in planning the language’s growth/evolution I think Rust is setting a good precedent for non-BDFL style governance and stewardship of programming languages. I would hope a more long term compatible view takes hold in programming language development particularly, but general software development could probably stand to benefit if the time horizon was lengthened well beyond what seems to be standard today.
Thank you very much; all of that is very gratifying to hear.
And yes, being conservative about what we add to the standard library is a very deliberate decision. We also try not to do novel design in the standard library; design and iteration should happen in the ecosystem.
There are also some things that we're unlikely to ever add, such as cryptographic algorithms, precisely because we wouldn't be confident that we could fix issues with them without breaking compatibility. Crates in the ecosystem get to have a 2.0; the standard library doesn't. (Editions give us some ability to evolve the standard library, but the standard library still has to support every past edition.)
Also: I wish this level of discourse were what we could have with everyone who expresses a dislike of Rust. This has been an entirely pleasant experience, and I appreciate your feedback. Even if Rust isn't your particular cup of tea and you'd prefer to write your own code in something else, I'm gratified to know that things like this make it more tolerable. We often have to deal with code in languages that aren't our first choice.
How is it any harder than using C? Sure, the C standard library gives you random numbers, but it doesn't, for example, give you any containers (hash maps, vectors etc.) which are needed even more often.
> Generate a random number.
Well, obviously, I would use cargo and pull in the `rand` package, because I'm not an anti-dependencies ideologue. Cargo makes it easier to depend on third-party code; that's the whole point. But the OP explicitly doesn't want that, so presumably he'd write his own RNG from scratch, or download a tarball of the `rand` package and build it manually without cargo. None of this is any harder in Rust than it would be in C or C++.
> 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?
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).
Woah! Thank you for taking the time to explain your perspective and thoughts! It's a lot of food for thought. I wish I had the background and knowledge to discuss things on equal footing :(
Just a few additional questions/comments:
> 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.
Would it be accurate to say that Swift's non-monomorphized generics are more along the lines of the Haskell approach you prefer (i.e., single function implementation with a separate parameter for additional type info)?
And a bit more hand-wavey, but IIRC Rust's generics were defined in such a way that monomorphization is technically an implementation detail; in other words, I want to say a Haskell-like approach isn't strictly ruled out. I'd take that with a large grain of salt, though.
> 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.
Might MiniRust [0] be something along the lines of what you would desire? It seems to fit the general idea of a smaller formally-specified "core" language. There's also this bit about traits specificlaly from the readme:
> That translation [from Rust to MiniRust] does a lot of work; for example, traits and pattern matching are basically gone on the level of MiniRust.
[0]: https://github.com/minirust/minirust
Swift is a good reference point in this area because Swift essentially took the dictionary-passing approach of Haskell and added the ‘low level’ type information like bit-width, offsets, etc as a Type Metadata parameter. The big upside is that Swift gets a good deal of performance boost compared to Haskell and other languages that have uniform datatypes (boxed values). So to extend the concept I was describing from Haskell to Swift would be creating concrete syntax for the language, which has no semantic identity outside those already existing in the semantics of Witness Tables. Sometimes the term “derived form” is used to talk about syntax like this. It is the term for concrete syntactic forms that are only defined in terms of syntax forms in the base/core language. It is, for the most part, correct to view derived forms as macros or as a more general metaprogramming construct, but but in Haskell’s case the macros are implemented in the compiler and expanded in a particular phase of compilation.
Swift is also good touch point for considering what the compiler does with the actual implementation of ad-hoc polymorphism. Swift is optimizing to monomorphized instances of a generic function give some heuristics about expect performance gains by specializing the function for a given type (Haskell also does this in GHC, but still pays a performance price for using boxed values).
So to answer the question: the part of Haskell’s implementation of typeclasses that I think is the correct method is that it is merely a derived syntactic form that is expanded by the compiler into Haskell’s actual language (its abstract syntax as encoded as ghc-core in GHC in particular). From this perspective Swift doesn’t provide the derived form, it just provides the implementation directly for developers to use omitting the sugar that Haskell provides. I tend towards explicitness as a strong default in language design.
Rust doesn’t have a formal semantics currently, so they could certainly adopt a derived form approach to traits, but I don’t know enough Rust to be able to determine what issues existing thoughts, assumptions, and type theory ‘commitments’ would act as obstacles to such a semantic.
As to MiniRust, Ralf Jung (at ETH Zurich) has done some excellent work, along with some of his students (Max Vistrup’s recent paper on Logics a la Carte is very, very good). MiniRust does attempt to be comparable to Haskell’s GHC-core. So in the sense of being or approaching what I would view as the (excluding type theory based options) correct way to implement ad/hoc polymorphism, yes, to sum: MiniRust as the semantic definition of a derived syntactic form and a compilation phase for ‘expansion’ of the trait macro.
Those explanations aside, my issues with ad-hoc polymorphism do not go away under this implementation, I’m generally opposed to generic functions (especially function name overloading). But I think that if a language is pursuing ad-hoc polymorphism as a feature they should pursue it in a well founded and formal manner.
> I’m generally opposed to generic functions
I'd be interested to know how, in your preferred model, you'd handle things like `Vec<T>` or `HashMap<K, V>`, without duplicating code.
Both of the example things you picked are generic types, and container-esque types at that. I think that my opposition to generics in general is a scale of dislike for different uses of generics. So, an off the cuff scale from (well founded and acceptable in certain cases) to (a strict negative in nearly all cases) would be:
Polymorphic Types Parametricly Polynorphic functions ‘Well Motivated’ Ad-hoc Polymorphism Basic Function overloading Basic ‘Operator Overloading’ Function overloading for symbols that are treated as ‘special’ by the compiler
I think the hashmap case is illustrative for my general perspective. I do see the value in being able to have polymorphism for function arguments which are generic in a type parameter. However, consider that the ideal/most performant hashing function for keys differs not just based on general types (int vs string) but can differ based on something like string length or bit width or signededness. My position is that a language should prioritize the ability to encode those exact requirements in a data structure and difficulties for achieving generic-ness be damned. Each function taking a hashmap as argument should be tied to the optimizations and low level considerations intended by the developer.
I am not opposed to some duplication of code where it produces the appropriate code for the problem being solved. My generalized dislike of ‘generics’ is there, but in my comment above I was mostly discussing ad-hoc polymorphism as a means of enforcing some general reasoning ability onto function name overloading. And as I implied in my scale above I find it particularly distasteful (basic function name overloading), if not actively harmful.
For generics there are two areas often conflated in conversation that I find to be wildly different in formalizations of type theories and languages: first, there is static phase type application associated with System F and higher order polymorphic lambda calculus more broadly. I obviously would like to see a more specific and limited implementation of generics at all levels of abstraction, but the higher the abstraction goes the more ‘sense’ generic-ness makes. Second, there is generics as a name for function name overloading, which is distinct from parametricly polymorphic function as well as distinct from generic types. I really dislike this usage of generics and do not think it is a good practice for developing quality software or for readability, maintainability, or efficient optimization. Obviously this is a scale as well. I would put Swift in the lead with Witness Table semantics for generics, then typeclasses and traits, then any less structured implementations at the bottom.
That's a helpful explanation, thank you. I do generally agree that overuse of generics can produce bad interfaces. I also agree that generics tempt people to assume that the type fully determines the desired behavior, rather than giving any other means of selecting it.
(It's worth noting, for instance, that HashMap lets you replace the hasher, if you have some strings with a property that make them more hashable. But if we didn't have that, then the generic would force a given type to have only one hasher, and force a newtype wrapper to change the hasher, which would make for suboptimal designs.)
Thanks again for taking the time to answer! I think I have a bit more comfortable understanding of what's going on. I appreciate it!
> I’m generally opposed to generic functions
I agree there are significant costs to generics (especially readability), but there are large classes of problems that are a right pain without them. Even Go added them eventually.
In (2), I'm surprised to hear your description of Rust's generics as "ad-hoc polymorphism". I tend to hear that term used to describe non-trait based systems, like C++ generics (in the absence of "concepts"), which act like a compile-time version of duck typing. I think of Rust's generics as trait-based polymorphism, not ad-hoc polymorphism, and I prefer the former over the latter. To a first approximation, I see Rust's generics system as somewhat related to Haskell's. I would be interested to better understand how you see the differences.
From the way you're describing it, it sounds like you might not fundamentally object to generics in general, just to the idea of doing it through monomorphization rather than "dyn Trait"-style vtables? If so, then that's understandable. I like that Rust has both options, but I can absolutely appreciate preferring to do everything via vtables, which has both advantages (code size, one kind of conceptual simplicity) and disadvantages (more difficult to do per-implementation optimization, without doing devirtualization which amounts to monomorphization anyway).
We do have some forms of first-class "type functions" or "type constructors" or "rank-2 polymorphism", in the style of Haskell, so that you can be generic over something like `Vec`. It's a little indirect at the moment, going through traits with associated types, and I'd love to see a more direct version where you can literally write `Something<HashMap>` or `Something<BTreeMap>` and have those be type functions of one parameter (Haskell "kind" star -> star).
In any case, we have talked many many times about the idea of having more global options to say "don't monomorphize by default, do everything with trait objects". We also are likely to build a stable ABI atop trait objects and vtables eventually, so that it's possible to pass around pointers to data structures and their associated functions, without relying on the layout of the structure.
For (1), I do think we need some mechanism to integrate dependencies. I can appreciate the aversion to the default of "get things from the network". We do try to have good support for vendoring and similar, and this is critical for many projects (e.g. Rust in the Linux kernel, or Rust in CPython, are not going to allow downloading dependencies from the network). All that said, there is a tradeoff between "one first-class package manager and build system" and "lackluster support for various build systems", and Rust picked the former deliberately. We do like being able to implement things in rustc and plumb them through Cargo, so that they're available through the whole stack when that's necessary to make a feature useful. But we also have many users who need to use rustc without cargo, and who ensure that rustc features work with other build systems, notably large corporate monorepo build systems.
As for (3), fair enough, that is very much a philosophical difference between you and Rust, and Rust isn't likely to change that. I do think we're going to make ever more sophisticated ownership semantics in the future (e.g. making self-referential data structures possible), but I doubt Rust's model will stop fundamentally being based around ownership and borrowing.
I just wanted to drop a quick comment to clear up your first question. The term ad-hoc polymorphism to describe both Haskell and Rust’s typeclasses/traits is taken directly from Wadler and Blott’s paper which introduces the idea/concepts of type classes to Haskell. The name of that paper is ‘How to make Ad-Hoc Polymorphism less Ad-hoc’. This paper laid the groundwork for the implementation Rust uses and it is a mechanism for restraining ad-hoc polymorphism. But I think the term still applies to both Haskell and Rust’s typeclasses. Ad-hoc polymorphism is not a derisive term (when used as a term of art in discussions of implementations of programming languages), it is merely the PLT way of saying function name overloading. Rust and Haskell use very similar system to impose restrictions and semantic guiderails on ad-hoc polymorphism, but both languages still have it. To sum, I certainly do not mean any negative connotation with the term, I feel I am using it appropriately and as intended in this domain of discourse.
PS. I intend to write a more substantive reply to your comment, but didn’t think I should leave this unsaid.
I didn't take it as having a negative connotation; I just didn't interpret it in the manner referenced in that paper, and instead interpreted it as being not based on traits/concepts. Even given that, I didn't take it as negative; some people prefer the C++-style model, just as some people prefer dynamic typing.
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.
> 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”).
LLVM is also free
[dead]
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.
> 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.
> 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.
You missed that Microsoft has several Rust contributors and is one of the main sponsors of using Rust in Linux, alongside Google.
Many forget that Microsoft went from "FOSS is bad", to now having their fingers across many key FOSS projects.
They are naturally not the only ones, a developer got to eat, and big tech gladly pays the bills when it fits their purposes.
Rustc (+ LLVM) already is a free compiler.
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.