@stevenroose wait, what does bitcoin have to do with it?
The rust-bitcoincore-rpc crate uses the jsonrpc crate which depends on hyper v0.10.19. Which is affected by this issue.
So we will have to migrate those crates to a different HTTP stack. One of our criteria is manageable dependency trees.
@stevenroose oh, that makes sense. For some reason I thought it was the other way around, the base64 create depending on the bitcoin one :-)
That escalated quickly.. I have to disagree. I very much enjoy the language and it seems their promise of memory safety also still holds.
lightweight can mean a variety different things
- not introducing unnecessary overhead at runtime [x]
- having a minimal standard library so if something turns out to have been a bad idea ten years from now, there'll be no burden of maintenance [x]
- having a compiler that fits on a floppy disk [ ]
- having software run fast because the compiler was smart and complex enough to make optimizations on high-level code [x]
i checked those that apply to rust.
I see a lot of hate, but no real arguments against the language.. I'm confused. I've been using Rust full time for work in the last year and it's been a blast. Very much enjoying it and never have much trouble except for the occasional moron crate maintainer that makes a breaking change in a minor version update so we have to solve the mess.
@caseyp @feld @lanodan
@stevenroose Rust 1.31 fixed usability problems of modules, and the base64 crate chose to use the newer syntax internally.
The oldest Rust version that is officially supported by the Rust team is 1.37.0.
Well, that's a big part of the problem. How can a team developing a systems programming language abandon each release after a few months..
@stevenroose The idea is that the compiler is backwards-compatible and automatically updates, so you never have a reason to stay on an old version.
It's exactly the same thinking as the change from the Internet Explorer upgrade model to Chrome upgrade model.
@stevenroose It is of course a shocking difference compared to C's "C 1999 is still too new in 2019" approach.
There are two major features Rust wants to release (async and const generics), and may slow down after that.
@kornel The flipside is that when your codebase is v1.19-compliant, you get a heckton of warnings printed about all kinds of things being deprecated.
But well, backwards compatibility is of course awesome. But there are reasons to stay on an older release, though: https://github.com/marshallpierce/rust-base64/issues/112#issuecomment-520907539
@stevenroose Rust ecosystem doesn't support Debian, sorry. You will have *endless* pain if you try to use Debian's unsupported Rust versions. It's rustup-or-nothing.
@stevenroose At Cloudflare we use Debian, but make our own Rust .deb.
@stevenroose @kornel debian trying to be c's package manager: "oh yeah, we give you outdated software, but don't worry about security issues! when we hear of security issues in the upstream project, someone from our team will start editing critical parts of other people's c code until it compiles again, then we'll ship it to everybody. also, two thirds of our package names end with -dbg or -dev, because all software has header files and debug symbols, doesn't it?"
@stevenroose It definitely tries to follow a successful model. Cargo is very similar to npm. Language's backwards compat + continued evolution is similar to EcmaScript. Rustc release trains are the same as browsers' shipping V8 & SpiderMonkey.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.