ibraheemdev

There is work going on to allow crate namespacing (foo/bar): https://github.com/Manishearth/namespacing-rfc/blob/main/000...

https://github.com/junegunn/fzf.vim + ripgrep is really great for that. There is also the native `:vimgrep` command.

What does an IDE give you that (Neo)vim + LSP + Vimspector does?

> can serve almost as much HTTP requests as a Rust server based on Hyper

Do you have a link to a benchmark showing this?

Note that this version of the book has not been updated since 2016. The updated version is here: https://veykril.github.io/tlborm/introduction.html

I believe this would work with type sets:

    type Result[T any, E any] interface {
        T | E
    }

The type sets proposal for Go has already been accepted as a clarification to the generics proposal [0]:

    type SignedInteger interface {
        ~int | ~int8 | ~int16 | ~int32 | ~int64
    }

Interfaces that contain type sets are only allowed to be used in generic constraints. However, a future extension might permit the use of type sets in regular interface types:

> We have proposed that constraints can embed some additional elements. With this proposal, any interface type that embeds anything other than an interface type can only be used as a constraint or as an embedded element in another constraint. A natural next step would be to permit using interface types that embed any type, or that embed these new elements, as an ordinary type, not just as a constraint.

> We are not proposing that today. But the rules for type sets and methods set above describe how they would behave. Any type that is an element of the type set could be assigned to such an interface type. A value of such an interface type would permit calling any member of the corresponding method set.

> This would permit a version of what other languages call sum types or union types. It would be a Go interface type to which only specific types could be assigned. Such an interface type could still take the value nil, of course, so it would not be quite the same as a typical sum type.

> In any case, this is something to consider in a future proposal, not this one.

This along with exhaustive type switches would bring Go something close to the sum types of Rust and Swift.

[0]: https://github.com/golang/go/issues/45346

async-std uses async-task under the hood.

(async-std -> async-global-executor -> async-executor -> async-task)

The underlying implementation sets the task as cancelled the first time it is polled, and then waits for it to stop running [0]. So you could just call `cancel` and poll the future once:

    futures::poll!(task.cancel());

[0]: https://docs.rs/async-task/4.0.3/src/async_task/task.rs.html...

> Nowadays the Rust http libraries to use are warp or axum

Warp and axum are certainly not the only choices, and saying they are the best choices is a matter of opinion. Actix-web, rocket, tide, warp, axum are all great web frameworks.

Cool language, it'd be great if there was a code block example in the README.

Does anyone happen to know if this possible with a Kobo?

It is built on top of Quran.com's API, which is a very reliable source.

There is only one Quran. Perhaps you are referring to differences in line or page numbering?

Is this a repost? I seem to remember seeing this a few days ago.

There was a pre-proccessor for Rust without curly brackets that I can't seem to find now... It actually looked very nice. The two biggest changes I would probably make are square brackets for generics, and in-band lifetimes everywhere.

I would love the pipeline operator in Ruby, but unfortunately the unstable feature [0] was removed:

    1.. |> take 10 |> map {|e| e*2} |> (x)

> After experiments, |> have caused more confusion and controversy far more than I expected. I still value the chaining operator, but drawbacks are bigger than the benefit. So I just give up the idea now. Maybe we would revisit the idea in the future (with different operator appearance).

[0]: https://bugs.ruby-lang.org/issues/15799

I'm guessing it's using forem, the open-source platform that powers dev.to: https://github.com/forem/forem

Have you tried LINQ to SQL?

What's your proposed signature of collect? You have to put a turbofish or type annotation because collect works with any collection implementing FromIterator, not specifically Result. Would you have it only work for Vec?

AWS lambda is built on Firecracker MicroVMs, written completely in Rust. Fly.io uses it as well.

Well the block_on runtime is only meant for testing or bridging sync and async code, so it wouldn't solve the problem :)

I think the OP meant that those who did not want async would use block_on, while the async API would just work for those who wanted to use it.

Well that's just the "simple primitive for 'block the current thread on this async call'", which can, with the new `Wake` trait, be written in around 10 lines of code. The real change would be adding an actual runtime to the standard library.

Because synchronous IO functions block the current thread and return the value directly, while asynchronous function return a `Future`, which will eventually resolve to the value, and can be polled concurrently with other futures as to never block.

    fn sync_read() -> Vec<u8> { ... }
    fn async_read() -> impl Future<Output = Vec<u8>> { ... }
    // the second can be written more succinctly as:
    async fn async_read() -> Vec<u8> { ... }

That would mean a runtime in the standard library, which was explicitly rejected. Different runtimes have different pros and cons and different use cases, choosing one and putting it in the standard library means that all others are second class and probably not well supported. For example, some might want an io-uring based async runtime, while others want a runtime-per-core system for a web server, and another might want a simple lightweight runtime for an embedded environment. Someone else wants to use raw OS primitives without ever spawning a runtime (to use block_on and an async function that does IO, you still need a runtime running in the background). A better solution is to provide standard interfaces for runtimes and libraries to develop against, something that is being worked on.

> There are alternate Discord clients, and — unlike Slack — Discord doesn't try to actively prevent people from writing alternate clients against their API.

Yes, they do.

https://github.com/Bios-Marcel/cordless:

> Hey, so I know this is somewhat of a bummer, but I got banned because of ToS violation today. This seemed to be connected to creating a new PM channel via the /users/@me endpoint. As that's basically a confirmation for what we've believed would never be enforced, I decided to not work on the cordless project anymore. I'll be taking down cordless in package managers in hope that no new users will install it anymore without knowing the risks. I believe that if you manage to build it yourself, you've probably read the README and are aware of the risks. I'll keep the repository up, but might archive it at some point. And yes, you'll still be able to use existing binaries for as long as discord doesn't introduce any more breaking changes. However, be aware that the risk of getting a ban will only get higher with time!

https://github.com/atlx/discord-term:

> Disclaimer: So-called "self-bots" are against Discord's Terms of Service and therefore discouraged. I am not responsible for any loss or restriction whatsoever caused by using self-bots or this software. That being said, there's no one stopping you from risking using an account, so go head!

I think the main issue is not the boilerplate as is usually the source complaints, but the fact that not handling errors is so easy due to shadowing.

Neovim + LSP for C# development worked really great (until I ran into a Roslyn bug...). You might consider that an "IDE" though.

Ruby.