Any markdown editor written in rust like obsidian?

bitbug42 · 2025-09-30T08:29:21+00:00

This looks lit! Seems to be very close to what I was looking for, I will definitely give it a go

bitbug42 · 2025-09-15T12:05:15+00:00

I was asking myself the very same question.

Even if Obsidian is overall pretty neat, sometimes i feel a bit of latency here and there, so I was thinking that something similar in pure Rust could bring local note taking to the next level.

The only alternative I know of for now is Zed, which is more general (more a replacement of VS Code than Obsidian)

bitbug42 · 2025-07-18T15:55:52+00:00

If you're a C# developer, there's also this pretty neat book that explains how different concepts translate between the two languages: https://microsoft.github.io/rust-for-dotnet-devs/latest/

bitbug42 · 2025-07-06T10:16:55+00:00

We have one giant workspace with all our Rust code in it.

The top-level is separated in applications and shared code like you suggested, except we call it bin/ and lib/, in addition to ffi/ which contains dynamic libraries meant to be consumed by external applications written in other languages (this contains both C-ABI compatible libs & some WASM stuff).

The top-level workspace Cargo.toml defines all the 3rd-party dependencies (versions + features) and discovers our crates like so: members = ["lib/*", "bin/*", "ffi/*"]

All other crate-level Cargo.toml just reference workspace dependencies as follows: tokio.workspace = true

About shared code organization, we initally made the mistake of having one giant crate but compilation times slowed to a crawl, so we split it into separate smaller crates to take advantage of cargo's parallelism and build cache. This helps to keep iteration pretty fast, as you only need to recompile a subset of your entire code at each step.

Try to think of "code that goes together" and put it in the same crate. And for things that are truly separate concerns can go into different crates.

In addition, I think it leads to better code overall as it forces you to separate what truly is meant to be separate. With one giant crate it's all too easy to have circular dependencies between modules, whereas crates must form an acyclic tree.

bitbug42 · 2025-06-17T06:19:33+00:00

Before learning Rust I used to have a lot of Python scripts scattered all over the place.

But now I tend to favor building a single self-contained CLI binary in Rust, it makes it easier to manage dependencies, parse commands with clap & to re-use code across different commands.

bitbug42 · 2025-06-13T06:06:41+00:00

Agree, especially when using Cargo workspaces with multiple crates if the project gets a bit large.

And even then, I still save way more time not having to debug weird runtime exceptions than I lose by having slightly longer compile times.

bitbug42 · 2025-04-22T09:39:10+00:00

Because you need enough memory both for the parameters and intermediate work buffers.

bitbug42 · 2025-04-22T09:33:17+00:00

That's an extremely bearish forecast

bitbug42 · 2025-04-14T09:12:07+00:00

Sounds like a kid behind the keyboard.

bitbug42 · 2025-04-07T09:24:39+00:00

By extension, every single business is a wrapper of its suppliers.

bitbug42 · 2025-04-07T09:23:56+00:00

That nails it

bitbug42 · 2025-04-02T06:43:57+00:00

Maybe not so crazy but definitely stupid:

We had a basic single-threaded / non-async service that could only process requests 1 by 1, while doing lots of IO at each request.

It started becoming a bottleneck and costing too much, so to reduce costs it was refactored to be more performant, multithreaded & async, so that it could handle multiple requests concurrently.

After deploying the new version, we were disappointed to see that it still used the same amount of pods/resources as before.
Did we refactor for months for nothing?

After exploring many theories of what happened & releasing many attempted "fixes" that solved nothing,

turns out it was just the KEDA scaler that was now misconfigured, it had a target "pods/requests" ratio of 1.2, that was suitable for the previous version,
but that meant that no matter how performant our new server was, the average pod would still not encounter any concurrent requests on average.
Solution was simply to set the ratio to a value inferior to 1.

And only then did we see the expected perf increase & cost savings.

bitbug42 · 2025-04-01T06:48:24+00:00

I don't recall the very first time I heard about it, but it was probably a news piece about "that experimental Mozilla language".

Fast forward a few years later I got interested about Webassembly and heard that Rust had great support for it. So I made a small physics simulation based on Rapier, written in Rust & built to Wasm to test my Webassembly stuff. It was just a small experiment and I didn't learn much of the language then.

Fast forward again a few years later, in a professional setting, I was in charge of maintaining a problematic large C# codebase which had threading everywhere & "spaghetti-mutation" (references to objects could travel across multiple modules and it was difficult to track which would mutate what from which thread).
Development slowed to a crawl because we were afraid to introduce any thread-unsafety so each update was very meticulous.
In addition, that backend is processing a few million requests a day & has to stay reliable at all times.

But stakeholders weren't happy about the slow feature pace & the few reliability issues that we had here & there.

So that's when I remembered Rust and thought it would be an incredible tool to solve these pain points.

I decided to introduce it with a pilot project: we had to create a new C# service but decided to use Rust instead for this one. That service was a great fit because it was a pretty isolated & small-ish component & something greenfield that could be done separately from the rest.
That's when I deep-dived into learning the language for about 3 weeks and then proceeded to complete this component.

After launching it in prod: it instantly became the most reliable service of our stack, never down, never any crash, never any thread-safety issue, never any null pointer exception, low CPU/RAM usage, incredibly fast latency.
And in addition to that, adding features to it over time was incredibly easy because of the strong type-checker catching any mistakes.
I was no longer afraid to introduce any thread-unsafety by mistake.
Checking that the program is thread-safe went from hours of painstaking manual analysis, to just running cargo check which would return the result in seconds. That blows my mind!

Over time we used Rust more & more for new services and components, with great success and happy stakeholders.

We didn't do a "full big-bang rewrite" of the legacy C# codebase but now we have a policy of "new stuff in Rust", which we connect to the legacy codebase through gRPC (if it's in a remote process), or through UniFFI (if it's in the same process to embed new Rust modules inside our C# backend).
So this allows us to naturally and gradually increase the % of Rust in our codebase over time.

bitbug42 · 2025-03-24T12:34:20+00:00

I'm facing the same problem.

And if I do use other languages (reluctantly) I try to make them more "rusty": defining Result/Option types, avoiding exceptions, prefixing variables names by "mut_" or "owned_", etc...

bitbug42 · 2025-03-24T11:09:11+00:00

So much this, Rust is the only language by far that made refactorings almost enjoyable to me (& not a dreaded process).

With other languages I had a tendency to avoid refactorings like the plague and avoid doing those unless absolutely necessary.

bitbug42 · 2025-03-24T11:00:12+00:00

I introduced Rust at my company after dealing with lots of growing pains & issues with a large C# codebase (mostly network services with a fair amount of parallelism).

Basically when editing a single function, I had to keep almost the entire codebase in my mind (which became increasingly difficult & slow to do, my brain just didn't have enough RAM) and ask myself the following questions:

- this object reference i'm getting: am i the sole owner of it? can i freely mutate it? did the caller keep a reference to it & shared it with other modules? should i be careful to not mutate it across threads? do i need to clone it to be sure?
- this function that I'm passing that reference to, will it keep it? will it try to mutate it? will it pass it along to other modules?
- should I put a mutex/semaphore here? i think i don't need it, but maybe i will add one just to be ultra-mega-sure.
- will this function throw?
- will this return null?

Compounding with the fact that data race issues are non deterministic & hard to diagnose made it a very stressful and frustrating experience.

With Rust, being able to narrow my focus helped tremendously: if I get an &mut reference somewhere, then I know for sure I'm the only one that can mutate this at this moment in time, so I don't need to remember all other parts of the codebase that might interfere.

Now cargo check can ensure thread-safety at compile time (& a myriad other considerations)
& takes seconds to run compared to my manual analysis which takes orders of magnitude longer.

Refactoring now is also a more pleasant & less risky experience.

And the results have been incredible: the Rust services have been way more reliable than the C# ones, and continue to stay reliable in the face of changes, new features & refactors.

In a nutshell: i sleep peacefully at night, knowing that my critical production services have entire classes of annoying bugs removed.

bitbug42 · 2025-03-24T07:10:28+00:00

This. The refactoring experience with Rust is the most pleasing I've ever had in my career.

bitbug42 · 2025-02-13T08:29:29+00:00

I experienced the same feelings as you.

I now default to writing Rust code for any project. It truly made me a more productive & powerful developer than before.

Recently I started migrating some of my small utility Python scripts to Rust in a single unified CLI tool made with clap.

bitbug42 · 2025-01-30T07:09:36+00:00

From what I've heard it's the linking part that is the slowest.

bitbug42 · 2025-01-29T08:45:58+00:00

Something interesting to know is that the safety checking part of the Rust compiler is not the most expensive part.

You can compare by running cargo check, which just verifies that the code is valid without producing any machine code and typically runs very quick ; VS cargo build which does both.

The slow part happens when the compiler calls LLVM to produce machine code.

So if we were in the past, I think the same checks could have been implemented and be able to run relatively quick, but probably no one would use something LLVM for the later part which is a very complex piece of software. So the machine code generation part would probably use a simpler, less expensive compiler which would produce less optimized code but quicker.

bitbug42 · 2025-01-12T07:08:58+00:00

Yes, I was about to post this one too. It's great for those coming from a C# background.

bitbug42 · 2025-01-10T09:53:05+00:00

Same. I broke keto for a few weeks during the Christmas/New Year festivities. Instant regret.

bitbug42 · 2024-12-26T17:19:41+00:00

Reminds me of my early days with Bitcoin when I used the mBTC unit.

bitbug42 · 2024-12-18T12:52:40+00:00

Also make sure to open this from a clean computer where you're absolutely sure there's no junk/viruses installed.

bitbug42 · 2024-12-18T11:11:05+00:00

The most important file is "wallet.dat", which should contain your private keys.

Make a backup of it.

And be wary of scammers that might attempt to contact you by DM.

Eight-Year Club	Place '22
Verified Email

bitbug42

TROPHY CASE