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

111–120 of 138 posts

Re: Rust GCC backend: Why and how

#111

Post by IshKebab »

throwaway17_17 wrote: post #109
aw1621107 wrote: post #105

Earlier quoted context omitted.

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

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

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

Re: Rust GCC backend: Why and how

#112

Post by nullpoint420 »

muvlon wrote: post #84
afdbcreid wrote: post #58

Earlier quoted context omitted.

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

Re: Rust GCC backend: Why and how

#113

Post by pjmlp »

School-Cotton wrote: post #28
hedgehog wrote: post #24

Earlier quoted context omitted.

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.

Re: Rust GCC backend: Why and how

#114

Post by pjmlp »

pessimizer wrote: post #56
1718627440 wrote: post #19

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

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

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.

Re: Rust GCC backend: Why and how

#115

Post by bigstrat2003 »

compiler-guy wrote: post #79
jacquesm wrote: post #77

Earlier quoted context omitted.

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

You got whooshed pretty hard here. The post you were responding to was a joke.

Re: Rust GCC backend: Why and how

#116

Post by lionkor »

School-Cotton wrote: post #91
throwaway17_17 wrote: post #82

Earlier quoted context omitted.

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

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

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.

Re: Rust GCC backend: Why and how

#117

Post by aw1621107 »

throwaway17_17 wrote: post #109
aw1621107 wrote: post #105

Earlier quoted context omitted.

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

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

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!

Re: Rust GCC backend: Why and how

#118

Post by nextaccountic »

estebank wrote: post #70
nextaccountic wrote: post #65

Earlier quoted context omitted.

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…

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?

Re: Rust GCC backend: Why and how

#119

Post by estebank »

nextaccountic wrote: post #118
estebank wrote: post #70

Earlier quoted context omitted.

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.

Post reply on HN