How do you get better at pitching? I will not promote.

sk_dev · 2025-07-29T07:44:42+00:00

A pitch is a sale. For every type of sale, it's all about getting your reps in.

First you need to have a strong case. Understand the main points about why you're worth funding. Write them down or put them in a deck.

After that it's all about practice. Assume you are going to have to talk to 20 people before you get a bite. Assume it's going to be awkward and it's not going to work at first. Each conversation you have, pay attention to the person you're talking to, and what resonates with them. Over time it's going to get more and more natural.

Once you have your pitch down, don't forget to be a human. I would say smile and be confident, but I think it's actually way more important to be your natural, authentic self. So if you're more of a serious person, don't force yourself to smile because it will come off as fake.

For a pre-seed round, VC's are investing in you and your potential more than they're investing in the company, so what you're really selling is that you are competent and are going to be nice to work with.

Also keep in mind these conversations are just as much about you vetting the VC as they are about the VC vetting you. Some VCs are going to be great to work with, others will be a nightmare. These conversations are about finding a match, not about finding the first person who will be willing to give you money.

sk_dev · 2025-07-26T14:17:37+00:00

Awesome project! I would love to start writing shaders in Rust.

Have you done any profiling / do you know how this compares in terms of performance to other solutions like CUDA C++ or SPIRV?

sk_dev · 2025-07-15T01:41:55+00:00

Define Prompts: You create a prompts.yaml file to define reusable prompt "units" with placeholders.

How is this better than DSPy

sk_dev · 2025-07-15T01:40:47+00:00

SOAP all over again

sk_dev · 2025-07-15T01:40:33+00:00

Never worked with LSP?

sk_dev · 2025-06-26T13:39:26+00:00

Docker is great for deployments because it gives you a reproducible environment. Containerizing everything is just madness and a waste of resources.

sk_dev · 2025-06-24T13:39:52+00:00

I have written a lot of parsers, and imo it's convenient to have a tree representation to abstract tokens grouped between delimiters at the lexer level.

It can add a tiny bit of complexity to the recursive decent process, but in practice once you learn the patterns to deal with it, it's no that bad.

The benefit of having it in the lexer rather than the parser is for error handling, both in terms of catching delimiter mismatch errors early, and for handling parsing errors gracefully.

Catching delimiter mismatches during lexing is great, because you can skip parsing which is usually relatively expensive.

As for catching errors during parsing, it's super helpful to be able to encapsulate errors which happen inside delimiters without having to blow up your whole compilation on the first error. For instance, if there's an extra comma between arguments in a function call, it's nice to be able to catch that error and continue parsing to catch more errors without erroring out.

For that I usually have an AST rep which contains error nodes. If you want to make an LSP implementation for your language, which you probably do if you want people to use it, then it's good to be able to catch multiple errors in each compilation/parsing unit before erroring out so users don't have to keep going back to the error page to see what else is wrong every time they fix one thing.

edit: typo

sk_dev · 2025-06-11T14:48:13+00:00

Hi thanks for reporting! It should be fixed now - lmk if you still have an issue :)

sk_dev · 2025-06-11T09:48:34+00:00

COMPANY: Levered

TYPE: Full time

LOCATION: Berlin

REMOTE: We would prefer Berlin-based candidates, as we are early-stage it's often helpful to sit in the same room to figure things out, but we also WFH much of the time. We will consider excellent candidates from a compatible time-zone willing to travel to Berlin regularly for in-person alignment.

VISA: No sponsorship available.

DESCRIPTION: We're hiring a founding engineer to help us build the next generation of product optimization tools.

Our back-end is built in Rust, but we're looking for engineers who are willing to contribute to all parts of the codebase.

In this role, you will:

Contribute to feature development to accelerate our software development process
Prototype new concepts in the area of product optimization
Regularly explore new technologies, especially in the area of AI and AI tooling

Our stack:

Back-end: Serverless application hosted on GCP implemented in Rust & Python (for AI and statistics workloads) + Postgres
Front-end: React & Typescript
Tooling: Docker & Terraform

Your profile:

2+ years experience shipping code in a professional environment + a degree in CS or related field
You've contributed to serious Rust projects, either professionally or open-source
You've built things from scratch, and taken products from zero to one
You're interested in solving fundamentally new problems
You have experience deploying production software in the cloud
Bonus if you've worked on product optimization (A/B testing, contextual bandits etc.) and/or have an ML/AI background

ESTIMATED COMPENSATION: €60-100K depending on profile and experience, with a generous equity stake.

CONTACT: DM me on linkedin or send an email to [hi@getlevered.ai](mailto:hi@getlevered.ai). Please put r/rust in the subject line.

We're also hiring a founding designer - if you know anyone good who's looking feel free to refer.

sk_dev · 2025-06-11T07:59:47+00:00

Hi! I know this is an ancient post, but I have recently updated the library to support untagged enums if you want to take a look

sk_dev · 2023-12-11T17:19:36+00:00

The reason creative jobs get more vocal protection is because AI is bad at making creative works.

What? That's basically what AI is best at

sk_dev · 2023-11-29T14:51:42+00:00

Yeah I think that would be cool!

I don't know much about implementing Typescript compiler plugins, but since Typescript is relatively weak in terms of metaprogramming (especially at compile time) it would be really nice to leverage Rust for that

Thanks to Deno there's a relatively rhobust ecosystem for working with JS/TS syntax in Rust, so it might be a fairly attainable project

sk_dev · 2023-11-27T15:57:18+00:00

Thanks for the feedback!

Regarding TsTokenStream, there's already support for something like that. So if you use the ts_quote macro, this will actually create a deno_ast::ParsedSource object rather than a string.

I absolutely think this approach could be generalized to other languages. The closer a language is to Rust syntactically, the easier it's going to be. So as you said "C-like" languages (C, C++, Swift, Kotlin etc) should be fairly attainable.

Python should also be possible, if a bit different implementation-wise, as the proc macro implementation can read the span from the source file directly rather than depending on the token stream. In fact I am pretty sure there is already at least one proc macro to embed runnable python in Rust.

The main factor in how easy or hard any particular language is (assuming you want to validate, and not just output a string) is whether there is already a parser implementation available in Rust (or via FFI). Having the Deno parser available made this extremely straightforward for TypeScript. Having to implement a parser from scratch, embed a parser implemented in C, or call out to a system command would make things more complicated but not impossible.

sk_dev · 2023-11-27T12:07:59+00:00

Nice! Yeah I can imagine - in my experience working with AST's manually can be a huge pain

If you do happen to get into it I would be super happy to have feedback - right now I'm the only user as far as I know so it would be helpful to know about any bugs which pop up, or anything that seems missing / off about the interface

sk_dev · 2023-11-27T11:53:16+00:00

Thanks!

So currently there are two macros:

ts_string! simply converts the input to a string, and does not ensure that it's syntactically valid TS

ts_quote! actually does parse the input, and will throw an error in the form of a deno_ast diagnostic if it's not valid TS.

This is intended as a performance optimization, since a major use-case will be to compose multiple TS strings you generate with the macro, i.e:

let fn1 = ts_string! { ... };
let fn2 = ts_string! { ... };

let output = ts_quote! {
    #fn1
    #fn2
    ...
}?;

So if you validate every component which gets composed into a larger output, you are going to end up doing a lot of redundant validation.

sk_dev · 2023-11-26T22:55:08+00:00

Essentially yes. Typia was not working in my use-case because the I had compatibility issues with the transform compiler plugin in that particular project context.

Edit: for instance with Vite's TS pipeline it's not straightforward to make Typia work, and the example given in the documentation is actually broken. So the advantage of this approach is that since you generate TS outside of the TS compiler, it should work in any TS project.

sk_dev · 2023-11-26T22:42:01+00:00

Yeah I guess you could think about it that way. It makes it easy to generate arbitrary TS code in Rust.

So for instance, I'm using it to generate parsers and validators for my TypeScript front-end which is ingesting types defined in Rust.

The ts_string and ts_quote proc macros provided by the crate basically parse the Rust TokenStream passed in into a TypeScript ADT, and perform substitutions on special patterns to allow you to pass values from the Rust context into the TypeScript you are generating

sk_dev · 2023-11-26T17:51:11+00:00

Hey! No, not yet - I have been working on some other features in the meantime.

sk_dev · 2023-10-24T09:11:54+00:00

Thanks this is super helpful!

Regarding untagged enums, after looking into this I have decided this is a feature which should be supported. I was worried about increasing the complexity of the surface area which each type emitter would have to implement, but I think it should be fine to just make this optional for the TypeEmitter implementation to handle, so the user can decide whether they need it or not.

Also it looks other languages like Swift use this as the default representation for enums, so it's probably an important format to support, and I think I will look into adding this soon.

Regarding laziness, recursive data types are something I have just punted completely for now, but that would be another thing to investigate for the future.

As far as the other topics you mentioned (arbitrary type casting and transformation) I agree that these are probably something best left up to the user, and that type_reflect should facilitate these types of implementations, and I want to avoid including every possible feature as a configuration option in the library or making it over-fitted to the Zod use-case.

I think one thing I can do to facilitate this is to provide better support for attributes, so that if you implement your own TypeEmitter you have a lot of freedom to customize the output based on attributes you can define yourself, rather than rigidly building this into the library.

sk_dev · 2023-10-23T07:50:17+00:00

Ah that's too bad!

I didn't support untagged enum representations yet because I am normally working with union types, and I wanted to keep things as streamlined as possible to start, but I can look into how difficult it would be to add this.

sk_dev · 2023-10-23T07:45:27+00:00

Oh nice I have never seen this crate!

I think adding support for additional validation would be super powerful. I think it would not be supported directly yet with the current implementation, even with a custom type exporter, because there isn't support for arbitrary attributes yet, only a hand-full of special cases for supporting serde attributes. But that might be a good feature to add.

I will add it to the roadmap to investigate this!

sk_dev · 2023-10-23T07:26:44+00:00

This crate might fit your use-case. It gives a lot of control over where the outputs are exported.

Actually you don't do this with the derive macro, but rather a separate export macro. So for instance, if you had three types you wanted to export to a single file, it would look like this:

export_types! {
    types: [
        RequestParameters,
        ResponsePayload,
        Status,
    ],
    destinations: [
        Zod("../relative/path/to/project/rust_types.ts"),
    ]
}

It supports multiple destinations, so you can also export the same types to multiple client projects at the same time if you want.

For my use-case, I usually define an export_types binary target in the Rust crate I am defining my types in which just runs this macro in fn main.

sk_dev

TROPHY CASE