6 ms·

I’d be curious to know what the creators of SQLite would have to say about Zig. Zig gives the programmer more control than Rust. I think this is one of the rea

I’d be curious to know what the creators of SQLite would have to say about Zig. Zig gives the programmer more control than Rust. I think this is one of the reasons why TigerBeetle is written in Zig.

Jtsummers 11mo ago
> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages. From section "1.2 Compatibility". How easy is it to embed a library written in Zig in, say, a small embedded system where you may not be using Zig for the rest of the work? Also, since you're the submitter, why did you change the title? It's just "Why is SQLite Coded in C", you added the "and not Rust" part.
- plainOldText 11mo ago
  The article allocates the last section to explaining why Rust is not a good fit (yet) so I wanted the title to cover that part of the conversation since I believe it is meaningful. It illustrates the tradeoffs in software engineering.
  - Jtsummers 11mo ago
    > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. From the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
metaltyphoon 11mo ago
> Zig gives the programmer more control than Rust More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t.
- Cloudef 11mo ago
  I think zig generally composes better than rust. With rust you pretty much have to start over if you want reusable / composable code, that is not use the default std. Rust has small crates for every little thing because it doesn't compose well, as well to improve compile times. libc in the default std also is major L.
  - metaltyphoon 11mo ago
    > I think zig generally composes better than rust. I read your response 3 times and I truly don't know what you mean. Mind explaining with a simple example?
    - Cloudef 11mo ago
      It mainly comes down how the std is designed. Zig has many good building blocks like allocators, and how every function that allocates something takes one. This allows you to reuse the same code for different kind of situations. Hash maps in zig std are another great example, where you can use adapter to completely change how the data is stored and accessed while keeping the same API [1]. For example to have map with limited memory bound that automatically truncates itself, in rust you need to either write completely new data structure for this or rely on someone's crate again (indexmap). Errors in zig compose also better, in rust I find error handling really annoying. Anyhow makes it better for application development but you shouldn't use it if writing libraries. When writing zig I always feel like I can reuse pieces of existing code by combining the building blocks at hand (including freestanding targets!). While in rust I always feel like you need go for the fully tailored solution with its own gotchas, which is ironic considering how many crates there are and how many crates projects depend on vs. typical zig projects that often don't depend on lots of stuff. 1: https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-save-memory-when-doing-a-string-table-3l33 https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-sa...
- array_key_first 11mo ago
  > More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t. I mean yeah, allocations. Allocations are always explicit. Which is not true in C++ or Rust. Personally I don't think it's that big of a deal, but it's a thing and maybe some people care enough.
  - aw1621107 11mo ago
    > Which is not true in [] Rust. ...If you're using the alloc/std crates (which to be fair, is probably the vast majority of Rust devs). libcore and the Rust language itself do not allocate at all, so if you use appropriate crates and/or build on top of libcore yourself you too can have an explicit-allocation Rust (though perhaps not as ergonomic as Zig makes it).
ginko 11mo ago
I'm generally a fan of Zig but it's in no way stable enough to write something like sqlite in it.

Jtsummers 11mo ago

> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages. From section "1.2 Compatibility". How easy is it to embed a library written in Zig in, say, a small embedded system where you may not be using Zig for the rest of the work? Also, since you're the submitter, why did you change the title? It's just "Why is SQLite Coded in C", you added the "and not Rust" part.

plainOldText 11mo ago
The article allocates the last section to explaining why Rust is not a good fit (yet) so I wanted the title to cover that part of the conversation since I believe it is meaningful. It illustrates the tradeoffs in software engineering.
- Jtsummers 11mo ago
  > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. From the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

metaltyphoon 11mo ago

> Zig gives the programmer more control than Rust More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t.

Cloudef 11mo ago
I think zig generally composes better than rust. With rust you pretty much have to start over if you want reusable / composable code, that is not use the default std. Rust has small crates for every little thing because it doesn't compose well, as well to improve compile times. libc in the default std also is major L.
- metaltyphoon 11mo ago
  > I think zig generally composes better than rust. I read your response 3 times and I truly don't know what you mean. Mind explaining with a simple example?
  - Cloudef 11mo ago
    It mainly comes down how the std is designed. Zig has many good building blocks like allocators, and how every function that allocates something takes one. This allows you to reuse the same code for different kind of situations. Hash maps in zig std are another great example, where you can use adapter to completely change how the data is stored and accessed while keeping the same API [1]. For example to have map with limited memory bound that automatically truncates itself, in rust you need to either write completely new data structure for this or rely on someone's crate again (indexmap). Errors in zig compose also better, in rust I find error handling really annoying. Anyhow makes it better for application development but you shouldn't use it if writing libraries. When writing zig I always feel like I can reuse pieces of existing code by combining the building blocks at hand (including freestanding targets!). While in rust I always feel like you need go for the fully tailored solution with its own gotchas, which is ironic considering how many crates there are and how many crates projects depend on vs. typical zig projects that often don't depend on lots of stuff. 1: https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-save-memory-when-doing-a-string-table-3l33 https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-sa...
array_key_first 11mo ago
> More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t. I mean yeah, allocations. Allocations are always explicit. Which is not true in C++ or Rust. Personally I don't think it's that big of a deal, but it's a thing and maybe some people care enough.
- aw1621107 11mo ago
  > Which is not true in [] Rust. ...If you're using the alloc/std crates (which to be fair, is probably the vast majority of Rust devs). libcore and the Rust language itself do not allocate at all, so if you use appropriate crates and/or build on top of libcore yourself you too can have an explicit-allocation Rust (though perhaps not as ergonomic as Zig makes it).

ginko 11mo ago

I'm generally a fan of Zig but it's in no way stable enough to write something like sqlite in it.