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

Two years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

291–300 of 312 posts

Re: Two years of Rust

#291

Post by nickpsecurity »

kibwen wrote: post #197
steveklabnik wrote: post #31

Earlier quoted context omitted.

Mrustc is one; my understanding is that it isn't yet , because its purpose in life is to make bootstrapping/ddc stuff easier. Once that works, I thought it intended to add the stuff that's missing. There's another that's not public.

> ddc stuff Note: this refers to "Diverse Double Compilation", which is a mitigation tactic against Reflections-on-Trusting-Trust attacks.

I suggest you email the team that did the C formal semantics about doing one for Rust. They did it in K Framework (Maude-based) with a front end, KCC, designed to be usable like GCC. Their other work includes functional and logic languages. A team that did an executable semantics for all of those seems ideal for a formalized compiler for Rust given it's like several styles combined. Their rewriting based tools could probably handle at least a subset. Then you get DDC for free plus a way to equivalence check reference compiler for certain features.

https://github.com/kframework/c-semantics

http://www.kframework.org/index.php/Main_Page

Re: Two years of Rust

#292

Post by flukus »

steveklabnik wrote: post #286
kbenson wrote: post #283

Earlier quoted context omitted.

While I understand your point, there is a difference between something installed through cargo for use in building software (in the manner rust does, where it's generally statically compiled), and something installed through the package manager for use in running the system . If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the pr…

> I wouldn't expect cargo to be the normal way to distribute software To be clear, neither does the Rust team. You're exactly on point here.

> Next, I'll introduce you to a tool called Cargo, which will help you write real-world Rust programs.

From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages.

After this conversation I thought I should expriment more with rust and it's linking options and quickly ran into an error of some sort (quite possibly a system one) trying to buils hello world with dynamic linking:

http://stackoverflow.com/questions/44012802/rustc-and-prefer...

Re: Two years of Rust

#293

Post by flukus »

AsyncAwait wrote: post #278
flukus wrote: post #244

Earlier quoted context omitted.

Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.

True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.

No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.

Re: Two years of Rust

#294

Post by steveklabnik »

flukus wrote: post #292
steveklabnik wrote: post #286

Earlier quoted context omitted.

> I wouldn't expect cargo to be the normal way to distribute software To be clear, neither does the Rust team. You're exactly on point here.

> Next, I'll introduce you to a tool called Cargo, which will help you write real-world Rust programs. From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages. After this conversation I thought I should expriment more with rust and it's linking options and quickly ran i…

(I did write the book, yes :) )

> That implies that rust can't be used without cargo right there.

rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year.

Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. It's like the difference between Make and pbuild or a similar tool; see the parent comment about "./configure && make" vs a system package.

> And I'm not seeing any libraries published as ubuntu packages.

Debian has an entire tool, https://crates.io/crates/debcargo, which automatically re-packages a Cargo package into a .deb. Currently, they only package the Rust compiler itself and Cargo, but this work was done specifically so that programs in Rust could be included in the distro, but packaged the way distros like. They've mostly been working on that stuff; I assume by the time Buster's cut-off date happens, there'll be some stuff; I'd like to see ripgrep, personally.

I haven't used -C prefer-dynamic in a while; usually SO questions get answered relatively quickly though.

Re: Two years of Rust

#295

Post by kbenson »

flukus wrote: post #293
AsyncAwait wrote: post #278

Earlier quoted context omitted.

True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.

No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.

Well, there is benefit to the platform, I think you've just misinterpreted it's use.

Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.

Re: Two years of Rust

#296

Post by flukus »

steveklabnik wrote: post #294
flukus wrote: post #292

Earlier quoted context omitted.

> Next, I'll introduce you to a tool called Cargo, which will help you write real-world Rust programs. From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages. After this conversation I thought I should expriment more with rust and it's linking options and quickly ran i…

(I did write the book, yes :) ) > That implies that rust can't be used without cargo right there. rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year. Second, again, Cargo is a tool you use to build your software, not necessari…

> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software.

The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.

And because static compilation is also a distribution mechanism (just not for the end user) the binaries are 10 times larger than grep, not to mention a giant GPL trap for commercial users.

Re: Two years of Rust

#297

Post by burntsushi »

flukus wrote: post #296
steveklabnik wrote: post #294

Earlier quoted context omitted.

(I did write the book, yes :) ) > That implies that rust can't be used without cargo right there. rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year. Second, again, Cargo is a tool you use to build your software, not necessari…

> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installa…

> SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.

Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it using cargo if you're a Rust programmer. Why did you leave that out?

You might also consider looking at the actual README of the project[1], which lists several more installation options, including using brew, chocolatey, pacman, emerge, dnf, yum and nix. There is clearly an effort to suggest that users install ripgrep using their standard system package manager.

Some of the points you've made in this thread are valid concerns, but please don't misrepresent other peoples' hard work while you're doing it. It's extremely rude.

[1] - https://github.com/BurntSushi/ripgrep#installation

Re: Two years of Rust

#298

Post by steveklabnik »

flukus wrote: post #296
steveklabnik wrote: post #294

Earlier quoted context omitted.

(I did write the book, yes :) ) > That implies that rust can't be used without cargo right there. rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year. Second, again, Cargo is a tool you use to build your software, not necessari…

> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installa…

We have resisted adding features to Cargo that would make it better for end-user distribution, and the RFC for "cargo install" made it explicit that it's a non-goal. It's for distributing stuff for Rust developers, like additional Cargo commands, not for general end-users.

Re: Two years of Rust

#299

Post by flukus »

burntsushi wrote: post #297
flukus wrote: post #296

Earlier quoted context omitted.

> Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installa…

> SPeaking of ripgrep, take a look at the installation section of ripgrep ( http://blog.burntsushi.net/ripgrep/#installation ) "cargo install ripgrep" is an installation option. Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it usi…

Sorry, I didn't mean to imply that cargo was the primary distribution method, merely that it was one and that cargo has gone well beyond being a build tool. Rereading the comment I can see how you interpreted it that way. I could have been any app built, ripgrep was just the only one that came to mind.

Re: Two years of Rust

#300

Post by flukus »

kbenson wrote: post #295
flukus wrote: post #293

Earlier quoted context omitted.

No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.

Well, there is benefit to the platform, I think you've just misinterpreted it's use. Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate . For the regular, non-developer user that needs a module to…

> Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby.

As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.

Post reply on HN