shepmaster

That’s what https://doc.rust-lang.org/std/primitive.f32.html#method.min is for

I believe there’s a joke being missed, by you or by me. The paper says

    diff --git a/src/exec.c b/src/exec.C

I don’t think git existed in 1975 ;-)

I’ll assume that you are in on the joke and I am not, however!

And even then, I try to update any SO questions and answers that are still useful to the latest edition, as it’s more likely someone who doesn’t know about editions will be playing around with 2018.

I agree which is why I write SNAFU

https://docs.rs/snafu/0.6.6/snafu/

Conversely, the upvote button (which I used for your point) doesn’t perform a full refresh. Both are good.

> If Rust devs took an everyday English word and gave it a different meaning

Perhaps, but if we had come up with a new word, you or someone else would complain that we had done that instead of using a word that people already "understood". :-)

English is a language full of elision, and there's nothing inherently wrong with using one word for closely related meanings. When being precise, Rust uses the term "memory unsafety", but we humans usually shorten that to just "unsafety" because we are lazy.

My point was merely to state that a function throwing an exception [1] doesn't introduce memory unsafety.

---

[1] Notably, we call this "panicking" in Rust-speak; does the fact that we call it something different from "exceptions" confuse people? Probably at least one.

> so that I can do things like internationalization

Can you expand a bit on how you do this internationalization? I've got a low-priority issue [1] to investigate how to integrate SNAFU and Fluent to get i18n for error messages, but knowing how someone does it today would be super helpful!

[1]: https://github.com/projectfluent/fluent-rs/issues/107

It's not clear if you are continuing to refer to Rust as your parent post did, but if so, note that this is not the standard Rust meaning for "unsafe". Using it in such a way makes it more complicated to discuss and explain the Rust-specific meaning.

I am! It's something I care about, but not sure if there's something I can do about it. The code blocks are powered by a `<script>` tag from GitHub's Gists. Unfortunately, I don't have the ability to edit that post without Wordpress completely removing those tags (I don't have appropriate permissions). I can ask for them to put `<noscript>` tags, but don't know if that will really help.

You are quite welcome!

I can't add much to the Haskell part as I've only ever used it sparingly. In many aspects, I view Rust as only having one or two small things that are new (or at least new in a non-research programming language). Its big strength is combining a lot of existing good ideas in a principled manner.

I wouldn't want to mention any language I don't have experience with for the risk of mis-speaking. I also tried to minimize talking about any specific language where I could.

I don't know the current state, but I hang out in the Zulip room dedicated to the work on the optimizations

- https://rust-lang.zulipchat.com/#narrow/stream/189540-t-comp...

> If Rust supported "pluggable" allocators in some fashion

It's coming, but it's still unstable and being actively developed

- https://github.com/rust-lang/rust/issues/32838

> because it’s new in the same way Haskell is new to a Java dev

Do you have any hypotheses about why we don't see as much publicity for Haskell then?

You are quite welcome! Hope to see you writing some Rust sometime!

> % of developers who are developing with the language or technology and have expressed interest in continuing to develop with it

https://insights.stackoverflow.com/survey/2019?__hstc=188987...

Most are that good, or better. I actually debated putting that error because it's one that doesn't have a "help:" line that actively suggests how to fix it.

Some errors are admittedly worse, and people like estebank are actively working on improving them.

Yup, which is what I alluded to with "However, the roughly 97% of survey respondents who haven’t used Rust" :-)

I’ve seen and used issues as “thank yous”. As a developer, I don’t mind this misuse of the issues :-)

See also "Safe Systems Software and the Future of Computing" by Joe Duffy, the closing keynote at RustConf 2017:

https://www.youtube.com/watch?v=CuD7SCqHB7k

Midori and Rust have several striking similarities, and Microsoft's recent uptick in interest in Rust (and Rust-like languages) bodes well for improved software quality.

Rust has books [1] as well as the usual terse API docs [2], so that also seems unlikely.

[1]: https://doc.rust-lang.org/stable/book/

[2]: https://doc.rust-lang.org/std/

Thanks for the additional points! What you state is true, but somewhat orthogonal to the point that the grandparent post was making (and I sought to refute).

Creating an allocator is inherently possible. Using that allocator with the rest of the ecosystem is currently not stable, as you point out.

As a sometimes Rust embedded developer, I look forward to both parameterized allocators and fallible allocation.

You can implement an allocator in Rust; it's unclear why you think this is not possible.

One example:

- https://github.com/fitzgen/bumpalo

A benefit of SNAFU is that the `From` trait is implemented against the internal-by-default context selectors. Since enum variants are public if the enum is, SNAFU also offers a way to wrap an opaque newtype around the internal error, allowing the implementor to choose exactly what public API their error exposes.

Some also produce backtraces on today's stable Rust and previous versions as well. SNAFU can produce backtraces back to stable Rust 1.31.

> but you can use some quick and dirty macros for that.

That is the point of most of the libraries described in the article — to prevent having to recreate this particular wheel each time you need it. Do all Rust programs/libraries need one of the libraries? Not at all, but I find that using one that has some nice bells and whistles will encourage the programmer to improve the errors and their messages.

I do believe it's non-zero, as the stack has to be walked and potentially symbols are looked up. The symbols can be delayed until display time, but the stalk walk is "now or never", as I understand it.

SNAFU addresses this by allowing `Option<Backtrace>` in the error struct. The backtrace is only captured when an environment variable is set by the end user.

> The most irksome thing remaining is to have to create your own error objects

That's generally the purpose of the libraries outlined in the article — reducing the pain of creating the custom error types.

An unstable `std::backtrace::Backtrace` (https://doc.rust-lang.org/nightly/std/backtrace/struct.Backt...) exists in nightly Rust. If you cannot require nightly, you can use the backtrace crate (https://docs.rs/backtrace/0.3.40/backtrace/) on stable.

Crates like my SNAFU (https://docs.rs/snafu/0.6.0/snafu/) help abstract this away. Whenever the standard library implementation stabilizes, you will likely see many more errors including backtraces.

Like the sibling, I'm not sure if you are serious, but my library SNAFU (https://docs.rs/snafu/0.6.0/snafu/) is similar to this at a step or two higher level. The idea is that you wrap lower-level errors (a file system error) with a higher-level context (opening the config file).

Taken to the extreme, you have a unique context for every possible error source inside your library, which means you could directly search for the name to find the line number.

This does make me wonder how I could add line / file information to an error automatically though.