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

301–310 of 312 posts

Re: Two years of Rust

#301

Post by flukus »

steveklabnik wrote: post #298
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…

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.

What's the policy of crates then? It's clearly being used here as a way of distributing end-user software. If node is anything to go by then this will only increase.

Re: Two years of Rust

#302

Post by kbenson »

flukus wrote: post #300
kbenson wrote: post #295

Earlier quoted context omitted.

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.

> rust is meant to be a systems language

It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for 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.

Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so.

Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.

Re: Two years of Rust

#303

Post by int_19h »

nickpsecurity wrote: post #280
int_19h wrote: post #239

Earlier quoted context omitted.

If I remember correctly, the only reason why Modula-3 is memory-safe is because it requires a GC. That right there is a no-go for a "C++ killer" system language.

Most C++ apps can be written in a GC'd language. It has UNSAFE/SYSTEM for when you want to take chances managing your own memory. A language like Ada or Rust would be better at unsafe stuff.

Yes, a lot of C++ code out there can be rewritten with GC. But for a language to replace C++, it has to cover the full spectrum, and that includes GC-less operation for low-level components. Providing primitives to manually allocate memory on unmanaged heap is not sufficient - the language must allow running without GC at all.

Re: Two years of Rust

#304

Post by lenkite »

pjmlp wrote: post #252
vvanders wrote: post #121

Earlier quoted context omitted.

Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.

So better try again with straight javac, Ant and Maven. Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse? http://androidbackstage.blogspot.de/2017/04/episode-64-gradl... https://www.youtube.com/watch?v=BKRK4SvMtRk The Android Gradle plugin being slow as molasses is a typical discussion theme at Googl…

Take a look at the Kobalt build system http://beust.com/kobalt/home/index.html

Re: Two years of Rust

#305

Post by nickpsecurity »

int_19h wrote: post #303
nickpsecurity wrote: post #280

Earlier quoted context omitted.

Most C++ apps can be written in a GC'd language. It has UNSAFE/SYSTEM for when you want to take chances managing your own memory. A language like Ada or Rust would be better at unsafe stuff.

Yes, a lot of C++ code out there can be rewritten with GC. But for a language to replace C++, it has to cover the full spectrum, and that includes GC-less operation for low-level components. Providing primitives to manually allocate memory on unmanaged heap is not sufficient - the language must allow running without GC at all.

It does. It just isn't safe. The extra primitives for safer handling of pointers are main advantage of C++, D, Rust, etc. A worthwhile re-incarnagion of Modula-3 should have something similar.

Re: Two years of Rust

#306

Post by MaulingMonkey »

pjmlp wrote: post #241
brandur wrote: post #201

Earlier quoted context omitted.

Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.

Personal experience. It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD. On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5…

If my github api-fu is correct that's what, 40kloc for the rust side of things? Doesn't seem unreasonable times (vs C++) for a full rebuild on that machine - which I'd generally want to do for anything but the most trivial C++ toolchain bump too (in fact, I'm usually forced to) making a comparison against incremental builds very apples-to-oranges IMO. What's your C++ LOC/full rebuild like?

I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump.

Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.

Re: Two years of Rust

#307

Post by arwhatever »

jmcomets wrote: post #274
Kali909 wrote: post #202

Earlier quoted context omitted.

I've only dabbled briefly in it and read various articles about the new features, but that hasn't been my very limited experience. The syntax and namespace constructs etc all look quite arcane to me, and then there's the borrow checker. Not sure I'd call it simple and intuitive (at least yet, for me).

Having written quite a bit of Rust, I agree with you that Rust is far from simple and not always as intuitive as say...Python or Ruby for example. However, I do appreciate the syntax which IMO is in that sweet spot between conciseness and expressiveness. Finally, the borrow checker is quite the experience. Whenever I banged my head trying to get some snippet to pass BCK, there was always an OH moment where I realized…

I shouldn't joke like that - learning Rust was a 4-6 month long low point my my lifelong professional self-esteem. I think I'm coming out of it now, and am only continuing to use it Because Stockholm Syndrome.

"No technology can ever be too arcane or complicated for the black t-shirt crowd." - Linus Torvalds

Re: Two years of Rust

#308

Post by photojosh »

yorwba wrote: post #227
photojosh wrote: post #182

Earlier quoted context omitted.

> then you'll really wish that you had a REPL Yes. I write roughly equal amounts of C (microcontroller firmware) and Python (overall system control, running on embedded Linux). I absolutely wish I had a REPL for C. When implementing with a new library in Python, I'll usually use iPython to explore it, and if I need to run a decent amount of data through, I'll use a Jupyter notebook. I'd put the difficulty of grokking…

I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.

Good point. I've only been working with AVRs for a few years since I've been at this job, but looks like it might be doable. Thanks for the tip.

Re: Two years of Rust

#309

Post by photojosh »

RhysU wrote: post #275
yorwba wrote: post #227

Earlier quoted context omitted.

I use gdb as a C REPL. You attach it to a binary that has the functions you need, then you can use them with the `p` (or `print`) command. Loops and new function definitions are not possible, but sometimes it's still good enough.

Gdb as REPL is a nice trick. Beaker Notebook might give the notebook parent wants for C work.

Thanks. It won't since all my C work is embedded and mainly systems programming rather than algorithms. But I'll keep it in mind for the next time I have to translate my Python explorations over to C for production.

Re: Two years of Rust

#310

Post by int_19h »

nickpsecurity wrote: post #305
int_19h wrote: post #303

Earlier quoted context omitted.

Yes, a lot of C++ code out there can be rewritten with GC. But for a language to replace C++, it has to cover the full spectrum, and that includes GC-less operation for low-level components. Providing primitives to manually allocate memory on unmanaged heap is not sufficient - the language must allow running without GC at all.

It does. It just isn't safe. The extra primitives for safer handling of pointers are main advantage of C++, D, Rust, etc. A worthwhile re-incarnagion of Modula-3 should have something similar.

So the standard library doesn't rely on GC semantics anywhere?

As I recall, that's the main problem with D: the standard library basically requires GC. Your code might not require it, but the library is always there. On top of that, it's just too easy to accidentally involve GC by using reference types.

Post reply on HN