Rust GCC backend: Why and how(blog.guillaume-gomez.fr) |
Rust GCC backend: Why and how(blog.guillaume-gomez.fr) |
Is libgccjit not “a nice library to give access to its internals?”
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.
I'd be very interested if the author could provide a post with a more in depth view of the passes, as suggested!
Yes, please!
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, ...?
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).
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
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).
AFAIK the reason is solely error messages: the customization available with handwritten parsers is just way better for the user.
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.
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.
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.
The rest of the f*cking owl is the interesting part.
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
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...
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.
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.
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.
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.
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.
https://github.com/NixOS/nix/blob/master/src/libexpr/parser....
https://github.com/NixOS/nix/blob/master/src/libexpr/lexer.l
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.
And what google turns up when you enter those exact three words in a row is really none of my business.
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.
Also, in what sense it is more conservative?
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.
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.
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.
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!
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
--- 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.
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?
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?
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).
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.
...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.
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 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 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
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.
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.
Either way, it would just create a GPL fork.
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.
> 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.
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.
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?
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.
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.
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).
This is an irrelevant and disingenious hacker jab (oh look, they’re not a “real hacker”).
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 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.
You conveyed that? How?
Really, what neat little delineation is there between your little OS hack-on world and people using whatever language they want to make their software? There isn’t. Because people on a long-running project can have members who want to move code over or start modules in Rust or whatever language. As is happening in some places.
Beyond that though the projects that one is interested in would need to remain static and not include potentially new projects written in upcoming languages.
Against that backdrop we have you, moaning about lang X potentially infecting your OSS ecocsystem.
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.
> 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.
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?
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.
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?
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.
> 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).
PS. I intend to write a more substantive reply to your comment, but didn’t think I should leave this unsaid.
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).
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 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.
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).
Generate a random number.
> 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++.
Note, that POSIX does have hashmap implementation [hsearch(3)], vectors are just arrays, which are sufficient in C, since types don't have any behaviour like classes would.
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.
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.
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.
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.
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.
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.
(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.)