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

61–70 of 138 posts

Re: Rust GCC backend: Why and how

#61

Post by throwaway17_17 »

IshKebab wrote: post #52
coldpie wrote: post #45

Earlier quoted context omitted.

> 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, acco…

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

Re: Rust GCC backend: Why and how

#62

Post by [deleted] »

quamserena wrote: post #33
grokx wrote: post #26

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…

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

[deleted]

Re: Rust GCC backend: Why and how

#64

Post by ajb »

eslaught wrote: post #41
grokx wrote: post #26

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…

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

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.

Re: Rust GCC backend: Why and how

#65

Post by nextaccountic »

eslaught wrote: post #41
grokx wrote: post #26

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…

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

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

Re: Rust GCC backend: Why and how

#66

Post by timeon »

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…

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

Re: Rust GCC backend: Why and how

#67

Post by JoshTriplett »

IshKebab wrote: post #52
coldpie wrote: post #45

Earlier quoted context omitted.

> 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, acco…

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

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.

Re: Rust GCC backend: Why and how

#68

Post by JoshTriplett »

throwaway17_17 wrote: post #61
IshKebab wrote: post #52

Earlier quoted context omitted.

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

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.

Re: Rust GCC backend: Why and how

#69

Post by JoshTriplett »

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…

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

Re: Rust GCC backend: Why and how

#70

Post by estebank »

nextaccountic wrote: post #65
eslaught wrote: post #41

Earlier quoted context omitted.

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

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.
Post reply on HN