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

91–100 of 104 posts

Re: How I Built Zig-SQLite

#91

Post by metadat »

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…

Is `.{"somevalue"}` a string array of length 1?

The dot seems quite superfluous and quite the silly quirk (in an unintuitive way). How do Python and Go get by without such a mystery sigil?

Re: How I Built Zig-SQLite

#92

Post by throwawaymaths »

metadat wrote: post #91
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…

Is `.{"somevalue"}` a string array of length 1? The dot seems quite superfluous and quite the silly quirk (in an unintuitive way). How do Python and Go get by without such a mystery sigil?

It's a tuple of length one with an array of u8. A tuple is an anonymous struct with special fields that are numerical, note that also tuples can be accessed by index syntax. Some distinction from empty braces is necessary because "naked" empty braces are for code blocks. It's only unintuitive to you because it's different and you're not used to it yet.

Re: How I Built Zig-SQLite

#93

Post by throwawaymaths »

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 think it allows the parser to be context-free since otherwise it is tricky to distinguish it from a code block. They could have picked a different sigil, but I think . was landed on because it had the fewest semantic conflicts with other concepts in the language (for example % is used to denote modular arithmetic)

Re: How I Built Zig-SQLite

#94

Post by avgcorrection »

formerly_proven wrote: post #73
b3morales wrote: post #48

Earlier quoted context omitted.

> 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!)

Homogeneous metaprogramming is a thing...

Re: How I Built Zig-SQLite

#95

Post by bo0O0od »

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?

In zig code blocks are expressions and can appear in a lot of places, e.g. on the RHS of an assignment. Probably possible to not need the dot but considerably more complicated.

Re: How I Built Zig-SQLite

#96

Post by mcronce »

sryie wrote: post #82
noodledoodletwo wrote: post #70

Earlier quoted context omitted.

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

> rust also incurs a non-negligible ongoing productivity cost for its complexity

This isn't really consistent with my experience. Compared to writing other languages with varying levels of strictness (C, Python, Go to name a few), Rust's compiler saves me a lot of time writing tests and finding bugs.

It doesn't save me the work of fixing them, but in my experience, bugs that are hard to find and easy to fix drastically outnumber bugs that are easy to find and hard to fix.

That said, I haven't tried Zig. It's on my radar, but just haven't had a new project to start lately.

Re: How I Built Zig-SQLite

#97

Post by cryptonector »

jhgb wrote: post #89
cryptonector wrote: post #87

Earlier quoted context omitted.

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?

If it's addressable memory, you can address it. That does not assume a stack however. You don't get to assume that they are in some order, not if you want your code to be portable. On typical architectures that do use a stack, if you're very careful, you do get to use the addresses of automatics to figure out whether the stack grows up or down, but that's not specifically something in standard C.

Re: How I Built Zig-SQLite

#98

Post by motiejus »

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.

I first tried rust in 2015[1]. It was my first serious attempt at rust.

The language was not small whatsoever at the time. It was not fun.

[1]: https://github.com/motiejus/makelua/tree/rust

Re: How I Built Zig-SQLite

#99

Post by sryie »

mcronce wrote: post #96
sryie wrote: post #82

Earlier quoted context omitted.

"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 in…

> rust also incurs a non-negligible ongoing productivity cost for its complexity This isn't really consistent with my experience. Compared to writing other languages with varying levels of strictness (C, Python, Go to name a few), Rust's compiler saves me a lot of time writing tests and finding bugs. It doesn't save me the work of fixing them, but in my experience, bugs that are hard to find and easy to fix drastical…

I am surprised that you don't encounter a productivity cost in rust vs languages with a gc (like python and go). If that were typical then I assume everyone would be using it. What do you consider to be the tradeoffs between rust and other languages? What are its drawbacks in your experience? How much rust experience do you have compared to other languages?

Re: How I Built Zig-SQLite

#100

Post by noodledoodletwo »

throwawaymaths wrote: post #34
noodledoodletwo wrote: post #18

Earlier quoted context omitted.

I see where you are coming from, zig is easier to learn, but zig doesn't offer what rust does with respect to safety. That feature is so hard for me to ignore. I respect it though, some people want to be up and running with a new technology in a day or whatever, rust doesn't give you that unless you are very seasoned.

Honestly many applications don't need the level of safety that rust provides (for small single threaded cli apps or cloud lambdas, just allocate into an arena and throw everything away when the program quits, no UAF or DF because you're never freeing ) At the other extreme, if you're writing an operating system or a language VM, you probably want contextual allocators (like an allocator that takes a runtime argument…

I actually disagree with that and think it encourages bad practices in people who don't know better. The rise of fuzz testing on these old c applications following this kind of mentality is a constant source of cves . Why expose users to problems, if it's easy not too?

Also it's not like that safety costs much of anything. You really can get comfortable writing rust, especially "easy rust" like a single thread cli app. It really is easy, even convenient.

Either zig is a different tool to rust, in which case I get it. Or people should be waiting for zig to be mature, meanwhile rust has been stable for half a decade, and at this point "just works". I'm not going to sit through an addendum static analyzer and all the bugs that come with making one for a few years. Other people whose appetite for risk is higher will though, and I wish them the best. I've seen efforts in other languages, my conclusion is that it's much better to have it built in...

Post reply on HN