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

81–90 of 104 posts

Re: How I Built Zig-SQLite

#81

Post by jdrek1 »

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…

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

There's a proposal for that https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1040r6...

> non-fixed-sized containers, ie vector

You can already use them in a constexpr context, you just can't leave it yet. So creating a vector on compile time and then using it on runtime is sadly not working right now but I think that's being worked on as well.

Re: How I Built Zig-SQLite

#82

Post by sryie »

noodledoodletwo wrote: post #70
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…

It's really not that hard to use once you invest some time into it. I know where you are coming from, but appeasing the compiler actually means "I am writing safe code". Rather then "it compiled let's see what happens in production"

"some time" is the entry barrier I was referring to and increases the cost of onboarding and adoption. However, rust also incurs a non-negligible ongoing productivity cost for its complexity.

Rust can provide some guarantees but it still won't protect you from logic errors or a "clever" coworker. In comparison, zig is simple and at the end of the day readability is my best defense against bugs/errors.

There was an interesting comparison (and discussion) of zig vs rust safety a few months ago: https://news.ycombinator.com/item?id=26537693

I find myself agreeing with pron and others in that discussion when they say no one really wants to use a safe language. What they want are correct programs.

What remains to be seen is how easy it is to write correct programs in each and the values people place on the deltas between the two languages.

Re: How I Built Zig-SQLite

#83

Post by kzrdude »

akira2501 wrote: post #77
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.

I'm wondering what the point of the period is here, could it be done without it?

Re: How I Built Zig-SQLite

#84

Post by alpaca128 »

kzrdude wrote: post #83
akira2501 wrote: post #77

Earlier quoted context omitted.

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.

I'm wondering what the point of the period is here, could it be done without it?

I don't know why, but this is a part of the language's syntax, for example when matching a union type each named variant also has that period. Same with the argument for print statements (`print("{s}", .{var})`).

Re: How I Built Zig-SQLite

#85

Post by kzrdude »

alpaca128 wrote: post #84
kzrdude wrote: post #83

Earlier quoted context omitted.

I'm wondering what the point of the period is here, could it be done without it?

I don't know why, but this is a part of the language's syntax, for example when matching a union type each named variant also has that period. Same with the argument for print statements (`print("{s}", .{var})`).

aha, seems like they use the list argument to print instead of having varargs functions then?

Re: How I Built Zig-SQLite

#86

Post by jhgb »

cryptonector wrote: post #75
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…

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

> because for all the ways in which C sucks, it is the most common (lowest) denominator that ticks the portability checkbox.

This is actually something that Zig is supposed to do as well. There should be nothing that you can do in C but can't do in Zig. So hypothetically, in the future (say, twenty years from now), a Zig implementation of SQLite could be a preferred one since you're not losing anything with it. (With the additional benefit that should you want to, you might be able to compile application-specific queries into it.)

Re: How I Built Zig-SQLite

#87

Post by cryptonector »

jhgb wrote: post #78
cryptonector wrote: post #74

Earlier quoted context omitted.

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

No, really, the C language makes no assumptions about this.

Re: How I Built Zig-SQLite

#88

Post by Const-me »

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?

GPUs are weird.

HLSL and CUDA have C-like syntax, but underneath the syntax these things are very different from C.

On GPU almost nothing has an address, there's no stack, no malloc/free, no files or printf, and every instruction runs on 32+ threads in lockstep.

Re: How I Built Zig-SQLite

#89

Post by jhgb »

cryptonector wrote: post #87
jhgb wrote: post #78

Earlier quoted context omitted.

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

No, really, the C language makes no assumptions about this.

You can't take an address of pretty much any input parameter, return value, or local variable of a function on a stack machine because they're all on the stack CPU core's hardware data stack which has no addresses for its elements. In C you should be able to take the address of these objects, using an ampersand. That's not making an assumption?

Re: How I Built Zig-SQLite

#90

Post by ranfdev »

gpderetta wrote: post #5
Tiberium wrote: post #4

Earlier quoted context omitted.

I think the only real way you can run make a language server understand comptime code is using the compiler as a library, similar to how Nim does it - nimsuggest (the tool for autocompletion, definitions, etc) is basically the compiler itself with some nimsuggest-specific stuff, so it understand macros, templates, compile time code evaluation, etc.

Isn't that's how most LSP servers are implemented? I'm only vaguely familiar with clangd.

Yes. An LSP has to work along with the compiler, or it has to become an alternative compiler.

For example, from the article "Why LSP?" [1]

"It is known that compilers are complicated, and a language server is a compiler and then some."

[1]: https://matklad.github.io//2022/04/25/why-lsp.html

Post reply on HN