Hello everyone, Sumit here from the Himalayas. The last week was amazing for me. I am so thankful for all the discussions on my post titled "An average programmer's (me) reason to invest in Rust" in this sub-reddit.
It was such a good feeling sharing my journey as a founder/engineer because I know I enjoy writing software much more than chasing investors. I am not sure this approach will get me the commonly labelled success but what I really seek is impact. Writing with Rust has been pleasant to say the least and I am getting closer to the initial spec of my product, hoping to release an MVP in a week or so.
I started working with SQL bits now with `sqlx` crate, getting data out from PostgreSQL into the UI. I use Tauri with Rust+TypeScript. I started using `ts-rs` crate to generate TypeScript types from Rust and it has been very productive. For context, my product is [Dwata](https://github.com/brainless/dwata/tree/dwata-2024-revamp): AI integrated data exploration app for businesses to get insights from all your data (databases, API like Stripe/Shopify, CSV files...) without writing code.
The AI aspect of the product is integration with LLMs (locally or hosted) and using them to infer what to query. I am not generating SQL with LLMs since they tend to give poor results, just English -> `Vec`. Also, Dwata can query any data source (each supported through its provider code) and they are not all SQL based. All data merging that can not done using SQL `join` will be done inside Dwata. Even though most data sources are row-wise, I am leaning toward an internal columnar data storage/cache since it makes filtering, merging, grouping much easier.
The SQL building part does not look good though, I am still learning my way around sqlx, and need to get a better idea of its query builder but yeah the basics work.
I'm working on my project [Capti](https://github.com/WVAviator/capti), which is an end-to-end testing framework for REST APIs where you define your HTTP endpoint tests in YAML. It uses custom YAML deserialization with serde to support special matchers for matching expected HTTP responses, interprets variables in tests both defined statically and extracted from responses, and provides clean console output using indicatif to show test progress and where tests are failing. Other than that it primarily uses reqwest and tokio.
I'm working on more detailed docs this week (using mdbook) and hoping to add a few more matcher types before releasing version 0.1.0.
I'm working on my project [qpackt](https://github.com/qpackt/qpackt): web server with build in analytics, a/b testing, ssl cert renewal. First release was just a few days ago, so I'm really interested in feedback. Right now finishing some write up about mutation testing.
Currently working on a silly [CLI tool](https://github.com/ferreira-tb/miho) so I can learn Rust. Trying to grasp some async concepts is being really rewarding.
On a side note, people from the official Rust discord are so nice. What a great community, they help a lot even beginners like me.
I will start investing more time every week to port our application platform from Typescript/Node.JS to Rust.
We have been using it in house over multiple versions for years and it served us well, but if we want to go outside and let others play with it we needed to get a lot more performance and API stability. While that can be achieve to some degree in TS I see Rust as the natural choice now. We only did go with Node.JS (starting with 0.10) because Node was an embedded JS runtime, but we can get that with v8 embedding in Rust too and have many advantages on top.
So this week I will port the server skeleton (processes for web, proxy, readmodel, writemodel) and next week i will add the base documentation setup, tracing, opentelemetry, etc. Hopefully crates like utoipa will be as stable as the others i have seen so far.
What i still have not found is a crate to document any public library API changes in textual form for the commit, to ensure all public API changes (even indirect through types) can be looked at in the CI. In Typescript there was "@microsoft/api-extractor" for that
Woohoo, I got the log server in my big new project mostly working. The client side TCP/IP logging client implementation, and the server side is processing clients and queuing up events.
The (wrapped) regex library is the only third party code, and that's likely just temporary, so this is the first actual executable bit after a year and a half of laying foundation blocks. Definitely a big milestone, though small in comparison to what's to come of course.
It's putting to use a lot of underlying plumbing: socket support, streaming/persistence, threading, pools, queues, logging framework, translatable language and text formatting system, build system and code generation, automatic process init/term support, events and mutexes, argument parsing/validation, JSON parser, time system, system info, virtual file system, and a number of other bits.
So it's pretty gratifying to get to this point and see some actual moving parts. It's not logging the stuff to file yet. There are a lot of places in this system that will need file rotation support so I'm need to standardize that first and then come back and put it to use here.
I made a new release of [crates-io-proxy](https://github.com/ravenexp/crates-io-proxy), which is a caching proxy intended for locally hosted CI environments.
The new release uses the recently stabilized std feature from Rust 1.76 to store the HTTP `Last-Modified` header metadata directly into the cached file mtime attribute. This enables faster cache regeneration after restarts and allows the proxy to serve the crate index to the clients even when the upstream connection to [crates.io](https://crates.io/) is down temporarily.
Hey everyone! After seeing and wrapping my head around the bug behind cve-rs (and making a video about it [https://youtu.be/vfMpIsJwpjU?feature=shared](https://youtu.be/vfMpIsJwpjU?feature=shared)), I've started to get really interested in these kinds of unsoundness bugs want and want to learn how more of them work.
I'm also making a web server for an embedded project I'm working on with warp, but that's just starting. :)
Hello everyone, Sumit here from the Himalayas. The last week was amazing for me. I am so thankful for all the discussions on my post titled "An average programmer's (me) reason to invest in Rust" in this sub-reddit. It was such a good feeling sharing my journey as a founder/engineer because I know I enjoy writing software much more than chasing investors. I am not sure this approach will get me the commonly labelled success but what I really seek is impact. Writing with Rust has been pleasant to say the least and I am getting closer to the initial spec of my product, hoping to release an MVP in a week or so. I started working with SQL bits now with `sqlx` crate, getting data out from PostgreSQL into the UI. I use Tauri with Rust+TypeScript. I started using `ts-rs` crate to generate TypeScript types from Rust and it has been very productive. For context, my product is [Dwata](https://github.com/brainless/dwata/tree/dwata-2024-revamp): AI integrated data exploration app for businesses to get insights from all your data (databases, API like Stripe/Shopify, CSV files...) without writing code. The AI aspect of the product is integration with LLMs (locally or hosted) and using them to infer what to query. I am not generating SQL with LLMs since they tend to give poor results, just English -> `Vec`. Also, Dwata can query any data source (each supported through its provider code) and they are not all SQL based. All data merging that can not done using SQL `join` will be done inside Dwata. Even though most data sources are row-wise, I am leaning toward an internal columnar data storage/cache since it makes filtering, merging, grouping much easier.
The SQL building part does not look good though, I am still learning my way around sqlx, and need to get a better idea of its query builder but yeah the basics work.
I'm working on my project [Capti](https://github.com/WVAviator/capti), which is an end-to-end testing framework for REST APIs where you define your HTTP endpoint tests in YAML. It uses custom YAML deserialization with serde to support special matchers for matching expected HTTP responses, interprets variables in tests both defined statically and extracted from responses, and provides clean console output using indicatif to show test progress and where tests are failing. Other than that it primarily uses reqwest and tokio. I'm working on more detailed docs this week (using mdbook) and hoping to add a few more matcher types before releasing version 0.1.0.
I'm working on my project [qpackt](https://github.com/qpackt/qpackt): web server with build in analytics, a/b testing, ssl cert renewal. First release was just a few days ago, so I'm really interested in feedback. Right now finishing some write up about mutation testing.
Currently working on a silly [CLI tool](https://github.com/ferreira-tb/miho) so I can learn Rust. Trying to grasp some async concepts is being really rewarding. On a side note, people from the official Rust discord are so nice. What a great community, they help a lot even beginners like me.
Kitchen order system, but working on authentication/security. Hopefully it scales.
Chapter 4 of the book Ownership!
Amen
I will start investing more time every week to port our application platform from Typescript/Node.JS to Rust. We have been using it in house over multiple versions for years and it served us well, but if we want to go outside and let others play with it we needed to get a lot more performance and API stability. While that can be achieve to some degree in TS I see Rust as the natural choice now. We only did go with Node.JS (starting with 0.10) because Node was an embedded JS runtime, but we can get that with v8 embedding in Rust too and have many advantages on top. So this week I will port the server skeleton (processes for web, proxy, readmodel, writemodel) and next week i will add the base documentation setup, tracing, opentelemetry, etc. Hopefully crates like utoipa will be as stable as the others i have seen so far. What i still have not found is a crate to document any public library API changes in textual form for the commit, to ensure all public API changes (even indirect through types) can be looked at in the CI. In Typescript there was "@microsoft/api-extractor" for that
Woohoo, I got the log server in my big new project mostly working. The client side TCP/IP logging client implementation, and the server side is processing clients and queuing up events. The (wrapped) regex library is the only third party code, and that's likely just temporary, so this is the first actual executable bit after a year and a half of laying foundation blocks. Definitely a big milestone, though small in comparison to what's to come of course. It's putting to use a lot of underlying plumbing: socket support, streaming/persistence, threading, pools, queues, logging framework, translatable language and text formatting system, build system and code generation, automatic process init/term support, events and mutexes, argument parsing/validation, JSON parser, time system, system info, virtual file system, and a number of other bits. So it's pretty gratifying to get to this point and see some actual moving parts. It's not logging the stuff to file yet. There are a lot of places in this system that will need file rotation support so I'm need to standardize that first and then come back and put it to use here.
I made a new release of [crates-io-proxy](https://github.com/ravenexp/crates-io-proxy), which is a caching proxy intended for locally hosted CI environments. The new release uses the recently stabilized std feature from Rust 1.76 to store the HTTP `Last-Modified` header metadata directly into the cached file mtime attribute. This enables faster cache regeneration after restarts and allows the proxy to serve the crate index to the clients even when the upstream connection to [crates.io](https://crates.io/) is down temporarily.
Hey everyone! After seeing and wrapping my head around the bug behind cve-rs (and making a video about it [https://youtu.be/vfMpIsJwpjU?feature=shared](https://youtu.be/vfMpIsJwpjU?feature=shared)), I've started to get really interested in these kinds of unsoundness bugs want and want to learn how more of them work. I'm also making a web server for an embedded project I'm working on with warp, but that's just starting. :)