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

71–80 of 104 posts

Re: How I Built Zig-SQLite

#71

Post by noodledoodletwo »

throwawaymaths wrote: post #64
sryie wrote: post #58

Earlier quoted context omitted.

If zig catches on then the question may change from "why zig" to "do I really need rust?". Rust has a higher entry barrier and is harder to use daily. Is the safety guarantee worth it? In my experience, it is easier to fix a bug than to prove to the rust compiler that there is no bug. I just need a language that finds and reports the bugs (before production). Zig's error handling is interesting in this regard and it…

I think a static borrow checker tool is very likely going to be in the future of zig ecosystem (unlikely to be in the mainline, but that's okay), especially after the intermediate representations stabilize.

I'll believe it when I see it hit 1.0 and has a healthy user base.

Re: How I Built Zig-SQLite

#72

Post by jhgb »

noodledoodletwo wrote: post #69
jhgb wrote: post #56

Earlier quoted context omitted.

Possibly, but then again, if one's aim is to replace C with Zig in the future perhaps completely, because SQLite became de-facto standard file format for many applications (see OGC GeoPackage for example), you might need some implementation of SQLite for that. If a file format is going to stick for decades, you'll definitely get other implementations of that file format sooner or later in environments that can't or d…

What environment cannot run C?

Well, for instance, famously, any multiple-stack machines will have a hard time trying to run C because C assumes a single hardware stack. Although I imagine that currently, in most cases, you'll want to avoid C for software reasons, rather than hardware reasons (for example, you're required to deploy pure Java code, or pure C# code, or want to avoid any unsafe code in Rust, things like that).

Re: How I Built Zig-SQLite

#73

Post by formerly_proven »

b3morales wrote: post #48
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…

> 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.

No metaprogramming as in no separate metalanguage (e.g. templates, macro_rules!)

Re: How I Built Zig-SQLite

#74

Post by cryptonector »

jhgb wrote: post #72
noodledoodletwo wrote: post #69

Earlier quoted context omitted.

What environment cannot run C?

Well, for instance, famously, any multiple-stack machines will have a hard time trying to run C because C assumes a single hardware stack. Although I imagine that currently , in most cases, you'll want to avoid C for software reasons, rather than hardware reasons (for example, you're required to deploy pure Java code, or pure C# code, or want to avoid any unsafe code in Rust, things like that).

> C assumes a single hardware stack

No, it doesn't. C does not even assume a stack. A platform where function call frames are allocated on the heap would not be incompatible with C.

You could say that some C code assumes a stack, but that's pretty exceptional.

> Although I imagine that currently, in most cases, you'll want to avoid C for software reasons,

Yes.

> rather than hardware reasons

Hard to imagine hardware on which C could not run. Maybe a JVM chip, but even then, you could compile C to bytecode.

Re: How I Built Zig-SQLite

#75

Post by cryptonector »

jhgb wrote: post #56
cryptonector wrote: post #51

Earlier quoted context omitted.

You lose at "reimplementation of SQLite".

Possibly, but then again, if one's aim is to replace C with Zig in the future perhaps completely, because SQLite became de-facto standard file format for many applications (see OGC GeoPackage for example), you might need some implementation of SQLite for that. If a file format is going to stick for decades, you'll definitely get other implementations of that file format sooner or later in environments that can't or d…

So, yes, it'd be nice to have an implementation of SQLite3 in some non-C language. However, that's a tall order.

And here you're proposing Zig while someone else will prefer Rust, and someone else Go. So you'll need N>1 rewrites.

This is why SQLite3 is written in C then, because for all the ways in which C sucks, it is the most common (lowest) denominator that ticks the portability checkbox.

Language runtimes that want to not have a C runtime embedded are the hardest hit. The best thing to do for those in the short-term is to talk to a C-coded IPC service that runs the C-coded thing that otherwise can't be run.

Re: How I Built Zig-SQLite

#76

Post by ArtixFox »

throwawaymaths wrote: post #63
ArtixFox wrote: post #40

Earlier quoted context omitted.

...is there any lisp that can be used for systems programming and that does NOT produce huge binaries, does not use GC, generates fast n small binaries and is still interactive? everyone claims lisp can be used for anything, same goes for forths, but i cant see a lisp like that, and about forths...none of the free ones are fast, and the fast ones are still slow on the same note, lets say if someone is creating someth…

I mean there was a "lisp machine" in the distant past that actually ran lisp on metal. Does that count?

obviously no, we dont care about a language that was once used in a machine specifically for it, cuz we cant go in past and program in that specific machine.

i think ive realised what is up with lisps, forths, etc. theoretically you can build all kinds of beautiful abstractions over it and use them for anything

but in reality these languages cant do that and/or their communities dont care to implement it/its not their goal

it might sound bad but it is what it is

if i would have to say it in a worse way, these languages are all talk

Re: How I Built Zig-SQLite

#77

Post by akira2501 »

SkeuomorphicBee wrote: post #20

In case anyone else is unfamiliar with Zig syntax and wondering: in Zig the .{ "somevalue"} represents an anonymous list literal [1], and .{.somename = "somevalue"} is an anonymous struct literal [2]. (A bit off topic rant, but Zig documentation is quite bad, it took me a lot more effort that it should to discover the facts above.) [1] https://ziglang.org/documentation/master/#Anonymous-List-Lit... [2] https://ziglan…

I'm not wild about the new trend of languages of making a bunch of syntax dependent on a single small sigil. It gives me a strong feeling of Perl's historical "eclecticness" and I feel like I'm putting more effort into correctly reading the program back into my mind than I should ideally have to.

Re: How I Built Zig-SQLite

#78

Post by jhgb »

cryptonector wrote: post #74
jhgb wrote: post #72

Earlier quoted context omitted.

Well, for instance, famously, any multiple-stack machines will have a hard time trying to run C because C assumes a single hardware stack. Although I imagine that currently , in most cases, you'll want to avoid C for software reasons, rather than hardware reasons (for example, you're required to deploy pure Java code, or pure C# code, or want to avoid any unsafe code in Rust, things like that).

> C assumes a single hardware stack No, it doesn't. C does not even assume a stack. A platform where function call frames are allocated on the heap would not be incompatible with C. You could say that some C code assumes a stack, but that's pretty exceptional. > Although I imagine that currently, in most cases, you'll want to avoid C for software reasons, Yes. > rather than hardware reasons Hard to imagine hardware o…

> No, it doesn't. C does not even assume a stack. A platform where function call frames are allocated on the heap would not be incompatible with C.

The problem is not with call frames being on the stack or on the heap; even a spaghetti stack would be problematic. One of the problems is that return addresses and data are interleaved in C-style frames, whereas multiple stack machines require them to be separate. It's not that you couldn't write an implementation of C for a stack machine, it's just that it would be probably very primitive and slow. Yes, you can run C at the very least the way it was done on Lisp machines, by allocating a large byte array and treating it as your physical memory, but surely you would want to avoid it if you could. There really is a reason why stack machines historically ran somewhat exotic languages like Forth.

Re: How I Built Zig-SQLite

#79

Post by AndyKelley »

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.

Similar idea: https://andrewkelley.me/post/string-matching-comptime-perfec...

Re: How I Built Zig-SQLite

#80

Post by AndyKelley »

adamdusty wrote: post #65
hansvm wrote: post #45

Earlier quoted context omitted.

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 n…

Rust probably had a fairly small "language footprint" when it was only a few years old with no production use cases as well. I've used both in some small hobby projects. I like writing zig significantly more than rust, but we'll see how long the language remains small and compact.

On the contrary, it had a larger one because it had green threads which require an entire runtime (similar to Go).
Post reply on HN