Ichorio has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
<mikdusan>
stratact: i think those are out of stock for a while now
<stratact>
My point wasn't so much the availability (although they claim they will ship more on Nov 15), as it was the cost of owning one because they are so expensive, unless money wasn't a concern.
dimenus has quit [Read error: Connection reset by peer]
<stratact>
If it were me, I would wait for RISC-V boards to become more popular and cheaper over time
_whitelogger has joined #zig
chemist69 has quit [Ping timeout: 245 seconds]
chemist69 has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
_whitelogger has joined #zig
_whitelogger has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 240 seconds]
return0e has quit [Ping timeout: 265 seconds]
<stratact>
Is there a way to generate a range, say 0 up to 10 for for-looping? I understand that for-loops are for iterating elements of an array, but is there a way to generate one that holds elements in an iterative range?
<drasko>
Hi all, I am new to Zig and I was wondering how you would compare Rust memory security guarantees to Zig ones? I have been trying to find texts that target this question, but I have not found many.
<drasko>
In general - what would be the best advantages of Zig vs Rust - except the faster compilation times?
<drasko>
And also - what are the things that Rust is doing better, and how would Zig address those?
<companion_cube>
rust is doing better at static memory safety, and being >1.0
<companion_cube>
but zig is simpler, more lightweight, and tries to compete with C (rust is more of a C++ contender)
<drasko>
Does it make sense for Zig to tries to address these Rust advantages as well adn then practically eliminate Rust as a competitor, or it is not worh of having this level of static memory safety?
<mq32>
drasko: i'm doing the kind of "debug software in-production" style working
<mq32>
because it fits my environment better
<mq32>
so i save time in the end to fix bugs only when they actually happen and cannot be fixed by "restart the program"
<drasko>
You can not debug in production mission critical stuff
Aransentin has joined #zig
<mq32>
i can and i'm doing it. it saves a lot of time actually
<drasko>
Looks like Erlang would be a better fit for you then, mybe
<drasko>
it would restart processes for you if they crash
slice has joined #zig
<mq32>
nah, that's not good either ;)
<mq32>
if i want that, i would do that
<mq32>
also erlang is functional which makes programming sequences incredibly hard :D
<drasko>
How about thread safety?
<mq32>
in zig? you have to ensure you're not doing stupid stuff
<mq32>
so afaik there is none except the usual stuff (mutex, atomics)
<companion_cube>
so far Zig has been focusing more on async, I think
<companion_cube>
(tbh with generics you can already improve on some things, like having a BlockingQueue(T) instead of reimplementing it every time)
<mq32>
companion_cube: async and thread safety are two completly distinct things
<companion_cube>
yes
<companion_cube>
(but rust picked threads first, to get basic concurrency; Zig picked async first)
<mq32>
afaik zig already supports threads
<companion_cube>
rust is only now getting to terms with async
<drasko>
mq32 I find Goroutines rather simple as a concept
<companion_cube>
yeah but even stuff like the package manager is "waiting for async"…
<drasko>
much simpler than async/await
<fengb>
Well Zig picked the wrong async and had to redo it :P
<mq32>
drasko: they imply a lot of stuff to know. like compiler inserting stuff you don't see
<companion_cube>
drasko: there's a non trivial scheduler underneath though
<mq32>
drasko: i think you're messing up simple and easy
<mq32>
easy is "i don't have to type that much"
<drasko>
Yes, I mean easy to use
<fengb>
Go scheduler isn’t too complex. Zig’s event loop would probably just as complex
<mq32>
and simple is "i don't have to know that much"
<mq32>
(at least in my understanding, maybe some native speaker may clarify the correct use *grin*)
<fengb>
People use “simple” to mean a number of different things
<fengb>
The worst part about Hickey’s talk is that “not simple” is the scapegoat of not making things easy
<mq32>
i don't know what talk you're talking about
<drasko>
In any case, I personally gind goroutines and channels easy to understand and work with
<drasko>
also, I personally fing Erlang actors and message passing easy to work with
<drasko>
I have more mental trouble following Node's or Tornado's async loop
<drasko>
I always have to take care of what might block the loop
<mq32>
i'm not a huge fan of pure functional programming (so no haskell or erlang for me)
<mq32>
drasko: same for zig's async/await feature. it's not inherently concurrent
<drasko>
Yes, this is what I understood
<fengb>
Node is semi-easy: nothing blocks
<drasko>
yes, but I find this paradigm hard to follow
<earnestly>
mq32: erlang isn't pure fp
<fengb>
The syntax for node’s async is pretty bad though
<drasko>
In any case - thanks for clarifications. There are a lot of thins that I saw in Zig that I like. I would just ike to understand more about the safety compromises in comparison with Rust - because I think Rust is prectically the main competitor of Zig today.
<mq32>
drasko, i don't think zig and rust target the same group of developers
<earnestly>
("pure" and "functional" is redundant, but that terminology lost its meaning long ago as people forgot what "proceedural" meant)
<fengb>
I don’t see rust as too much of a competitor. For the dev that needs 100% safety, Rust is great. For dumb guys like me, Zig is understandable
<companion_cube>
also watch for the other new LLVM langs, like nim or crystal ;)
<companion_cube>
(less control, but easier to use, I think)
<fengb>
They’re both better embedded languages than C but that’s really where the commonality lies
<mq32>
earnestly, yeah i just looked at some examples of erlang and it looked pretty functional to me :D
<companion_cube>
it's purely functional except that you can send messages ;)
<companion_cube>
(which is quite a side effect)
<earnestly>
mq32: People will understand you I guess, but truthfully, if it's not pure, it's not functional
<companion_cube>
so the only functional language is haskell?
<earnestly>
companion_cube: And joy
<earnestly>
The rest are essentially procedural, although you can implement functions in those languages too
<earnestly>
companion_cube: It may seem extreme, but proceedural is lovely too :(
<mq32>
fengb, i don't think Rust is an exceptionally good language for embedded development (although some fanboys tried to convince me otherwise)
<fengb>
I’m trying to be fair :P
<mq32>
:D
<companion_cube>
earnestly: we're off topic, but there's a reason "functional" and "purely functional" are not the same term ;)
<earnestly>
It's okay though, the language as simply changed, it's become vague. People will know what you mean, so it's not a problem
<mq32>
the argument was like "yeah you have to write a hardware abstraction layer with like 98% unsafe code and then you can optimize that layer away again..."
return0e has quit [Read error: Connection reset by peer]
<earnestly>
companion_cube: In the same way a C function is not a function, it's just age old mislabeling of things
<companion_cube>
(technically haskell has exceptions, also…)
kristoff_it has joined #zig
<companion_cube>
yeah but then you only have idris/coq/agda, not haskell
return0e has joined #zig
<mq32>
earnestly: BASIC has real functions :D
<companion_cube>
haskell only has partial functions
<earnestly>
companion_cube: It's also not so cut and dry because languages can mix the approaches
kristoff_it has quit [Ping timeout: 265 seconds]
<Aransentin>
Porting the netlink.h header to Zig. It as an enum where multiple tags have the same value, but that's not allowed in Zig. :(
<Aransentin>
Guess I have to put some values as an independent const just after to the enum... Still, ugly.