Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust GCC backend: Why and how

blog.guillaume-gomez.fr

Post reply on HN
Print view View original

131–138 of 138 posts

Re: Rust GCC backend: Why and how

#131

Post by tovej »

colechristensen wrote: post #102
tovej wrote: post #47

Earlier quoted context omitted.

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 co…

"Most" is not all, and I doubt rights have been turned over since the beginning.

Either way, it would just create a GPL fork.

Re: Rust GCC backend: Why and how

#132

Post by JoshTriplett »

throwaway17_17 wrote: post #129
JoshTriplett wrote: post #123

Earlier quoted context omitted.

> 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 ca…

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.

Re: Rust GCC backend: Why and how

#133

Post by JoshTriplett »

throwaway17_17 wrote: post #127
JoshTriplett wrote: post #125

Earlier quoted context omitted.

> I’m generally opposed to generic functions I'd be interested to know how, in your preferred model, you'd handle things like `Vec ` or `HashMap `, 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 Bas…

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.)

Re: Rust GCC backend: Why and how

#134

Post by JoshTriplett »

throwaway17_17 wrote: post #128
JoshTriplett wrote: post #124

Earlier quoted context omitted.

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 Rus…

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 mecha…

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.

Re: Rust GCC backend: Why and how

#135

Post by seg_lol »

jacquesm wrote: post #108
compiler-guy wrote: post #104

Earlier quoted context omitted.

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 pac…

I think you are taking this all way too seriously. Think IP over avian carriers.

You would need two midi connections, one for each direction.

Re: Rust GCC backend: Why and how

#136

Post by keybored »

throwaway17_17 wrote: post #85
keybored wrote: post #78

Earlier quoted context omitted.

> 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 c…

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 objec…

> As I think I conveyed in my original post, I am not against anyone using whatever language they want to make their software.

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.

Re: Rust GCC backend: Why and how

#137

Post by keybored »

keybored wrote: post #136
throwaway17_17 wrote: post #85

Earlier quoted context omitted.

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 objec…

> As I think I conveyed in my original post, I am not against anyone using whatever language they want to make their software. 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…

I have now read your other replies from about four days ago. They go into substantive reasons like the licensing of LLVM. So I have no complaints about those.

Re: Rust GCC backend: Why and how

#138

Post by 1718627440 »

School-Cotton wrote: post #121
lionkor wrote: post #116

Earlier quoted context omitted.

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.

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 poin…

> it doesn't, for example, give you any containers (hash maps, vectors etc.)

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.

Post reply on HN