251–260 of 312 posts
Earlier quoted context omitted.
> about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`) How is that more boilerplate than any other way to have concurrency?
Async/await is commonly suggested as a lighter-weight syntax.
Earlier quoted context omitted.
Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times…
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'.
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 Google IO since it was introduced. Being partially written in Groovy also doesn't help.
Earlier quoted context omitted.
Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex…
My main pet peeve with cargo is lack of support for binary crates. Compiling the whole world, including dependencies is big waste of time. I already tried to play around with workspaces to see if at least crates only get compiled once. With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search.
Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
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.
So do you enjoy packaging code for every single OS, in its own specific way?
I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory.
The cargo approach will end up with windows/node level bloat where every app bundles half an OS.
Earlier quoted context omitted.
"rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.
I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid…
https://edn.embarcadero.com/article/20803
And even today Delphi 10 is quite fast.
Same applies to many other compiled languages with modules.
Earlier quoted context omitted.
That assumes you're using cargo and it's "fuck the package manager" approach.
Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex…
Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager.
> If you're pre-building something and pushing a package for say dpkg or rpm
The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities.
> Should an OS want to bless crates, cargo does have an override for crates.io
That's a recipe for dll hell if I've ever heard one.
Earlier quoted context omitted.
But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.
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.
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…
Earlier quoted context omitted.
> but usually it does far worse Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.
https://michaelfairley.com/blog/i-made-a-game-in-rust/ > It consists of ~7700 lines of Rust ... > Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.
Earlier quoted context omitted.
Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. If you understood the wins of untyped languages, you'd be aware that this is often the most optimal path for a startup to take. Get features done now + fix them later is, in hundreds of cases, the way that startups win. It's also a win for people w…
If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…
I happen to use more often the IDE's graphical debugger than the REPL.
Still Visual Studio has had immediate mode (aka REPL) since VB days, followed by .NET support.