<emekankurumeh[m]>
it's gonna be a while before I can test it on my setup, but I'll submit a pr if I find any regressions
<andrewrk>
thanks!
<hryx>
andrewrk: regarding #2897 (de-keywordizing primitive values): Removing the grammar keywords led to removing the special AST node types, which affects ir.cpp. I find myself adding a new primitive_value_table in the CodeGen, similar to primitive_type_table. Does that sound like the right direction?
<andrewrk>
hryx, I think primitive_type_table can be renamed to primitive_value_table and handle both cases
<andrewrk>
since types are values
<hryx>
rad idea, will do
rsdimenus has quit [Read error: Connection reset by peer]
<scientes>
hryx, also, it would be rad if all attributes were just annonmous enums
<scientes>
instead of keywords
<Tetralux>
Attributes?
<scientes>
well we don't have real attributes like C yet
<strmpnk>
Reminds me of true/false in Erlang. They're just atoms and dialyzer (the optional type system) treats booleans as the union of the two atoms.
<strmpnk>
Or "polymorphic variants" is OCaml.
<scientes>
but like comptime
<scientes>
would become .Comptime
<scientes>
.Inline
<Tetralux>
You mean like `fn f() .Inline i32 { return 42; }` ?
<strmpnk>
scientes: The question of that becomes, what can the user of the language do with open enumeration?
<strmpnk>
Seems more like overloading syntax (context overloads). I'd find that hard to follow.
<Tetralux>
Are these attached to a declaration or fn to modify their behavoir in some way?
<Tetralux>
In the src code.
<scientes>
same for variable, like align, pointer-namespaces, et cetera
<scientes>
anyways, just an idea
<andrewrk>
hmm no it can't be a calling convention, that won't be compatible with external APIs
SimonNa has quit [Remote host closed the connection]
<andrewrk>
well, maybe
<strmpnk>
scientes: I don't hate the idea. I am mostly musing about the benefit of generalizing a notation.
<strmpnk>
inline seems to be more parallel with comptime than it is with calling conventions.
<scientes>
andrewrk, perhaps LTO can have inline attribute ?
<strmpnk>
The transformation is done by the compiler.
<scientes>
strmpnk, but also by llvm
<scientes>
comptime is zig-only
SimonNa has joined #zig
<strmpnk>
scientes: I'm pretending LLVM is part of the compiler. Not sure if there is a specific boundary to that term here.
<scientes>
Anyways, at some point zig will probably want something as flexible as gcc's attributes, and I was pleased with this syntax because it is consistant and very short
<scientes>
so sure how to make it take data however
<scientes>
like .Align(8)
<strmpnk>
While they are heavier syntactically, I like the annotations I see in C#/F#. The benefit of having annotations that can be reflected upon (comptime here of course) seems useful. (but perhaps it's just another way to hide parameters to a comptime function call, ¯\_(ツ)_/¯).
<companion_cube>
what do you think of rust's attributes?
<strmpnk>
They remind me a lot of what I did with F# at past jobs but in a much more complicated interaction with macros and compiler built-ins.
<strmpnk>
I do like that one attribute cannot imply another. It's just data, not a transitive closure. It helps keep some amount of sanity interpreting annotations.
ltriant has quit [Ping timeout: 245 seconds]
<scientes>
has anyone else had a crash that only occurs when not running under the debugger (same binary)?
<scientes>
damn heisenbugs
<Tetralux>
Probably unit memory XD
<Tetralux>
uninit*
ltriant has joined #zig
<Tetralux>
Dammit can't get even my quip right xP
<scientes>
its a floating point exception in the caching code
<daurnimator>
andrewrk: did you get directory iteration in windows figured out?
<andrewrk>
daurnimator, that's been working fine for a while. it uses FindFirstFile, FindNextFile
<daurnimator>
andrewrk: I meant your experiments with NtQueryInformationFile
<daurnimator>
which I apparently confused with NtQueryDirectoryFile
<andrewrk>
I found that by looking at ReactOS source
<daurnimator>
andrewrk: should put a comment in the zig code saying as such...
<andrewrk>
normally I would use translate-c to find the values for the definitions but the relevant header files appeared to not be available without installing some separate thing
<Tetralux>
You had an off-by-one in an enum? That's a curiousity.
<andrewrk>
I mean it was documented incorrectly
<andrewrk>
so anyway, now `make install` doesn't print a jillion redundant lines and manually adding new files to CMakeLists.txt is no longer required for the standard library
<andrewrk>
and `make` now takes about half as long as it used to to notice that no file copying must be done
<andrewrk>
a small bit of the build just became self hosted
<hryx>
sooooo nice
<daurnimator>
andrewrk: I thought you were working on #2888 :)
<andrewrk>
daurnimator, oh! I see why you thought that now. That was just a coincidence, I didn't realize the function you found was the same one I just took advantage of
<andrewrk>
so I learned how to use Process Monitor, which is an amazing tool
<andrewrk>
all the sudden I feel like I can understand wtf my windows programs are doing and troubleshoot the performance
<daurnimator>
andrewrk: do zig stack traces show up correctly?
<andrewrk>
and I was trying to figure out why copying files was so slow. at first I thought it was inefficiency in GetFileInformationByHandle since the procmon stack trace showed that was simply delegating to NtQueryInformationFile. so I eliminated the middle man
<andrewrk>
but then realized it was not the syscall but the unicode conversion that was slow
<andrewrk>
that reminds me though, I'm going to open an issue which is to propose that the zig standard library migrate towards using NtDll as the only API
<andrewrk>
figuring out how to do that is straightforward with procmon
<andrewrk>
since the stack trace feature tells you the actual low level APIs that you're calling
<daurnimator>
you can't use it as the only API unfortunatly
<andrewrk>
why's that?
<daurnimator>
Some GDI functionality adds hooks into the kernel32 layer
<daurnimator>
and if you bypass it sometimes graphic applications stop working.
<andrewrk>
you're talking about gd32.dll functions?
<andrewrk>
what functions are dangerous to bypass?
<daurnimator>
that's a good question for midipix
<daurnimator>
but it's only relatively specialized ones
<daurnimator>
e.g. fork
<daurnimator>
(yes! windows has a fork syscall....)
<Tetralux>
WAIT
<Tetralux>
WINDOWS HAS FORK
<Tetralux>
WHAT SORCERY IS THIS
<daurnimator>
Tetralux: yep. but if you use it you can't use any graphics APIs. and input processing gets really hard
<daurnimator>
as such, microsoft choose not to document it
<Tetralux>
That's sounds about right for a user-facing API.
<Tetralux>
OH!
<Tetralux>
Even better!
<daurnimator>
hence why no one really knows about it
rakkom has joined #zig
_whitelogger has joined #zig
rsdimenus has joined #zig
rsdimenus has quit [Remote host closed the connection]
fengb has joined #zig
<fengb>
andrewrk: I noticed Windows libc includes all the h files. Does that mean the Mac version can include everything too?
<andrewrk>
fengb, you're asking about shipping .h files for macos libc?
marijnfs has quit [Ping timeout: 264 seconds]
<fengb>
Yeah
marijnfs has joined #zig
<andrewrk>
I need to double check the license information
<fengb>
They're mostly Apple licence or BSD
<andrewrk>
the windows.h files we ship are all public domain (or similar) licensed, which is one of the main goals behind the mingw-w64 project
<andrewrk>
but yeah if they're compatibly licensed, and it adds a reasonable amount of file size, then we can ship those too
<fengb>
It's just a lot so I'm not sure how much time it'd take for me to prune it down
<andrewrk>
there's likely a project that has done this work already - the mingw-w64 equivalent for macos
<fengb>
Bleh you're right. There's a bunch of private files
<andrewrk>
darwin frameworks are another problem to solve
<andrewrk>
I'll probably save macos for last and solve freebsd first
<andrewrk>
hryx, I have tests running on all platforms for your translate-c PR...
<emekankurumeh[m]>
so will we be writing our own AFD driver like daurnimator was talking about a while ago?
<andrewrk>
what's AFD?
<daurnimator>
emekankurumeh[m]: huh? no you *use* the AFD driver
<emekankurumeh[m]>
I mean write our own abstractions over the AFD driver, communicating with it directly like node does
<daurnimator>
andrewrk: AFD is the piece of windows that handles TCP and UDP
<andrewrk>
hryx, sorry that took so long, but it's in master now :)
<fengb>
:o
<andrewrk>
zig has 5,555 commits
<companion_cube>
🎉
ntgg has joined #zig
<andrewrk>
emekankurumeh[m], possibly. I'm not well informed on the topic yet
darithorn has quit [Quit: Leaving]
<diltsman>
Does Zig have well defined sequencing?
<diltsman>
Or, I guess, is it well defined enough that you can write a double checked lock that the optimizer can't break?
<andrewrk>
you can use @fence and the other atomic builtins
ntgg has quit [Ping timeout: 268 seconds]
<hspak>
is there any way to do something like the following with when <some_u8> is only available at runtime? const a = switch(some_u8) { 0 => blk: { warn("stuff"); break :blk 0; }, ...
<hspak>
the code fails with "error: cannot store runtime value in type 'comptime_int'"
<andrewrk>
hspak, yes, cast your 0 to a type
<hspak>
andrewrk: that worked, thanks!
ltriant has quit [Ping timeout: 258 seconds]
<diltsman>
andrewrk: Does @fence produce code in the binary?
<andrewrk>
on some combinations of architectures and AtomicOrder it does. but mainly it limits what the optimizer can do
ltriant has joined #zig
fengb has quit [Ping timeout: 260 seconds]
rakkom has quit [Quit: Leaving]
brakmic has joined #zig
brakmic_ has joined #zig
brakmic__ has joined #zig
<hryx>
andrewrk: awesome! thanks so much for figuring that out — glad to have it solved
<hryx>
also 5555 hail satan
brakmic has quit [Ping timeout: 245 seconds]
brakmic_ has quit [Ping timeout: 245 seconds]
karrick_ has joined #zig
karrick_ has quit [Read error: Connection reset by peer]
<shachaf>
I suspect making a completely explicit reified frame like that isn't the compiler's job.
<shachaf>
I mean, one that can be sent over the network or whatever. It would be interesting to see something like that, though.
<shachaf>
Mostly I think it being about as opaque as a stack frame is fine?
<shachaf>
One thing that would be interesting would be having "stack variables" that are explicitly marked as externally accessible on the frame.
<daurnimator>
shachaf: I think a concept at the moment is a `@Frame(myfunction)` builtin
<shachaf>
Sure, but presumably it's opaque.
<daurnimator>
ehhhh; I don't see why you'd need to
<shachaf>
I'm imagining something like "coroutine fn foo() void { coroutine_exported_var i = 0; ... }" such that if f has type @Frame(foo), you can refer to f.i
<daurnimator>
shachaf: if it wasn't opaque then you'd be able to do some really cool introspection. useful for not only debugging but even serialising.
<shachaf>
Sure, but there are all sorts of tricky things to figure out.
<shachaf>
Presumably you can do liveness analysis on your coroutine frame, so that different variables can occupy the same frame memory at different points.
brakmic__ has quit []
<daurnimator>
shachaf: yeah I guess. could have it as a union of different states?
brakmic has joined #zig
<shachaf>
Right, you can imagine it as a tagged union.
<daurnimator>
for now I'm just waiting to see what andrewrk comes up with
<shachaf>
But often you switch just the tag and keep the rest of the memory the same, which isn't a common use of tagged unions at least?
<daurnimator>
easier to suggest actual changes than theorize
<shachaf>
Also, if you're not reifying it, you can store an instruction pointer directly rather than an enum value.
<daurnimator>
shachaf: reminds me of my issue about packing data into low bits of pointers: unions end up really awkward.
<shachaf>
(Which is the way "ret" works, of course. It makes sense for coroutine context switches, I think.)
<daurnimator>
I guess `suspend` is really a way to save data out of registers and into the frame?
<shachaf>
Sure. So is a function call.
<daurnimator>
so really... a frame needs to be the size of stack used by the function... + enough to fit register contents at any `suspend` points.
<shachaf>
Yep.
<daurnimator>
would you need to save *all* registers?
<shachaf>
Just the ones that store whatever you need.
<shachaf>
It's almost exactly like a function call.
<shachaf>
(Except there are also callee-saved registers in typical calling conventions, and presumably you wouldn't have any here.)
<shachaf>
But the compiler knows which caller-saved registers to save, and this is the same thing.
<daurnimator>
interesting
<daurnimator>
I haven't really thought too much about this before
<daurnimator>
this was helpful for my mental model
<mikdusan>
if zig will be "doing it's own impl of coroutines" how does it know what the final frame size will be given register usage is done by llvm?
squiddlebit has joined #zig
<shachaf>
Does LLVM also lay out stack frames and do liveness analysis and so on?
<shachaf>
I don't know what API it provides exactly but I wouldn't be surprised if a compiler that does good coroutines on top of LLVM had to reimplement a bunch of that.
ltriant has quit [Quit: leaving]
<shachaf>
I've thought about some specific use cases of this a bunch but I should get my thoughts in order in general.
<shachaf>
For what it's worth, even without coroutines, it would be nice if functions clearly specified how much stack space they use in a comptime-accessible way.
<shachaf>
So you could allocate stacks yourself and guarantee that the functions will fit.
<shachaf>
As long as you don't do unbounded recursion, or call unknown function pointers, you can figure it all out statically.
<daurnimator>
shachaf: yes that's another open proposal I think
<mikdusan>
big topic. complex. /me backs away very very slowly
<shachaf>
gcc lets you compute stack usage information, by the way.
<shachaf>
But you only get it after the fact, it's not comptime-accessible. Presumably you could do some complicated multiphase compilation thing if you really wanted to.
<daurnimator>
shachaf: yeah it's emitted by gcc for the GCC linker. -fstack-limit-symbol uses it IIRC
<daurnimator>
of course we're on LLVM right now. so that doesn't help us :P
<shachaf>
All of these things have analogies for coroutines, of course.
<shachaf>
In particular, if you have nested async functions such that at frames are local variables and you're only ever waiting on one at a time, it looks exactly like a stack.
<shachaf>
(A stack is just an arena used as @Frame instead of statically allocating it.)
<daurnimator>
shachaf: indeed; that's an interesting way to think about it
<daurnimator>
shachaf: does that mean that a function call is actually sugar for `const cf = current_stack.alloc(@Frame(func)); @newStackCall(cf, func, ...); current_stack.free(cf);`
<shachaf>
If I'm reading what you wrote correctly, I think so?
<shachaf>
Where "free" means "free everything after this pointer" which you can do with an arena.
<daurnimator>
to take things too far: zig says that hidden allocations are bad. should an explicit frame be required for every call? -> why not?
* daurnimator
is thinking about semantics
<shachaf>
Because this is why we use compilers.
<daurnimator>
shachaf: maybe the stack analogy is the wrong one.... what if it's actually a nested allocator
<shachaf>
The function call syntax *is* the explicit allocation.
<emekankurumeh[m]>
ugh, moving the build stuff to userland increased my build time from ~3 minutes to ~30 minutes
<shachaf>
An arena/stack/nested allocator are all the same thing.
<daurnimator>
shachaf: like, what if it was more: `var child_stack = @maxStack(func); @newStackCall(child_stack, func, ...)`
very-mediocre has joined #zig
<shachaf>
Yes, that's what I thought you meant.
<shachaf>
I mean, in the case that @Frame(func) is an unbounded size because of recursion or whatever.
<daurnimator>
yep.
<shachaf>
As soon as you call a function you pass it ownership of the entire stack from the stack pointer on.
<shachaf>
And when it returns you get ownership of that back.
<daurnimator>
I guess taking this latter concept would end up with stackful coroutines; vs the earlier would end up with stackless coroutines
<shachaf>
I think the distinction is different (if it exists at all, which maybe it shouldn't).
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mikdusan>
seen that before; i think there is issue for it. recursive struct. Node size is unknown. so it needs to be ?*Node or somesuch
<daurnimator>
emekankurumeh[m]: just first run? or subsequent runs are slow too?
<daurnimator>
emekankurumeh[m]: and which platform?
<very-mediocre>
mikdusan: I see, I thought it might be due to the double optional-ness, since arrays are pointers, using a nullable pointer to the array should point to its first element, and that element itself is also nullable.
<very-mediocre>
so if the array is not null (implies pointer to first element is not null) but its first element is null (iirc optionals compile down to pointers, implying that the first element _is_ null), that's contradictory
<very-mediocre>
nvm that's not it, played around with the optional-ness
<daurnimator>
emekankurumeh[m]: FWIW I just did a fresh build + install and it took ~15 seconds
<emekankurumeh[m]>
first and subsequent, i'm on windows 64bit mingw-w64
<daurnimator>
emekankurumeh[m]: can you profile to figure out what's taking all the time?
<mikdusan>
for me: windows10, vstudio 2019 buildtools, msys64: build from scratch: 3m, 38s
<mikdusan>
(debug)
<mikdusan>
errr. scratch that. Release build.
<emekankurumeh[m]>
mikdusan: that must be nice
very-mediocre has quit [Read error: Connection reset by peer]
<mikdusan>
i do notice a pause on the "install step" which is now quiet (no verbosity). can't tell if it's taking longer or not
<nrdmn>
andrewrk: regarding panic on uefi: uefi provides a stderr interface. However, to use that interface, accessing a parameter that is passed to EfiMain() is required. Either we'd need to wrap EfiMain() or we leave defining panic() to the user.
very-mediocre has joined #zig
squiddlebit has quit [Quit: WeeChat 1.9.1]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
utzig has joined #zig
dimenus has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
bheads has quit [Quit: bheads]
laaron- has quit [Remote host closed the connection]
laaron has joined #zig
marijnfs_ has joined #zig
dimenus has joined #zig
Pwipwi has joined #zig
halosghost has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
fengb has joined #zig
<Pwipwi>
hello all
<Pwipwi>
I have been asking on the discord on the way to put a literal string into an []u8
<Pwipwi>
var toto = "toto"; var key: []u8 = toto[0..];
<Pwipwi>
this is the only thing working so far
<Pwipwi>
is there any simpler way ?
<Pwipwi>
shouldn't the compiler be able to sort this out ?
<mq32>
you can only put a literal string into an array (mutable) or into a non-mutable slice ([]const u8)
<mq32>
otherwise you would have a mutable slice on the string literal
<Pwipwi>
oh
<Pwipwi>
so is it a bug that the compiler lets me do that?
<mq32>
no
<mq32>
the second example is:
<mq32>
create an array (toto : [4]u8) and take a mutable slice on that array
<Pwipwi>
does it mean that my toto variable can be modified ?
<mq32>
you can "mix" types and then the Zig compiler will make an anonymous struct out of the "array"
<nrdmn>
yes but if I don't? wouldn't both syntaxes give the same result?
<mq32>
nah
<mq32>
.{ "hello", 10 } would not be an array, but would be allowed with anonymous syntax
<nrdmn>
I mean if I don't mix types
<mq32>
then it *should* give you the same syntadx
<mq32>
*result
<fengb>
Hmm, I kinda like that for replacing `[_][]const u8`
<nrdmn>
hmm, did something change about that syntax in the last two months? I have a program that used to compile successfully using the []T{...} syntax. Seems like now I have to use [_]T{...}.
Akuli has joined #zig
<fengb>
Yeah that's a breaking change
<fengb>
`[_]` means inferred array. It was a little ambiguous when `[]` doubled as both array and slice
<very-mediocre>
nrdmn: _ is required for arrays with a comptime known size, the programmer should be explicit that the size is known
<very-mediocre>
you could write a number or just _ for the compiler to infer the length
<very-mediocre>
You'd use []T for a dynamic array. iirc I've noticed andrewrk referring to that as a slice but I'm not sure if it carries the properties of a regular slice i.e. len
<very-mediocre>
"regular slice" being like `something[0..]`
<fengb>
A slice is just a fat pointer
<fengb>
It was ambiguous syntax that's been updated
<very-mediocre>
yes, I'm saying I'm not sure zig maintains a `len` for dynamically allocated arrays
<fengb>
Arrays have length. It's a compile time quality
<very-mediocre>
Zig maintains a length for slices using something[0..] syntax
<very-mediocre>
I'm saying I remember seeing andrewrk refer to []T as a slice too
<fengb>
Yeah they're always slices now
<very-mediocre>
and I wonder if that implies length is maintained
<fengb>
[N]T and [_]T are arrays
ntgg has joined #zig
<very-mediocre>
Take `const something = some_allocator.alloc(SomeType, runtime_known_count);`
<fengb>
Arrays are comptime known memory spaces
<very-mediocre>
that a []SomeType
<fengb>
You can't build arrays at runtime
<fengb>
That returns a slice
<andrewrk>
mikdusan, re: your question about coroutine frames - the way it works is we put all the variables of a function into a struct, and then have that function accept a secret pointer to that struct as the first argument
<very-mediocre>
fengb: we're talking in circles, I'm aware that is now called a slice, I just wonder if length is maintained by zig
<andrewrk>
very-mediocre, idk what you mean by "maintained"
<very-mediocre>
Can I do something.len with `something` being of type []SomeType
<very-mediocre>
(I'd test it and find out but I can't right now)
<andrewrk>
yes that's the point of a slice
<very-mediocre>
Well there you go, that's what I was asking about, thanks
<very-mediocre>
Because previously I thought slices were _only_ when you did [m..n] syntax
<fengb>
Slice is a pointer + len. For unknown lengths, it's a [*]T
<very-mediocre>
tl;dr: I know what a slice is, I just did not know dynamically allocated arrays = slice in zig until recently
<Tetralux>
Wait what?
<andrewrk>
the zig language doesn't have dynamically allocated arrays
<Tetralux>
(.. Well - strictly it does - but it's std.ArrayList.)
<andrewrk>
std.ArrayList is a dynamically allocated array and it's a different type than a slice
<very-mediocre>
Sure, that's a semantical argument though
<very-mediocre>
I understand fully now what you mean
<very-mediocre>
and it means I was using the wrong terminology when talking about zig
<Tetralux>
I'm not sure I understand why that's semantical but sure xD
<fengb>
It matters in Zig (and C, Go, etc.) where array == fixed segment of memory
<andrewrk>
a slice does not necessarily mean that it is dynamically allocated
<andrewrk>
there are statically allocated slices
<Tetralux>
^^
<very-mediocre>
Yes, indeed I've used [m..n] on various non-dynamic arrays many a time
<very-mediocre>
while a slice does not mean it's dynamically allocated, I thought that, similarly, an array being dynamically allocated did not mean it was necessarily a slice in zig
<mq32>
andrewrk, what i wondered about coroutines/CPS: can we yield from a second-level function? (so my function is calling a function that yields the coroutine) and does the coroutine frame then contain *all* local variables in my potential call stack
<andrewrk>
mq32, when the second function yields, the program counter returns to the first function
very-mediocre has quit [Read error: Connection reset by peer]
<andrewrk>
a coroutine frame contains local variables for the function only
<andrewrk>
there is no coroutine stack, there is only the kernel thread's stack
<andrewrk>
importantly "The result of an async function call is a promise->T type, where T is the return type of the async function. Once a promise has been created, it must be consumed, either with cancel or await."
<nrdmn>
I can't have pointers to anonymous arrays, right?
<andrewrk>
nrdmn, I think you can
<Tetralux>
Is the idea of cancel that it simply doesn't bother to resume a coroutine when it next becomes suspended?
brakmic has quit [Remote host closed the connection]
<mq32>
andrewrk, i want to know how that is planned as the proposal for transparent calls of async/sync code
<Tetralux>
So you essentially cannot cancel a coroutine that suspends only once?
<nrdmn>
huh? oh...
<andrewrk>
mq32, here's the way to think about it: when you call a function with async, you must consume it with `await`. Await is a suspend that will be resumed when the awaitee returns
brakmic has joined #zig
<andrewrk>
suspend/cancel is a lower level API. when a coroutine suspends, it must have a plan for how it will be resumed
<Tetralux>
When would you need to use suspend/cancel?
<mq32>
andrewrk, ah okay
<very-mediocre>
Tetralux: docs say "In general, suspend is lower level than await. Most application code will use only async and await, but event loop implementations will make use of suspend internally."
<andrewrk>
mq32, the idea behind transparent calls of async/sync code is centered around 2 things: 1. inferring that a function is a coroutine if it calls a coroutine. 2. calling a coroutine as a normal function (`foo()`) is syntactic sugar for `await async foo()`
<Tetralux>
Yeah - how the _loop_ would use suspend always puzzled me xD
<Tetralux>
But
<fengb>
andrewrk: does that mean the compiler will have to mark functions as "coroutine-able"?
<andrewrk>
Tetralux, have a look at std/event/loop.zig. after the coroutine changes, the logic will be mostly the same, it'll just be cleaner with better memory management
<andrewrk>
fengb, yes the compiler has to know whether to generate a function as a coroutine by the time it gets to the end of analysis
<fengb>
Expose the "function color" but only dispatch runtime changes
husho has quit [Remote host closed the connection]
<very-mediocre>
andrewrk: point #2: you can't you launch several coroutines without awaiting them right away?
<andrewrk>
so this does introduce a downside of: you try to pass a callback to a C API, and you get a compile error that says something like: that function has async calling convention, but you're passing it to a C calling convention API. and then there could be a stack of 50 functions in the error message and the last one at the end was a coroutine
<very-mediocre>
I'm thinking of the `await Promise.all()` pattern in JS. Apologies for talking over everyone, timing is hard to get right on IRC.
<fengb>
mq32: I think the goal is the function exists as both a regular and coroutine. But running as a coroutine limits its interoptability with C
<very-mediocre>
...unless some kind of an event loop runtime gets codegened.
<very-mediocre>
but yes that seems anti-zig
<fengb>
It's the color problem... but a bit nicer in Zig-land since the execution semantics should be the same
<andrewrk>
all the "depends on" issues in that proposal have been solved except the coroutine rewrite :)
<fengb>
How does Go solve it? Does hiding behind a blocking channel just "fix" the problem?
<andrewrk>
fengb, the goal is that a zig library can have functions that express logic that works in both environments optimally: blocking and event loop
<andrewrk>
goroutines have stacks that grow. every function call checks to make sure there is enough stack space for the function call and might allocate more stack space
<fengb>
Yeah I really like this approach. It just sounds hard and unsolved :P
<andrewrk>
I've always wanted to be able to express the inherent concurrency in control flow, even when it sometimes gets compiled single-threaded blocking
<andrewrk>
like, hey compiler these files can be loaded independently, and then only here do they both need to be complete before continuing
<very-mediocre>
JS gets a lot of hate but imho it deserves credit for popularizing concurrency + some really clean syntax for expressing it
<andrewrk>
agreed
<andrewrk>
std.event.Loop.initSingleThreaded(); // I got your node.js right here
<fengb>
Eventually some clean syntax :P
<very-mediocre>
This is going to be killer
<fengb>
Back in my day, we used callbacks and liked it
<andrewrk>
zig is trying to take it a step further though, with a thread pool event loop. max out those cores
<very-mediocre>
I remember reading the phrase - green threads multiplexed over several cores - on this channel before
<andrewrk>
I believe green threads are equivalent to goroutines, and zig does not have those, and has no plans to have those
<andrewrk>
the only stacks around here are kernel thread stacks
<very-mediocre>
Yeah you're right, I thought the term was more vague than that (I thought it'd work for "multiple coroutines per thread")
<very-mediocre>
but that isn't exactly a "scheduler", just naive multiplexing
<Tetralux>
Q: How easy would it be to go from simple single-threaded code, to coroutine-MT code?
<Tetralux>
Is this just a case of adding async/await in a few places, essentially?
<andrewrk>
(I'm not trying to have a semantic argument with you, just trying to keep the information clear in this channel with 112 people in it, many of them newbies)
<very-mediocre>
I understand, I generally assume everything is said in good faith. :)
<andrewrk>
Tetralux, according to the #1778 it would be nothing more than adding this to your root source file: pub const io_mode = .ThreadedEventLoop;
<fengb>
So... CS-y semantics it'd be fibers?
<Tetralux>
Oh I see - so the idea is you'd write the code with the intention of using an event loop and async/await and then just set it to MT vs ST.
<Tetralux>
So you'd write it as if it was MT to begin with?
<andrewrk>
yes, evented-MT, evented-ST, or blocking-ST
<andrewrk>
you'd write it as if it was evented-MT
<Tetralux>
And the difference between using managing kernel threads yourself and this would be that you have some syntax to help you write it in a more sequential way.
<Tetralux>
.. And presumably have better stack traces for free.
<andrewrk>
just like in status quo zig you should write it as if it was MT but you can pass --single-threaded which does things like make thread-local variables into normal global variables
<andrewrk>
yes stack traces will be a big thing\
<Pwipwi>
is there something like warn() but that outputs to stdout ?
<Tetralux>
Does "write it as if its MT" mean that you are using Mutexs and things to protect for thread safety, but they get simplified out in --single-threaded?
<Tetralux>
But actually making a Thread would still be exactly that.
<andrewrk>
Pwipwi, const stdout_file = std.io.getStdOut(); and then `const out = &stdout_file.outStream().stream;`
<andrewrk>
Pwipwi, need to handle the error from getStdOut though
<Pwipwi>
I've been using stdout.write() for a while
<Pwipwi>
just wondered if there was something that did the formatting for me
<Pwipwi>
on stdout
<andrewrk>
in my example `out.print()` is what you want
<Pwipwi>
oh
<very-mediocre>
stdlib auto-documentation is gonna go a _long long_ towards increasing adoption
<andrewrk>
Tetralux, that's correct, std.Mutex turns into no-ops in --single-threaded. making a thread is a compile error with --single-threaded
<andrewrk>
actually std.Mutex turns into deadlock detection safety in --single-threaded debug builds. in release builds it's no-ops.
<Pwipwi>
@very-mediocre that and intellisense :)
<andrewrk>
both planned, both depend on the same thing, both still probably 2 release cycles out
<Pwipwi>
so one year ?
<andrewrk>
that's my estimate yes
<nrdmn>
andrewrk: I've had a look at panicking on uefi. Outputting any message requires accessing an argument that's passed to EfiMain(). So I think we would either have to wrap EfiMain() and do some initialization work hidden from the user or let the user provide a panic(). What's your opinion on that?
<Pwipwi>
sweet
<Tetralux>
So presumably the entire point of --single-threaded is for embedded, and for debugging, essentially.
bheads has joined #zig
<Tetralux>
Because in reality, why wouldn't you have it otherwise.
<andrewrk>
need to take the address of the stream field
<andrewrk>
I almost said something about it explicitly when I gave you the example code above
<Pwipwi>
ok
<Pwipwi>
yeah, I lexed it but didn't parse
<Pwipwi>
I used to code in C like 10 years ago
<Pwipwi>
trying zig coming from the wonderful javascript world.
<Pwipwi>
I'm trying to keep questions at a minimum, but it's not easy :)
<andrewrk>
questions are more than welcome
darithorn has joined #zig
<mq32>
every question means that something hasn't been documented well :P
<fengb>
There's a lot of (former) JS programmers here
<andrewrk>
there's nothing more on topic here than questions about how to use zig
<Pwipwi>
sure, but at this moment it's understandable that it wouldn't
<gonz_>
fengb: How do you figure?
<Pwipwi>
I wouldn't consider myself as *former* JS coder :)
<gonz_>
This seems like a foregone conclusion but I'm curious what makes people think so
<fengb>
andrewrk did a bunch of JS work. I do JS with my day job
<fengb>
So 2 most important people do JS :P
<gonz_>
I think in any IRC room there's bound to be a lot of programmers who have been forced to use JS, even. :D
<Pwipwi>
I think JS is enjoyable provided you can use typescript :)
<andrewrk>
I don't think js programmers have discovered it yet but zig is already a pretty reasonable tool for creating node.js modules with wasm
<Pwipwi>
I just wanted to have a more systemy language
<Pwipwi>
andrewrk : that's actually one of my use cases !
<andrewrk>
because the generated .wasm can be uploaded to npm
<andrewrk>
we even have the ability to compile C code for .wasm, and a wasm-compatible libc (that is far from complete)
<Pwipwi>
sweet
<companion_cube>
that's where the next war is fought for low level languages: wasm!
<companion_cube>
I wonder how soon we'll see electron apps mostly written in wasm
<Pwipwi>
never ?
<gonz_>
I don't even know if I can categorize what kind of programmer I am. Not by numbers, at least. I did C++ for seven years but I was terrible at learning and I ended up hating it.
<fengb>
I actually don't see wasm replacing JS any time soon :/
<gonz_>
I work very profitably with Elixir & Erlang, but I dislike them too
<companion_cube>
there's no replacing of it, but competing would be nice already
<Pwipwi>
gonz_ ain't nothing wrong hating cpp
<fengb>
Oh? First I've heard anyone dislike Elixir lol
<gonz_>
It's an unmaintainable mess
<fengb>
Huh
<companion_cube>
lack of types?
<gonz_>
Yes
<companion_cube>
that's the one thing that scares me away from it 🤷
<gonz_>
No way to model anything correctly and enforce any kind of invariants
<Pwipwi>
the fun part is that this unmaintainable mess makes your code an unmaintainable mess ! \o/
<Pwipwi>
I tried to like Rust
<fengb>
The macros have scared me... but they've been scaring me since Lisp
<gonz_>
Not to shittalk another language too much, though. This is #zig :P
<andrewrk>
thanks gonz_ :)
<Pwipwi>
by the way, is there work planned on organizing the standard library ?
<andrewrk>
for now the standard library is allowed to get big, because it helps test the language
<Pwipwi>
I meant more of a reorganization like a containers folder which different implementations in it
<Pwipwi>
that kind of thing
<Pwipwi>
like the crypto/ folder
<fengb>
andrewrk: I've noticed a lot of "core" things are being extracted out of Go, like crypto. Will we have a "standard repository" for stdlib like stuff that's not included?
<Pwipwi>
iirc, hash_map is at top level
very-mediocre has quit [Read error: Connection reset by peer]
<mq32>
fengb, that's one thing that annoyed me a lot and prevents me from using stuff like Rust/dotnet Core
<mq32>
you have a language and a really thin std library
<mq32>
and then you download like 50 packages into *every* project just to get your "hello world" program to compile
<Pwipwi>
yay python stdlib
<Pwipwi>
andrewrk is there any reason why zig won't accept arrays as slice parameters ?
<Pwipwi>
maybe doing a [0..] under the hood ?
<Pwipwi>
I find myself creating static arrays a lot, just to take their [0..] as parameter
<fengb>
mq32: pioneered by npm :P
<Pwipwi>
oh nevermind, I can do it with const
<fengb>
But more seriously, it allows each library to iterate on its own instead of depending on core releases
<mq32>
yeah, that's true
<mq32>
but i think there's a path between "npm" and ".NET" thickness of stdlib
andersfr has joined #zig
andersfr has quit []
<halosghost>
that's quite a wide gap there
<companion_cube>
rust's stdlib seems a pretty decent size to me
<companion_cube>
it's bigger than C++'s but doesn't try to include stuff like http
kristoff_it has quit [Ping timeout: 246 seconds]
<fengb>
I think Python is a great counter example. There was urllib, urllib2 both in core and neither was well supported
<fengb>
Sometimes the batteries get super stale but they also can't be fixed due to breaking changes
laaron has quit [Remote host closed the connection]
<Tetralux>
Is it sometimes?
return0e has quit [Read error: Connection reset by peer]
<Tetralux>
Or is it always?
<Tetralux>
Seems more likely always to me.
<companion_cube>
rust includes basic traits and types to help the ecosystem agree on them, which I think is healthy
<Tetralux>
Does that not limit you?
<fengb>
I suppose Java still includes the Vector class :P
laaron has joined #zig
<halosghost>
I think providing things like traits/interfaces in the std lib is a great idea so that programmers can standardize on those interfaces and the implementations can be easily pluggable
<halosghost>
best example I can give would be the mistake that Haskell made with STring
<halosghost>
s/Tring/tring/
bheads_ has joined #zig
<halosghost>
would have been dramatically better if String were a typeclass (read: interface, trait) instead of a bare type
kristoff_it has joined #zig
<halosghost>
that specific example isn't really applicable to Zig, but I hope the spirit makes sense
return0e has joined #zig
<companion_cube>
also things like std::future for rust, they're agreeing on it so async/await can be stabilized
bheads has quit [Ping timeout: 244 seconds]
bheads_ is now known as bheads
<gonz_>
I dunno, an `IsString` type class is still very usable in the end.
<gonz_>
Regardless of having the base type
<halosghost>
gonz_: If you're disagreeing with me, I don't understand what part you're disagreeing with :)
<gonz_>
Having the base type didn't somehow exclude having the `IsString` type class which people can implement
<halosghost>
for sure
<halosghost>
but that was added on later
kristoff_it has quit [Ping timeout: 272 seconds]
<halosghost>
rather, if String (or IsString, whatever) had been in the prelude from the beginning, then that standardization could have happened a lot sooner
<companion_cube>
in rust, even the initial (de)serialization stuff is deprecated and universally replaced by serde
<companion_cube>
which is de facto standard
very-mediocre has joined #zig
ntgg has quit [Remote host closed the connection]
fengb has quit [Remote host closed the connection]
tgschultz has quit [Ping timeout: 248 seconds]
tgschultz has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
kristoff_it has joined #zig
bheads_ has joined #zig
bheads has quit [Ping timeout: 244 seconds]
bheads_ is now known as bheads
kristoff_it has quit [Ping timeout: 244 seconds]
ky0ko has joined #zig
bheads has quit [Ping timeout: 244 seconds]
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
MajorLag has quit [Ping timeout: 268 seconds]
kristoff_it has quit [Ping timeout: 268 seconds]
MajorLag has joined #zig
MajorLag is now known as tgschultz
marler8997 has joined #zig
<andrewrk>
Pwipwi, a slice is a reference; an array is a value. zig won't implicitly make reference unless it's safe (such as for static constants)
<andrewrk>
there will need to be community efforts to help organize zig packages
<andrewrk>
zig's decentralized model takes burden from the zig project itself and puts it on the community
<andrewrk>
we will need third party package discovery services, third party curating, and community lead decisions on what packages are considered "standard"
fengb has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
bheads has joined #zig
very-mediocre has joined #zig
<darithorn>
just learn from npm's mistakes. i swear i hear almost every day about some npm package being compromised
tgschultz has quit [Ping timeout: 276 seconds]
tgschultz has joined #zig
<fengb>
npm's problem exists because it's a centralized repo without any community guidance
<andrewrk>
zig packages won't be capable of being compromised, users of packages lock exact versions with hashes
<fengb>
I think at the very least, we should have some "core" that's trustworthy
<andrewrk>
of course, when you update to a new version of a package, you are trusting the new code. so skip reading code diffs at your own risk, depending on how much you trust someone
darithorn has quit [Quit: Leaving]
<fengb>
andrewrk: do you foresee something like Debian's packages? Where there's an actual official repository where things can get merged if well maintained and trusted
<andrewrk>
I think that would be a great third party project
<andrewrk>
I could see the zig project "blessing" one or more of these third party project with an official statement saying that the zig project considers it trustworthy and meeting quality standards
<THFKA4>
as long as it plays nicely with nixos
<THFKA4>
also, i think zig is broken since 0.4 on guix because it runs something out of the build output directory or something
<companion_cube>
maybe the blessing could be pgp signatures of releases?
tgschultz has quit [Ping timeout: 264 seconds]
<THFKA4>
in case you care lol
<andrewrk>
THFKA4, happy to help if you can write up an issue with some more details
tgschultz has joined #zig
<THFKA4>
already uninstalled it, sorry. i'll try it again in a VM someday
<fgenesis>
since we're asking about weird systems, any plans for XP support? (as long as it "works"...)
* mq32
is not surprised…
<andrewrk>
THFKA4, if guix is your system, then I'd be more motivated to get it working. in general, however, I think effort is better spent on the language and other core concerns at this time. broadening the set of supported targets is a later stage effort
* fgenesis
high fives mq32
<andrewrk>
currently zig's policy is to support windows versions still supported by microsoft. that means the lowest supported windows is Windows 7, which you can see on https://ziglang.org/#Support-Table
<fgenesis>
yea i've seen that and got a little sad :D
<andrewrk>
what's your windows xp use case?
<fgenesis>
because i'm wondering how far it might be possible to backport
<fgenesis>
oh, a lot. everyday use kinda
<andrewrk>
you use windows xp as your main operating system?
<fgenesis>
i like having a finished, stable system that's not broken by random updates anymore
<fgenesis>
on my secondary dev machine, yes
<fgenesis>
it thinks it's a POS system so it did get updated until recently
<andrewrk>
interesting
<fgenesis>
plus i need it to supply software to my C64
<fgenesis>
needs this weird kernel driver that works super well on XP and bit-bangs stuff out the LPT port to make the commodore floppy drive actually work on modern systems
<andrewrk>
I doubt that zig's policy on minimum windows versions is going to change. but we have been moving closer to using NtDll for more API which as I understand my help that use case
<andrewrk>
I haven't filed that issue yet
<andrewrk>
also zig's lazy analysis helps the use case a lot
<andrewrk>
because if you don't use a feature, then you don't depend on it
<fgenesis>
NtDll is going to fail hard once i try compiling for w98, then =)
<fgenesis>
aaactually KernelEx might work, but not sure
<andrewrk>
a fork of zig lowering the minimum windows version would be reasonably straightforward
<andrewrk>
I need to keep the scope of this project under control
<andrewrk>
I don't want to be working on a programming language for the rest of my life, I want to be building stuff with it, goddammit
<fgenesis>
i'm more curious about where LLVM draws the line
<andrewrk>
afaik LLVM does not have the concept of windows versions
<fgenesis>
yes, and then annoying users come along and demand Win3.11 support :o)
<companion_cube>
with 💵 hopefully
<very-mediocre>
andrewrk: i think you'll be in a safe situation if at least 1 major corporation adopts zig for a critical app of some kind
<andrewrk>
I still want enough "grass roots" sponsors though, so that said corporation can't jerk me around
<very-mediocre>
yeah i just mean in terms of credibility to keep the project going even if you'd like to retire, or not work on it so much
<andrewrk>
I see
<very-mediocre>
even hated corporations have cred, like facebook
<very-mediocre>
everyone hates facebook, but they produce tons of open source stuff and everyone says "oh facebook is backing this project"
<companion_cube>
easy, just convince Linus to use Zig in the kernel from now on 🙃
<fengb>
I wonder if he'll curse our Zig like he does C++
<companion_cube>
very-mediocre: technically, FB are good; but to users they're bad
<fengb>
s/our/out/
<very-mediocre>
I'll have to disagree with you there but anyway that's a moot point
<andrewrk>
I think that zig wolud be a great fit for the linux kernel, and linus would be unreasonably skeptical about it
<very-mediocre>
Linus had become one of those "code of conduct" cultists recently
<fengb>
FB open source is surprisingly everywhere, e.g. they're the current maintainers of jemalloc
<companion_cube>
otoh if some people use Zig for hardware drivers…
<companion_cube>
where C is king but also really bad
<andrewrk>
let's not get into a code of conduct argument please. that's controversial and off topic
<very-mediocre>
sure i don't meant to get into it much more than that
<very-mediocre>
just saying he's very uncharacteristic now
<andrewrk>
yeah don't even mention it, it's off topic bait
<very-mediocre>
hard to predict how he'd react
<very-mediocre>
noted
tgschultz has quit [Ping timeout: 250 seconds]
<companion_cube>
I don't think linux would adopt a language driven by llvm, though
<andrewrk>
anyway there's a really good reason to be skeptical about zig and that is about its lack of maturity
<Tetralux>
Yeah - just the frequency of running into wierd compiler bugs is enough to dismiss it pretty easily for some people.
<andrewrk>
the llvm monoculture is also a reasonable objection, but that's also related to maturity given that's recognized that we'll need more backends than LLVM provides and an official language specification
<very-mediocre>
LLVM hasn't hurt Rust much I think
<companion_cube>
yeah, personnally I think I'd consider Zig a safe bet for real projects when it gets a gcc frontend
<companion_cube>
(after 1.0 and after a spec exists)
<andrewrk>
so there are those good reasons to be skeptical. but I really think it holds up to scrutiny beyond that
<fgenesis>
oh, there are plans for that?
<companion_cube>
very-mediocre: some people dismiss rust because it has only one compiler
<andrewrk>
companion_cube, what about that c++ one?
tgschultz has joined #zig
<very-mediocre>
Rust does have Firefox backing it though, that's huge. I wonder what Zig's killer app could be
<companion_cube>
it's partial, afaik, it doesn't do the borrow checking
<fgenesis>
which of the many, slightly broken c++ compilers?
<companion_cube>
it's mostly there for independent bootstrapping I think
<very-mediocre>
this is a very consolidated space right now
<companion_cube>
what if systemd adopted Zig? ;-)
<very-mediocre>
connections seem to trump merit
<fgenesis>
pearls on pigs
fengb42 has joined #zig
fengb has quit [Ping timeout: 260 seconds]
<andrewrk>
I do think that we'll start to see more complicated and impressive zig projects once the community can start depending on each other's code
omglasers2 has joined #zig
<andrewrk>
and then consequently the fact that the stage1 compiler doesn't have all the planned performance improvements of self-hosted will become painful
<Tetralux>
..And once there are fewer compiler bugs :')
<very-mediocre>
maybe the most immediate most mainstream use case is web server software, that attracts tons of people and they tend to get pretty entrenched
<companion_cube>
I wonder if the end result compiler would be comparatively "simpler" (or as simple) than Go
<companion_cube>
since it's something people apparently love about Go
<andrewrk>
Tetralux, yeah. the main difference with self-hosted isn't that it will be written in zig, although that will help - the main difference will be that the requirements are fixed...
<andrewrk>
zig stage1 compiler has had its premises yanked out from underneath it so many times
<companion_cube>
another weird question: could Zig bootstrap from a wasm image?
<companion_cube>
(ocaml bootstraps from a bytecode version of its compiler + the C interpreter, for reference)
<Tetralux>
.. meaning that there is more motivation to--slash, is easier to---fix bugs in it?
<andrewrk>
bootstrapping means using source only. a wasm image is not source
<andrewrk>
Tetralux, I'm saying that it's a lot easier to write bug-free code when the requirements are fixed
<andrewrk>
companion_cube, have you seen the bootstrapping issue?
<companion_cube>
andrewrk: but you depend on a C++ compiler then
<Sahnvour>
in what timeframe do you see zig hitting beta stage (almost 1.0 stage2, etc.) ? 2-3 years ?
<andrewrk>
Sahnvour, yes
<andrewrk>
it feels like the issues are never-ending, but in reality there are only a handful of major proposals left
<andrewrk>
and once the language stabilizes all the sudden there won't be *new* bugs
<Sahnvour>
I don't think major proposals will eventually stop but I get your point
<Tetralux>
andrewrk: Hmmm. That's not so clear-a-correlation to me. And yeah - there's always new bugs xD
<Tetralux>
But yeah, the waterfall will prob subside a bit over time.
very-mediocre has quit [Read error: Connection reset by peer]
<andrewrk>
Sahnvour, oh, I mean my own proposals, sorry :)
Akuli has quit [Quit: Leaving]
<andrewrk>
at some point zig will be closed for proposals
very-mediocre has joined #zig
<very-mediocre>
golang has ~4600 open issues
<bheads>
then the zig ISO standard will be formed
<bheads>
the MS will extend it
<very-mediocre>
I still think without a killer app things may go in a D-like direction
<Sahnvour>
andrewrk: that's a bold claim, I can't think of a language reaching maturity early on and never updating, even C does
<very-mediocre>
I know pandering sucks but it'd be nice if zig focused on excelling in 1 area for a while just to attract ppl
<andrewrk>
Sahnvour, there will be updates for sure. for example we have to keep up with LLVM/Clang versions, and update the standard library for new operating system stuff. maybe even add a new operating system
<andrewrk>
major language changes, on the other hand, the plan is to finish the language and then leave it alone
<emekankurumeh[m]>
so zig will stay 1.*.*?
<andrewrk>
IMO javascript got worse with ES6
<very-mediocre>
ES6 added Promises though, way better than "then"
<very-mediocre>
ES7 or 8 was async/await
<very-mediocre>
ES5 is pretty miserable imho
<Sahnvour>
I understand, but it's pretty inevitable people get annoyed at some quirks that weren't discovered early enough, and sometimes they might even be right about it :p
laaron has quit [Remote host closed the connection]
kristoff_it has joined #zig
<andrewrk>
Sahnvour, the plan is to fix quirks and design flaws, and I'm willing to bump major versions to do that (I have some ideas so that packages can specify the zig version to make this not break everything)
<andrewrk>
but I don't expect to add new features
<emekankurumeh[m]>
imho that's a bit of a bummer but i can see why you would want to do that
<companion_cube>
C barely evolved in the last 20 years, indeed
<companion_cube>
hopefully, starting now, we could get a language that doesn't need to evolve much either
<andrewrk>
that's been the plan all along, I'm sorry if I didn't make that clear
<companion_cube>
(except for stuff like compiling to CUDA or whatever future architecture will be invented)
<andrewrk>
let's make sure it's a great language before 1.0 then shall we?
<companion_cube>
:D
<very-mediocre>
there is some appeal to it not having tons of radical changes
<very-mediocre>
C++ priotizes backwards compat and it creates a massive amount of cruft
<very-mediocre>
and other languages break too much
kristoff_it has quit [Ping timeout: 245 seconds]
<very-mediocre>
python2->3 was a huge mess
<Sahnvour>
about that, the optimizer is bothering me by outlining every function every time they get more than 1 call, even if inlining it at some points would be a huuuge win
<companion_cube>
question is: what new *important* trends will appear in the next 20 years
<companion_cube>
async/await is fairly new, for example, but everyone wants it somehow
<very-mediocre>
btw andrewrk: what would _you_ personally use zig for
<companion_cube>
his music player! :D
jjido has joined #zig
<very-mediocre>
no need to answer if you find this line of inquiry inappropriate, no pressure. But I thought it might give some insight on the language.
<andrewrk>
if you look at my github repos I have quite a lot of projects
<very-mediocre>
great, thanks. I find this really insightful, I should have asked earlier.
<andrewrk>
other projects I've done in the past that would have been better in zig: json-like configuration parser, libsoundio, all the games listed on andrewkelley.me (most are playable in the browser), a game engine for rapid prototyping, statically recompiling nes games to native executables, static website generator, using genetic algorithm to evolve brainfuck code, minecrat bot API framework
<Sahnvour>
I'm looking forward to gamedev with zig so much ...
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<very-mediocre>
all very cool
<very-mediocre>
the most insightful thing imho is your C++ code
<very-mediocre>
it might be fair to say it wants to be zig code
<Sahnvour>
nice
<very-mediocre>
seriously C++ codebases can be so awful, check out his code in Genesis though
<companion_cube>
I forgot, is anything planned for type parameter inference? so one could use ArrayList without specifying the type explicitly
<Sahnvour>
although I would wait for our linker/hot reload to consider it really serious
<andrewrk>
very-mediocre, genesis does not link libc++
<andrewrk>
turns out if you avoid most C++ features you don't even need that
<andrewrk>
Sahnvour, ah yes that's a big deal
<very-mediocre>
yeah, I've written a few C++ projects and they came out like just classes and procedural glue code and not much more
<Sahnvour>
I would also really like to work on them but time is lacking unfortunately
<Sahnvour>
now that I've used Live++ I would hardly consider working without this on a game if that's my main activity
<very-mediocre>
gamedev is so like the rockstar of the programming world
<THFKA4>
zig dorf fortress when
<Sahnvour>
very-mediocre: and like rockstars it's mostly about the image
<very-mediocre>
maybe so, I genuinely love games though. I've made 4 and released 0.
<very-mediocre>
if i have time in the distant future i'd think about making a zig-godot binding
<very-mediocre>
i am out, i'm absurdly burned out. Thank you all for the discussion.
very-mediocre has left #zig [#zig]
fengb42 has quit [Remote host closed the connection]
fengb has joined #zig
<fengb>
I'm actually curious what pro game devs think about Zig. The only ones I've spoken to are pretty opinionated like Jon Blow
<mq32>
it really depends
<mq32>
there are the engine guys who really want 150% control
<mq32>
and then there are the guys who only make game logic
<mq32>
they want maximum abstraction
<THFKA4>
i think "ziggurat" would be a pretty sweet name for a zig package repo
<THFKA4>
just wanted to share
<companion_cube>
:D
<THFKA4>
the .dev is only $2400/yr
<Sahnvour>
i'm doing engine and no day goes that I don't wish I could use zig instead of C++ ... and I was really into C++ before that :p
<fengb>
I think everyone now agrees C++ sucks. But they all seem to want that 10%
<mq32>
<= actually likes C++17 a lot
<mq32>
if you just ignore all legacy stuff
<companion_cube>
still not as clean as rust, if you're into that level of complexity 🤷
<mq32>
yeah, but i cannot use Rust for my kind of code
<mq32>
low level embedded with rust is just "working against the language"
fengb has quit [Ping timeout: 260 seconds]
<mq32>
i've switched hardware platforms for my next project, so i first have to compile a new LLVM version to build a custom version of Zig against it in order to use zig
<mq32>
xtensa-elf32 is not supported by the mainline LLVM
<THFKA4>
you doing radar or wifi?
<tghume>
Hey so I'm writing a blog post about ways of doing generics that contains a Zig example. I'm wondering how you'd add methods to a generic data structure.
<andrewrk>
tghume, have a look at std/array_list.zig
<tghume>
The example for methods refers to the struct by name in the self parameter of the method like `self: Vec3`
<tghume>
thanks
<tghume>
ah cool a special Self name like Rust
<mq32>
THFKA4: Playing around with my odroid go and some other ESP32 based boards to *maybe* create a distributed OSish thingy
<tgschultz>
tghume: short answer based on that: const Self = @This(); in the struct body, then refer to Self
<tghume>
oh thanks almost missed that line and thought Self was special
<mq32>
really good thing in Zig: IF it isn't a keyword or there's an @ in front of it, it ain't special :)
<tgschultz>
andrewrk: I don't think being able to create types and unions with new fields is so bad. Then again, I did create the pseudo-struct so I'm clearly insane.
<andrewrk>
tgschultz, I think you can think of #2907 as a stepping stone to #383. if anything it gets us closer to that
<tghume>
I was just looking at some example metaprogramming use cases for my blog post and some of them required creating structs with dynamic fields
<tghume>
which in Zig would require the fully-featured reify that can create structs
<tghume>
The main real example I have is replicating Swift for Tensorflow's autodifferentiation feature as a library.
<tghume>
You need to be able to automatically create a struct for the gradient that contains all the differentiable fields of the parent struct.
<tghume>
In Zig if it was complete enough I think it would also allow you to implement the feature where you can import C headers as just a non-privileged library that uses libclang.
<mq32>
just a brainfart: with @reify and @embedFile Zig could have a comptime implementation of protobuf
<andrewrk>
yep
<mq32>
and i think it would be great, no more stupid code generators in build scripts… :)
<mq32>
got to go
<andrewrk>
I think for translate-c it is good to have the translated zig AST be in a file somewhere. it helps for 3 things: 1. compile errors 2. debug info 3. caching
<andrewrk>
the same argument coudl be made for protobuf