51–60 of 110 posts
Earlier quoted context omitted.
Even on those platforms, it's helpful for distros, who only want one package, not a separate bootstrapping package. I'm real glad we're doing it.
Speaking of non-tier1, is there support for static linking libc when building on/for FreeBSD?
Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at co…
> These are mostly reported using return values of type Error However, unlike more dynamic languages, the return types are usually Result , e.g. writing to a file or a socket will get you Result , values of which can be Ok(usize) (the number of bytes written) or Err(io::Error) (an I/O error which you can further inspect). Although if you want to, you can use Result > where Error is a trait implemented by types repres…
Yes, this is a more complete and precise explanation. :-) I rather like Rust's error handling in practice—it adds only a small amount of syntactic noise, and even the annoying bits (such as converting and wrapping error types) can mostly be isolated in a single file per project.
Earlier quoted context omitted.
> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…
Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.
Earlier quoted context omitted.
Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.
That sounds like a horrible work environment. Seriously, devs can't choose their favorite tools, or specifically use tools which improve their quality until IT approves it? I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.
You come in, develop the modules you were hired for, using the existing stack and leave for the next gig.
This is why regardless how good someone might brag about his/her C and C++ skills, they don't scale in this type of environments.
Earlier quoted context omitted.
You can write your own code in stable Rust while using tooling that works on nightly. Rustup.rs makes it very easy to switch between stable and nightly.
Assuming you are allowed control over the development environment, which isn't possible in many companies.
Earlier quoted context omitted.
Speaking of non-tier1, is there support for static linking libc when building on/for FreeBSD?
I am not sure, but I don't think so right now. I don't know how FreeBSD and MUSL interact.
Earlier quoted context omitted.
Will we maybe also get official musl-host builds accessible via rustup and automatically fetched on such a platform?
We are always interested in adding more platforms. I don't remember if there are any open issues with a MUSL host; I vaguely remember something about compiler plugins?
Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at co…
I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too.
I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not actually a language feature. The performance hit, if you selectively opt-out for profiled critical paths (and thoroughly review them), is usually very small.
In my opinion the default should switch to "opt-out" instead of "opt-in" for Release builds.
Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at co…
The main idea is that most panics (in parsers) are going to be caused by using the indexing operator on slices containing the untrusted input, so we wrap the input in a type that hides the slicing functionality, giving us only methods that return 'Result's.
nom is a much fancier thing which, IIUC, solves the same problems, and more: https://github.com/Geal/nom.
Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at co…
> 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak. I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not a…
Yeah, I remember when the debug-mode overflow checks were added right before Rust 1.0. There wasn't enough time remaining to thoroughly measure the performance impact of these checks in release mode or to implement compiler optimizations to reduce the cost. So IIRC, the decision was made to allow integer overflows to panic, and to turn on checks in debug mode so that the ecosystem wouldn't come to depend on the absence of checks.
But AFAICT, the debug-mode checks are basically still a placeholder for some indefinite future version of Rust that wants to fix this issue properly, if the performance cost can be made low enough. And in the meantime, you can still turn the checks on for release builds if the performance hit is acceptable for your application. I'll consider your recommendation when building binaries in the future!