Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Built Zig-SQLite

rischmann.fr

Post reply on HN
Print view View original

41–50 of 104 posts

Re: How I Built Zig-SQLite

#41

Post by noodledoodletwo »

ptato wrote: post #37
noodledoodletwo wrote: post #23

Earlier quoted context omitted.

See I got downvoted a bit... Let me rephrase, other modern languages offer something along the lines of these, of the things that aren't there for say rust, close integration with c/c++ is nice. Ie rust has nostd, etc.

out of that list, rust doesn't offer "no macros and no metaprogramming" and "no hidden control flow". maybe these just aren't things you care about?

Yea but for the most part you can avoid macros, and areas where you can't you can consider them to be keywords in my opinion anyways. Macros aren't all bad, but they do get abused a lot and make a nightmare for others. Fwiw Ive only written one macro and it was for learning purposes only.

Re: How I Built Zig-SQLite

#42

Post by noodledoodletwo »

soggybutter wrote: post #29
noodledoodletwo wrote: post #21

Earlier quoted context omitted.

Does a really short summary of this read kind of like, "zig is a modern c, but I like using rust as a modern c++"? Agree, Tokio is a little tricky for people new to rust no doubt, but it's tricky for a reason. It's saving lives in production.

This is actually the frame of reference I've taken to giving most folks. Zig is to C what Rust is to C++ in my mind. Is there a lot of overlap between all 4? Absolutely. But devs still choose C over C++ (and Rust) in some cases, and I think it'll be similar for Zig

Thanks for explaining, I really appreciate it.

Re: How I Built Zig-SQLite

#43

Post by ntoskrnl »

nickysielicki wrote: post #28

constexpr/consteval/comptime/etc is a game changer for the systems programmer and it feels so close but yet so far. Can someone speak to what language has the best support for this? Some things that I feel are missing in C++: * arbitrary file I/O. I can take my compile time data and write a python script to put it in a std::array, but I shouldn’t have to. * non-fixed-sized containers, ie vector * a generic memoizatio…

> Can someone speak to what language has the best support for this?

I can give you the Rust perspective, but I'm not sure it's the best.

> arbitrary file I/O

include_str! and include_bytes! make the contents of a file available as a string or a byte array. More complex types would need a build script (or transmute).

> non-fixed-sized containers, ie vector

No support in `const fn`, but you can again use a build script as an escape hatch.

> a generic memoization utility in the standard library for caching

There's nothing in the stdlib, but there are a few third party crates that give you the easy one-line syntax, such as https://crates.io/crates/memoize

Re: How I Built Zig-SQLite

#44

Post by stonemetal12 »

noodledoodletwo wrote: post #15
pbronez wrote: post #12

Earlier quoted context omitted.

The Zig website [0] has an FAQ for this. I’ll copy in an abridged version here for convenience: ========== Why Zig When There is Already C++, D, and Rust? - No hidden control flow. If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. - No hidden allocations. Zig has a hands-off approach when it comes to heap allocation. There is no new keyword or any other language feature that uses a he…

Yea I feel like most of these differentiators aren't things most people care about barring one. Tight integrations with c/c++ is potentially useful, beyond that I don't really get it. It's kind of like Hare in that regard?

In general those are the reasons I see people give for why they still use C instead of C++ or newer languages. Also all of those things were, and maybe still are necessary for embedded systems where C still dominates.

To me it comes down to Zig is a "modern" C, but unlike most other attempts at replacing C it doesn't skip some of C's use cases.

Re: How I Built Zig-SQLite

#45

Post by hansvm »

noodledoodletwo wrote: post #10

Cool article. I can't figure out why i am supposed to care about zig beyond it's fun? I get that it's interesting and more safe than C (honestly though what the hell isn 't). Say you write rust pretty regularly for new product development, what does zig offer to make my life better, my products more stable, etc?

I write Rust for $day_job and Zig for fun. Rust is great, but if I had to rip on a few places where it's lacking for some applications: Zig maintains a small language footprint, is easier to interop with C, and makes it readily apparent when your code is doing anything non-trivial. To make that concrete:

- The small footprint in Zig enables fast compilation (and getting faster) and fast feedback cycles.

- Arbitrary nastiness can happen using From and other traits in Rust, and the tendency to shadow names and rely on type inference can make that unpleasant to track down. In Zig you'd be forced to make a choice (for any non-trivial type) at the return or call site of how you were going to convert things.

- If you want to use the stdlib and have any non-trivial control over how objects are allocated you're in for a rough time in Rust (say, a circular buffer backing some objects and a reusable arena for others). You'll probably be reinventing a lot of wheels.

- Similarly with issues like implicit locking in stdout. It's executing a syscall per line anyway, but the lock can inadvertently make contended writes 1000x slower, so suddenly logging in multithreaded code needs a dedicated logger, and not any of the common options since those fall back to the locking stdout we're trying to avoid.

Re: How I Built Zig-SQLite

#46

Post by apavlo »

jhgb wrote: post #35

Here's an absolutely crazy idea that I had the other day... Since Zig has comptime, couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries? So far I haven't been able to come up with any counterargument for why this wouldn't work.

> couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries?

SQLite already compiles queries into opcodes and then uses its own VM to interpret them. You would have to reimplement the internal VM.

Re: How I Built Zig-SQLite

#47

Post by skybrian »

curist wrote: post #19

By using comptime, the statement couldn't be runtime composed, right? That's currently the major holdback for me to spend more time on zig: if using comptime become more common in zig community, the libs could be less flexible to use. It feels sort of like function coloring to me, that the whole call chain also need to pass down the value as comptime variable. I've only spend 2 days with zig, so I would love to learn…

Often, comptime code couldn’t be executed at runtime because the language features it accesses aren’t available then. But I agree that if a parameter could go either way, you shouldn’t have to write two versions.

Re: How I Built Zig-SQLite

#48

Post by b3morales »

pbronez wrote: post #12
noodledoodletwo wrote: post #10

Cool article. I can't figure out why i am supposed to care about zig beyond it's fun? I get that it's interesting and more safe than C (honestly though what the hell isn 't). Say you write rust pretty regularly for new product development, what does zig offer to make my life better, my products more stable, etc?

The Zig website [0] has an FAQ for this. I’ll copy in an abridged version here for convenience: ========== Why Zig When There is Already C++, D, and Rust? - No hidden control flow. If Zig code doesn’t look like it’s jumping away to call a function, then it isn’t. - No hidden allocations. Zig has a hands-off approach when it comes to heap allocation. There is no new keyword or any other language feature that uses a he…

> Simplicity. Zig has no macros and no metaprogramming

This one is an odd point; this very article is a demonstration of metaprogramming*:

> Thanks to Zig’s type reflection we can read a row of data into a user-provided type without needing to write any “mapping” function: we know the type we want to read (here the User struct) and can analyse it at compile-time.

* Which is a feature I favor, for the record.

Re: How I Built Zig-SQLite

#49

Post by jhgb »

apavlo wrote: post #46
jhgb wrote: post #35

Here's an absolutely crazy idea that I had the other day... Since Zig has comptime, couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries? So far I haven't been able to come up with any counterargument for why this wouldn't work.

> couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries? SQLite already compiles queries into opcodes and then uses its own VM to interpret them. You would have to reimplement the internal VM.

I'm aware of that, but these elementary operations have some definitions in code. Even just calling them in a fixed sequence (as opposed to dispatching at runtime one opcode at a time) would be something optimizable for a sufficiently smart compiler. However, given a good-enough design of the whole system, straight code generation from the query plan shouldn't be a problem either (and at that point, the Zig compiler should be able to do even more work with the generated query code). I mean, any reimplementation would presumably use Zig features heavily anyway -- otherwise you could just link with the C code.

Re: How I Built Zig-SQLite

#50

Post by pvg »

jhgb wrote: post #35

Here's an absolutely crazy idea that I had the other day... Since Zig has comptime, couldn't a Zig reimplementation of SQLite use comptime for compile-time query compilation? Including generating native code for fixed queries? So far I haven't been able to come up with any counterargument for why this wouldn't work.

The counter-argument is interpreting the query is not what takes up the time in executing a typical RDBMS query. Imagine a db is just a key-value store, the query is some keys and the db just spits out whatever it found in a giant hashtable. That's not going to get faster if you 'compile' the query. It's not going to get much faster if your db is a more realistic three hashtables, two big arrays and a partridge in a b-tree.
Post reply on HN