I see Zig, I vote up ;)
Exciting new language with compelling features!
Great work of the author explaining comptime!
How I Built Zig-SQLite
31–40 of 104 posts
Re: How I Built Zig-SQLite
#32Re: How I Built Zig-SQLite
#33In 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…
Zig is still not 1.0. I can forgive its lack of docs at this point, especially how surprisingly readable the std lib is.
Re: How I Built Zig-SQLite
#34Earlier quoted context omitted.
Yes, but say you are not yet writing Rust, perhaps you should choose Zig instead of it?
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 like "which green thread I'm allocating on") which rust makes extremely difficult.
If you really need memory and resource safety I think the best answer is to be patient. Zig is very easy to parse and I imagine it will be the case that static analysis build tools will come about which can do what you want out of rust.... Being decoupled from the compiler chain you would be able to run fast but guard your prs to main/dev/release (as you see fit) with static analysis tools that will protect you with the safety you seek in an isomorphic fashion to "how rust does it". There's no reason why someone couldn't write it now, but with a lot of things (like ZIR/AIR) being highly unstable -- and these are what you're likely to want to statically analyze for such a tool -- for ones sanity I don't recommend building out a tool like that now.
Re: How I Built Zig-SQLite
#35Here'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.
Re: How I Built Zig-SQLite
#36Earlier quoted context omitted.
As someone who uses both for different personal projects: - I use zig as my build system for both rust, zig, C libraries and linking since the build system works really well for this purpose - When I need to write applications or libraries that can benefit from compile-time code, I always try and use zigs since it's much easier to use comptime then a combination of rust macros and generics - I like the zig async stor…
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.
Yes, but Rust offers something more than just modernizing C++. The borrow checker provides something entirely new that has the potential to make a huge impact.
Re: How I Built Zig-SQLite
#37Earlier quoted context omitted.
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?
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?
Re: How I Built Zig-SQLite
#38constexpr/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…
All of this is already done in Lisp. Greenspun's 10th rule.
Re: How I Built Zig-SQLite
#39I see Zig, I vote up ;) Exciting new language with compelling features! Great work of the author explaining comptime!
[deleted]
Re: How I Built Zig-SQLite
#40constexpr/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…
All of this is already done in Lisp. Greenspun's 10th rule.
...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 something[i am thinking of] like this, what would be a better option, go the forth way or the lisp way cuz both offer same stuff to some extent