are actually specified in international standards, which ensures they will be around for essentially all eternity

LOL

I don’t get it!

If the T in Result (and presumably Option) is (), then why not just use is_ok()/is_err() from the caller side?

Other Tips:

• bool has then() and then_some() methods in std now.
• You can transpose() in both directions between ResultᐸOptionᐸTᐳᐳs and OptionᐸResultᐸTᐳᐳs

That is a terrible time to throw away the error. Best to actually check for file not exists error and…

lol

This is unintentionally funny considering how exists() is implemented (which is why we have try_exists() now).

As I mentioned in my other comment, part of the problem is the list of implementers (which gets included as a suggestion) being too big, and maybe sometimes too complex.

This is not inevitable and unescapable, as your comment may suggest. It is, in part, caused by the lack of (mature) support for some type system features, like HKTs.

Luckily, this is not an inherent eternal limitation it Rust. Although, as I already mentioned, we are probably still years away from seeing this problem being fully in the past.

• I take slight issue with your title. Such diesel errors are not your average Rust error.
• Looking at the first example, you should have quickly realized that lack of kind abstractions over types (lol no HKTs) since Rust v1.0 is contributing to the verbosity. Maybe in a few years, with features like GATs maturing, expanding in scope, and being used more in the ecosystem, things will get better!

Most specific and technically relevant point:

• Rust is what we need to turn on concurrent function execution.

You can read more in the RIIR PR.

Used it last month for the first time. It was great.

Documentation is very good.

typst-lsp is also good.

Did it all from neovim, exportPdf = "onSave" as a part of lsp setup, and zathura open in a tiling window manager. zathura auto-reloads the PDF when it changes on disk. So no web editor needed ;)

First class RTL support (which was required for the task at hand) was a very pleasant surprise.

Gotta admit though that I couldn’t figure out why typst-lsp didn’t work initially. Took me some time to figure out that it needs a git repo and files checked in to work. That probably should be mentioned in the README.

And there was the odd behavior here and there, like setting gradients on text elements in table fields actually setting the gradient over the whole table for some reason. Not sure if it was my fault since I was learning on the go, or an edge case not handled.

All in all, would definitely recommend.

don’t do it during working hours (especially commits - if you’re paranoid, use tor)

I wanted to mention not using personal emails or committing from home IP addresses, but thought that was needless to say.

Meh, everyone scaring you into thinking you don’t own your own mind.

Assuming your boss is not the dangerous kind (beyond legal threats), and if the goal is to make it FOSS, then do it using an alias first. Do it differently. Use components/libs/algos from other people at first, even if they are not perfect. Make those parts easily pluggable/replaceable which would be good design anyway. The code then wouldn’t be wholly yours, not even your alias self.

You can join the project later with your real identity as an interested domain expert (maybe a bit after not working for the same boss). Start contributing. Become a maintainer. And maybe take over after a while. You can start replacing non-optimal components/libs/algos with better ones piecemeal.

Oh, and if Rust wasn’t the choice of implementation, use it this time.

As I discovered and mentioned here a couple of months ago, there is a new hyper-util crate that may/should bring a higher-level API interface back. It also predictably brings a hard dependency back on tokio rt. So there is that.

hyper-util was also just mentioned by Sean (hyper dev) in the discussion you linked.

What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian

[closes tab]

Should have told the auditors that stripping symbols is stupid and counterproductive instead of playing along. That segfault a user managed to hit once and only once with their self-built binary, and that useless core file that was left behind, shall hunt you in your dreams forever.

And I love how that commit was merged with the comment “A further reduced binary size! 🎉”. Exhibit number #5464565465767 why caring that much about “dependency bloat” and binary sizes always was, and always will be, a result of collective mania in action.

Initial implementation is written in pure-Rust using only 6 tokens. Impressive.

Yes. That is in part why I mentioned that it’s not a real alternative, and mentioned cargo-vendor as a possible basis for a less manual serviceable solution.

Serviceable, but not necessarily good still. Anti-crates.io extremists would still be better off using an alternative crates registry*.

* That’s something that already exists btw. True extremists don’t have to wait for the HN leak-promised Good Stuff.

• GitHub wasn’t always owned by Microsoft. At least get your dates right.
• Yes, GH shouldn’t be the sole auth provider.

deleted by creator

version can be passed with git actually. And it will need to match with the version set in Cargo.toml from the git source.

I wouldn’t call that an alternative to crate registries though (of which, crates.io is only one impl).

Also tangentially related, cargo-vendor is a thing.

See! Unlike the post from last week, this post actually provides useful and actionable info.

Good luck to the Ferrocene team.

Is everyone genuinely liking this!

This is, IMHO, not a good style.

Isn’t something like this much clearer?

// Add `as_cstr()` to `NixPath` trait first

let some_or_null_cstr = |v| v.map(NixPath::as_cstr)
  .unwrap_or(Ok(std::ptr::null()));

// `Option::or_null_cstr()` for `OptionᐸTᐳ`
// where `T:  NixPath` would make this even better
let source_cstr = some_or_null_cstr(＆source)?;
let target_cstr = target.as_cstr()?;
let fs_type_cstr = some_or_null_cstr(＆fs_type)?;
let data_cstr = some_or_null_cstr(＆data)?;
let res = unsafe { .. };

Edit: using alternative chars to circumvent broken Lemmy sanitization.

If the matches are causing too much nesting/rightward drift, then that could be an indicator that you’re doing something wrong.

If it’s the opposite, then you’re probably doing something right, except maybe the code needs some refactoring if there is too much clutter.

If there isn’t much difference, then it’s a matter of style. I for example sometimes prefer to match on bools in some contexts because it makes things look clearer to me, despite it being not the recommended style. I’m also a proud occasional user of bool::then() and bool::then_some() 😉

Also, if you find yourself often wishing some API was available for types like bool, Option, and Result, then you don’t have to wish for long. Just write some utility extension traits yourself! I for example have methods like bool::err_if(), bool::err_if_not(), Option::none_or_else(), and some more tailored to my needs methods, all available via extension traits.

Macros can also be very useful, although some people go for them too early. So if everything else fails to declutter your code, try writing a macro or two.

And it’s worth remembering, there is no general rule, other than if the code is understandable for you and works, then you’re probably okay irregardless of style. It’s all sugar after all, unless you’re really doing some glaringly wrong stuff.