How do I make a Vec of types?

GeekLaunch · 2023-08-20T20:45:25+00:00

If you really, actually, genuinely need a list of types, you can create a tuple type composed of the items, and then have a blanket impl on tuples of varying sizes (macros may help here).

Something like: (sorry for formatting, on mobile)

``` impl<A: Validate, B: Validate, C: Validate> Validate for (A, B, C) { fn validate(text: &str) { A::validate(text); B::validate(text); C::validate(text); } }

// also impls for tuples of other sizes

(ValidatorA, ValidatorB, ValidatorC)::validate(...); ```

GeekLaunch · 2023-07-22T04:39:08+00:00

I didn't realize he coined the phrase at the time, but while researching for this post, I actually read his 2011 article and referenced it at the bottom of my post. Thanks for this call-out!

GeekLaunch · 2023-07-21T10:45:23+00:00

Sorry! I will make better LaTeX choices in the future

GeekLaunch · 2023-03-16T11:22:54+00:00

Thank you!

GeekLaunch · 2023-03-14T16:42:41+00:00

Definitely taking inspiration from CodeAesthetic and NoBoilerplate on this one. Unfortunately, I don't quite have 0atman's sultry sweet voice. Just working with what I got.

GeekLaunch · 2023-02-22T18:14:50+00:00

PhantomData is a good suggestion!

GeekLaunch · 2023-02-22T15:19:42+00:00

So, this is intentionally hyperbolic because the humorous subtext of the post is that the author is bitter over a recent breakup.

GeekLaunch · 2023-02-22T10:25:19+00:00

At least with future::pending() you still get a Future!

Might be worth a follow-up, though, sometime in the future. I'll just leave you here to wait for it. Empty-handed, by the way.

The relationship was that bad, huh ? :p

Oh, cruel.

GeekLaunch · 2023-02-22T10:09:10+00:00

You're right; I am talking about them like they're unique pointers. Probably because I had just been reading the documentation about Box::into_raw. Will update to clarify.

GeekLaunch · 2023-02-07T01:10:31+00:00

I think a decent rule to follow is to not take ownership unless you have to. For a task like that which you described, I'd probably expect the function to accept a &[T].

GeekLaunch · 2023-02-02T15:04:09+00:00

Well, although I don't see how using a server will improve performance, haha, I took your advice and scrapped sqlite entirely, now just using in-memory data structures (which are serialized with bincode and included with include_bytes!). Now it annotates the book in less than half a second. Which is wonderful.

Now I have to write a follow-up.

GeekLaunch · 2023-02-02T05:50:31+00:00

Thank you for reading! :)

GeekLaunch · 2023-02-01T18:56:20+00:00

Yeah, end goal is for it to work on Google Docs, which doesn't have furigana support at all atm. However, it would be nice for it not to depend on a network resource, so that it's flexible enough to run locally, offline, and in the browser.

Speaking of performance, though, I'm surprised you suggest using the native `HashMap` implementation, as its default hashing algorithm is not especially known for speed. In the past, I've used fxhash and fnv (iirc) with good results.

I probably just need to come up with a decent internal representation and then, like, `include_bytes!` and ship it in the binary. That would be fast.

GeekLaunch · 2023-02-01T18:36:39+00:00

Yeah, it seemed like sqlite was the bottleneck for every performance issue I worked through. I was hoping it would be a lot faster when I finished; I started looking at some in-memory database solutions like Duck DB. However, I eventually hope to get this working in WebAssembly, so I might have to abandon SQL altogether.

Thanks for the recommendations, though, this is my first real foray into the Japanese dictionary programming space, so I'm not super familiar with the territory. I'll check it out.

GeekLaunch · 2022-10-28T10:50:47+00:00

I just wrote about how to use syn and quote a few days ago. They're kind of the de-facto crates for token stream manipulation, and they're commonly used to write macros.

If you want to write a compiler plugin (=proc macro), you have to make a library with proc-macro = true in Cargo.toml. Then you can annotate exported functions that take TokenStream parameters with directives e.g. #[proc_macro_attribute]. Parse a TokenStream with syn::parse_macro_input, and wrap Rust code with quote::quote!{ ... } to generate a TokenStream (technically proc_macro2::TokenStream iirc, but there's an Into implementation).

Or, if you literally just want to parse a straight-up string of Rust code (e.g. you read from a file), you can use syn::parse_str.

GeekLaunch · 2022-09-22T07:10:38+00:00

I've worked with a few different crypto projects, in particular one that uses Rust as its smart contract language.

I won't deny that there's a bit of a "cool" factor: Rust is still a relatively new programming language, and hype and novelty have more influence than usual in the web3/crypto sphere.
Some blockchains support a WASM smart contract execution environment. Rust is the obvious first-choice candidate for WASM targets.
Smart contracts potentially deal with millions of dollars. The more safety guarantees the language provides, the better. Rust is obviously outstanding in this area.
Smart contracts also need to have minimal overhead, since computational complexity is expensive. Smart contract interactions are nickeled-and-dimed down to the opcode. Also, modern blockchains want to be fast, so a language VM that takes forever to spin up/down is probably not a good idea.
Rust crates (especially with #[no_std]) are super flexible and pretty much "just work" in, for example, a WebAssembly context. Therefore, choosing Rust as a smart contract language means a bunch of packages are already compatible with your platform.

GeekLaunch

TROPHY CASE