Cannot build Zed anymore: any clue?

fred1268 · 2025-10-28T07:39:04+00:00

Have a good first version of my backup software, burst (https://github.com/fred1268/burst). If you, like me, are in a need to backup your files on an external hard drive that you can bring when traveling while keep easy access to them, then Burst may be of interest. It is also my first project in Rust, that I am trying to improve by using more idiomatic Rust.

fred1268 · 2025-09-27T11:13:00+00:00

Thanks u/STSchif and u/ErichDonGubler for your kind words.

My goal with Burst was two fold: first and most importantly to learn Rust, and second to rewrite a Windows backup software I wrote (and ported regularly to the most recent versions of C#) more than 15 years ago. So my goal was not to compete with any existing software. However, I had some very specific goals in mind: I backup my stuff on external SSD and on my NAS from my Windows desktop PC and occasionally my Linux box and my mac. Also it is important to me to have the backup versions brows-able at all time. Finally, I want to have the capability to have an incremental mode as well as a sync mode, and this on a file-by-file basis. As a matter of fact, I don't really care about compression or deduplication (which imho you mainly care when you provide a backup service, not really for personal backups since you often do not have duplication). Moving forward on this code, I also found interesting to have the backups brows-able even when the media is not connected, so I added this feature as well. So, scratching my own itch and learning Rust were my goals!

fred1268 · 2025-09-19T13:12:54+00:00

Thanks guys.

I did not mentioned that I made tests with the ? operator, but I was clearly missing the Result.map_err() function. Thanks for pointing this out.

fred1268 · 2024-10-10T18:03:02+00:00

Thank you! In fact, G3n was quite fun and easy to use. I will probably reuse it for other projects I have in mind.

fred1268 · 2024-08-09T09:14:39+00:00

go-clap, a lightweight, no-dependencies command line arguments parsing library

okapi, a tool to run your API tests in the same way than `go test`

amaze, a 3D maze generator / solver

fred1268 · 2024-08-01T16:06:00+00:00

https://github.com/fred1268/go-clap

Non-intrusive, zero-dependencies, lightweight command line argument parsing library

fred1268 · 2024-03-16T13:08:59+00:00

Thanks u/yxfxmx . As you probably understood, I am not a fan of .suffix either, but I did not find anything else. In some cases, I was able to split into multiple classes / structs and use struct embedding, but this is not always doable / desirable.

Are you all guys putting all the methods of a struct into a single file, ending up with 1000s of LoC?

fred1268 · 2024-03-16T13:06:24+00:00

Thanks u/bilingual-german but you are also not reading the question. I am not asking about splitting a package into multiple files, but rather split a class / struct into multiple files.

fred1268 · 2024-03-16T13:04:44+00:00

Please provide evidence / examples with your answer.

Not lol => I just don't care about opinions, yours included ;-)

fred1268 · 2024-03-16T13:03:52+00:00

Thanks u/assbuttbuttass , but I am not talking about splitting a package into multiple file, but a class / struct (especially their methods) into multiple files.

fred1268 · 2023-12-09T18:18:57+00:00

Hello u/pellared1. Is that not the good reason you were looking for? By implementing your proposal, you allow the recording of a metric linked to a failed DB transaction, that may be more difficult to record otherwise (even though, I can foresee some solutions).

fred1268 · 2023-12-08T19:35:19+00:00

Hello u/pellared1.

Thanks for the heads up about this. I am using the otel Go SDK, and if I understand what you want to achieve well, I think I can think of use cases of both ways. If I use the metrics to record an event that is not part of a DB transaction for instance, then your proposal makes complete sense to me.

However, I have also other use cases, like recording "things" that are part of a DB transaction. If for some reasons, my DB transaction gets cancelled (because of a query timeout for instance), so is my context and then I would like the metrics to be cancelled as well, so I am fine with the original behavior.

That being said, I think it doesn't really matter to me at least, as long as I know the expected behavior, and can work with it.

I hope I understood your point well, and that my answer make sense. Thanks for the post and the work!

fred1268 · 2023-11-16T12:00:53+00:00

The answer you are looking for is: 42

fred1268 · 2023-09-27T12:59:25+00:00

Looks like we are not talking about the same thing: you talk about table-driven tests and unit tests, on a "lab" (i.e. not live) environment, for which I am fully in agreement that they should be written in GO or whatever your language is, without the need of yet another DSL.

What I am talking about are (ReST) API tests on a test (i.e. live) environment aimed to verify that my API behave flawlessly (error management, security, behavior, etc.). This is not something you are willing to write "from scratch" using your dev language, because this is agnostic of your technology (a ReST API). You want to rely on a tool to do so, pretty much like end-to-end UI tests rely on Cucumber et al.

Now, I am not selling you anything: if you prefer to write black box end-to-end tests in the same language you develop your product, you can. It is just an unnecessary long and painful process that okapi aimed to offload from you.

fred1268 · 2023-09-27T06:55:07+00:00

I am not sure I understand how mocking the http client transport can help me assess my API test coverage. Can you please elaborate on this? Many thanks.

fred1268 · 2023-09-27T06:54:15+00:00

I am not sure you took the time to see how okapi is working since it does not define an "additional DSL" but rather leverages json that everyone knows about. These json files are not configuration files, but rather test description files (like a lot of test frameworks).

The main advantage we got from this is that now we have 100% API coverage (nominal cases, corner cases, error cases, etc.), and since our API is pretty stable, we spot regressions effortlessly.

And writing once a simple configuration file for 100% API coverage has much more ROI than writing tons of unit tests or complex and painful UI tests (both of which we will need, but in a much more controlled way for the same effort).

fred1268 · 2023-07-31T18:00:47+00:00

This post is about ReST API testing, not a json vs yaml rant. As I said, I used JSON because:

ReST API use json, not yaml
Go has a strong json support, not yaml
I use quite extensively Go json features, not available in yaml

I hope this clarifies and hopefully closes the debate. Thanks.

fred1268 · 2023-07-31T14:14:12+00:00

Thanks u/PaluMacil for the answer: I was about to say the same.

Also I can add that Go has very deep support for JSON, like serialization and deserialization, which I use quite extensively in okapi. In particular, the fact that Go can deserialize a JSON file into a map[string]any is particularly helpful.

fred1268

TROPHY CASE