| I am not certain that technical argumentation is required on many, many threads on HN. In fact, TFA is just a blog post about the concept of compiler backends generally. Also, the comment I replied to was not a technical question so I just wrote the response in the same tone. I will maintain that it is absolutely alright to just dislike a programming language for any reason and those reasons if they exist outside of aesthetics don't have to be well formed or technical. But assuming your assertion of genuineness was intended to mean you want a response to those questions: 1) I had no ideal imagined outcome to writing that comment. The parent asked what the GP meant by not liking Rust but that at least Rust could be compiled by gcc. I was just explaining why it may be preferable to someone that does not use (or in this case "like" Rust) to see it able to be compiled by a GPL piece of software that has been a part of the Linux core for almost all of Linux's existence. As to the rest of that question, of course, I don't think that anyone using/enjoying/designing/supporting Rust in any way would be convinced by anything I think or say (I'm just some guy on HN). 2) If I had the power to change what? The issue with Rust not being able to compile using gcc or more broadly concerning change things regarding Rust? I don't think a list of changes I'd make to Rust is what you wanted, so I'll assume you meant regarding compiling Rust via gcc. If I had the power to change Rust from being only compiled using rustc and moved to primarily gcc based I would. And the why is not particularly interesting, I will always prefer actions and decisions that take mind and market share away from anything that can be used to advance the interest of multi-national conglomerate corporations via permissive licensing of the core technologies of computing. I know that is not a technical argument, but it is the reason I'd make the change. I will assert that such a reason is absolutely valid, but I don't take disagreement with my position to be a character flaw in someone. |
| |
| ▲ | pdimitar 6 days ago | parent [-] | | > I will maintain that it is absolutely alright to just dislike a programming language for any reason and those reasons if they exist outside of aesthetics don't have to be well formed or technical. I too am just one guy on HN but when I go to certain threads, I do expect no emotional and preference comments because I want to fill up my blind spots and emerge better educated. Obviously that does not mandate anything from you but since we are expressing preferences, that's mine. RE: the rest, I am trying to understand your POV but can't. Is your issue with the difference between GPL and whatever Rust is licensed under? That I could somewhat understand. But your rather emotionally loaded language against Rust itself I simply cannot and will not take seriously. Apparently Rust has an unique talent to tick people off on HN would be my tongue-in-cheek conclusion here because it has been years since I saw what we might call a "zealot fiercely arguing in favor of Rust" here, so the reason should be somewhere else. Feel free to elaborate on that, though I am fairly sure such a discussion would not go anywhere. Emotion resents reason; emotion just wants to express itself. But I do get weirded out how many people treat Rust like it's coming to eat their kids and puppies. | | |
| ▲ | throwaway17_17 6 days ago | parent [-] | | I laid out three examples of issues I have with Rust in a sibling comment (which I can never remember how to link), those weren’t exhaustive, merely illustrative. The Rust zealot posting (if they ever really existed) have certainly not been very present in recent years. To your final statement, for me, it is not a Rust specific issue. I would not be in favor of Scala being brought into software I use. As an example, Scala also has characteristics, semantic and syntactic that I strongly oppose and so I ‘don’t like’ the language. Other than the saying I don’t like Rust I can not think of the language above as being emotional. Maybe the communication barrier of text on HN is too much to overcome for a discussion about subjective programming language preferences. As to your, somewhat rhetorical seeming, question about my issue pertaining to GPL vs ‘whatever Rust is licensed under”. Yes I have an issue regarding licensing. But it pertains primarily to LLVM in this instance. LLVM is permissive licensed vs gcc being GPL. I am firmly opposed to the core executables/artifacts of computational technology (compilers, OS, drivers, ISAs, hardware interface standards) being anything other than copyleft. However, I would be willing to adapt to a more restrictive “open source” that allowed for limiting use of software for the betterment of the whole. If I could immediately change anything, it would be to see LLVM stripped of its importance and dominance and put all those resources into copyleft software forcing profligate consumers of technical advancement to ‘pay it forward’ if they want the product of our collective minds and effort. | | |
| ▲ | pdimitar 6 days ago | parent [-] | | Thanks, that's actually helpful (your entire reply). What's your preference about copyleft about? Is it that you don't want corporations to keep leeching off of open source? But they do that already! And of course will do their best to hide it. What some license somewhere says bears nearly zero significance. Even if you catch them red-handed and can prove it in court (a very unlikely and rare combination) it would still take like 5 years for any conclusion to be reached... and it will likely end with financial settlement and no real negative outcome for the corporation. So that battle has IMO been lost already. But if you have something else in mind, I am actually interested to hear it. I am rather cynical and not very well informed on licenses. To me they simply have no real teeth and that's why I lost interest in knowing more. Still, not taking an interest in something innately means that one is having a rather big blind spot. I recognize that about myself. -- RE: Rust / Scala etc., thanks, that puts things into better context. But I still don't get why would you be against a language becoming more pervasive. Are you maybe convinced that the PL is only driven by hype and not merit? Or is it some other reservation / protest / consideration? | | |
| ▲ | throwaway17_17 6 days ago | parent [-] | | 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. | | |
| ▲ | pdimitar 5 days ago | parent [-] | | 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). |
|
|
|
|
|
