<wilsonk>
g-w1: I think Andrew said he will use the 80/20 rule to get the %80 low hanging optimization fruit for the stage2 backend and leave the difficult %20 to LLVM (if someone wants/needs that level of opt). So it will have SOME optimizations but not the hardest to implement
<g-w1>
That makes sense.
<wilsonk>
once the parallelization of stage2 is complete, I believe the non-LLVM backend will smoke the LLVM backend (even with -O)...won't even be close. Plus incremental, in-place, hot code swapping...! :)
<g-w1>
do you also think the generated code will be better?
<pixelherodev>
For debug builds, I think so
<pixelherodev>
For runtime builds, no, and that's a good thing.
<wilsonk>
yeah, pixel is correct I believe
<pixelherodev>
s/runtime/release
<g-w1>
why is it a good thing
<ifreund>
the argument is that llvm's rampant complexity and high compile times are not worth the 20% speed or whatever it turns out to be
<ifreund>
it's also a very heavy dependency
<g-w1>
yeah
<g-w1>
but to compile the stage1 compiler you will need llvm.
<wilsonk>
yes, but once the stage2 compilers C backend is complete then you can bootstrap itself once and you won't need the LLVM backend afterwards (it is sort of a circular dependancy to start...rust was similar with its original need for OCaml...little different though)
<ifreund>
rust bootstrapping is a mess currently :(
decentpenguin has quit [Quit: ZNC crashed or something]
<wilsonk>
yeah, it is a pain sometimes (I haven't worked on it in a while but I was there back in the OCaml days ;) )
<wilsonk>
pushed some code before Patrick even started on the project...that was a long time ago!
<g-w1>
that makes sense. is that the only reason for a c backend? Its pretty cool
<wilsonk>
not the only reason...CBE can be useful for targeting really exotic architectures that zig doesn't have a code generator for. So you can produce the C code and then use gcc (or a specialized compiler for just that arch) to build the exe
cole-h has quit [Ping timeout: 256 seconds]
xackus has quit [Ping timeout: 246 seconds]
<pixelherodev>
One example is the z80, for instnace
<pixelherodev>
I doubt Zig will be as good as SDCC for the z80 any time soon
<pixelherodev>
But CBE means we don't have to be
_whitelogger has joined #zig
decentpenguin has joined #zig
ryuukk_ has joined #zig
<andrewrk>
hmm we could be providing a zip for windows developers to make a debug build of zig + release build of LLVM
<ryuukk_>
i installed zig on arch linux, but for some reason it can't find log in std ./src/main.zig:17:8: error: container 'std' has no member called 'log', zig version is 0.6.0, does anyone have an idea
<g-w1>
try master
<andrewrk>
0.6.0 std doesn't have log, the error is correct
<ryuukk_>
oh ok
<andrewrk>
I think I finally fixed the macos CI
<wilsonk>
ugh...trying to build llvm11 on a macos VM with 64 cores but forgot to increase the RAM up to >64GB! SWAPPING hell!
<wilsonk>
well, maybe I could get away with about 40GB from my old notes, but whatever...
<andrewrk>
the trick is to limit the number of simultaneous link jobs
<wilsonk>
I only assigned 8GB so it is taking a while to shut down
<wilsonk>
yeah, I could do that but I have plenty of RAM so I will just assign more on reboot
<wilsonk>
there we go, now all the cores are maxing out at %100
<ryuukk_>
it works with latest version, thanks
msingle has quit [Ping timeout: 256 seconds]
<Snektron>
packed struct?
<Snektron>
oh whoops, i was scrolled way up, that was for ifreud
dddddd has quit [Ping timeout: 240 seconds]
dddddd has joined #zig
<ryuukk_>
that's pretty nice my code works on both windows and linux, i had 0 changes to make
earnestly has quit [Ping timeout: 272 seconds]
<andrewrk>
living the dream
kristoff_it has quit [Ping timeout: 260 seconds]
Stephie has joined #zig
solaire has joined #zig
solaire has quit [Client Quit]
decentpenguin has quit [Quit: ZNC crashed or something]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
decentpenguin has joined #zig
cr1901_modern has joined #zig
Kingsquee has joined #zig
AceNovo has joined #zig
AceNovo has quit [Quit: Konversation terminated!]
AceNovo has joined #zig
AceNovo has quit [Quit: Konversation terminated!]
AceNovo has joined #zig
marnix has joined #zig
PC980178 has joined #zig
PC98017 has quit [Ping timeout: 256 seconds]
PC980178 is now known as PC98017
radgeRayden has quit [Ping timeout: 272 seconds]
radgeRayden has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
AceNovo has quit [Quit: Konversation terminated!]
AceNovo has joined #zig
lltt has joined #zig
frett27 has joined #zig
ur5us has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 260 seconds]
lltt has quit [Remote host closed the connection]
gazler_ is now known as gazler
radgeRayden has quit [Remote host closed the connection]
<daurnimator>
dang; why am I finding it so hard to finish 5852
<jabb>
i'll help
<jabb>
5853
marnix has quit [Ping timeout: 272 seconds]
cole-h has joined #zig
marnix has joined #zig
lltt has joined #zig
lltt has quit [Remote host closed the connection]
lltt has joined #zig
<wilsonk>
that was a left jabb, if I ever saw one...duck next time darnimator :)
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<jabb>
is the current method for dynamic dispatch @fieldParentPtr?
<jabb>
(reading std.io.reader)
osa1 has joined #zig
ur5us has joined #zig
<jabb>
would this strategy work for storing pointers to these types? it appears this method is only for static dispatch?
<g-w1>
I am taking a look at the old emit-h c++ code to try to impliment it and I am seeing stuff like this buf_appendf(out_buf, "enum %s {\n", buf_ptr(type_h_name(type_entry)));
<ifreund>
I think structs have always been anon
<ifreund>
enums let you set a tag type with `const Foo = enum(u42) { ... }`
<g-w1>
ohhhhhhhhhhhhh
<g-w1>
the c emitted code is `enum A {b}`
<g-w1>
thats y it looks like that
<ifreund>
not familiar with ancient zig though, I showed up in the 0.5.0 release cycle
<ifreund>
heh, yeah emitting C code not zig
<g-w1>
im looking at 0.6.0 for reference on the emit-h
<ikskuh>
daurnimator: didn't know you're the maintainer of community/zig
<daurnimator>
ikskuh: tada
<ifreund>
what is community/zig?
<ikskuh>
the arch package
<ifreund>
ah yes
<daurnimator>
FYI the llvm 11 package is currently blocked on the zig 0.7.0 release
<g-w1>
so 2 more weeks till llvm11 on arch?
<daurnimator>
as long as zig is released ;)
<g-w1>
ok
<ifreund>
zig release is planned for the 26th iirc
<ikskuh>
:O
<ikskuh>
11 days to go
<g-w1>
does anyone know what the equavalent type for CodeGen was in the c++ compiler
<FireFox317>
g-w1, wdym?
<g-w1>
in the self hosted compiler
<g-w1>
is there an equavalent type to CodeGen
<g-w1>
im trying to impliment gen_h in selfhosted
<g-w1>
and using the c++ implimentation as reference
<ifreund>
g-w1: Compilation
<g-w1>
ok
<ifreund>
though be aware that stage1 in general doesn't show the ideal way to do things, the idea is to learn from its shortcommings as we develop stage2
<g-w1>
ok
<g-w1>
that makes sense
<ifreund>
stage2's architecture is already significantly different
<g-w1>
its pretty cool that its a compiler, assembler and linker
<kristoff_it1>
it would be a great shame if multiple people were to submit the article link to HN
<g-w1>
I am a little stuck reading the Compilation.zig. would I want to use zir for emit-h, or an ast. CodeGen in stage1 just had CogeGen.fn_defs. is there something simmilar?
<ifreund>
maybe Module is what you really want
<ifreund>
it tracks the Decls, which include functions
<g-w1>
oh. yeah
<g-w1>
that makes sense
<g-w1>
thanks
<ifreund>
(the function info would be in Decl.typed_value)
<g-w1>
ok thanks
lltt has quit [Ping timeout: 256 seconds]
AceNovo has quit [Quit: Konversation terminated!]
AceNovo has joined #zig
<pixelherodev>
g-w1: gen-h isn't going to be the same in stage2
<pixelherodev>
I'm working on it as part of the CBE
<pixelherodev>
(C backend)
<pixelherodev>
Basically, we already have a backend that takes ZIR and produces C89
<pixelherodev>
So I'm tweaking it to support header generation too
<pixelherodev>
gen-h will basically be "only generate the header, not a .c file"
<pixelherodev>
...huh. That's new.
<pixelherodev>
`./zig build test-stage2` results in a segfault. I checked the produced builder and it's segfaulting in _start ??
<ifreund>
pixelherodev: it worked for me using my zig built from some point before llvm10 was merged and with master checked out
<pixelherodev>
ifreund: I just downloaded the new static zig, now I'm good :P
<ifreund>
nice
<pixelherodev>
Ugh, I'll be better once stage2 is done though :P
<pixelherodev>
stage1 is hella slow
<ifreund>
same
<pixelherodev>
Like, i'm just trying to make a single header with an automated tool, why can't you even beat me doing it manually? :P
<ifreund>
I've been writing a lot of code without compiling anything recently though
<pixelherodev>
SLight exaggeration, but still :P
<ifreund>
so it's not too bad
<pixelherodev>
That's what I've started doing too
<pixelherodev>
Building less often
<ifreund>
oh in my case it's hundreds (thousands?) of lines that I literally haven't tested
<ifreund>
I'm making nice bindings for wlroots and all the other c libraries I use
<ifreund>
which will also allow me to switch to a musl based system
<ifreund>
since translate-c can't handle C bitfields yet, and musl uses one someplace glibc doesn't
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<pixelherodev>
g-w1: if you want to look at the CBE, it's in codegen/c.zig
<g-w1>
yeah
<pixelherodev>
I'm hoping to get emit_h working for stage2 today
<g-w1>
i saw it was doing some of the same stuff
<pixelherodev>
Should be pretty straightforward
<pixelherodev>
I'll probably just store the current config in link/C.zig as `emit_h: bool, emit_c: bool`
<pixelherodev>
Could be something like "if both are on, generate a C file and a .h file, with the headers needed by the .c in the .h. Otherwise, if emit_c is on, generate a C file with headers stored at the top of the file [this is current behavior]. Otherwise, if emit_h is on, generate a header file with headers for all exported functions. If both are off, fail"
<g-w1>
e
<g-w1>
sry
<pixelherodev>
Does that logic make sense?
<g-w1>
i think emit-c should auto turn emit-h on
<pixelherodev>
The key difference is that if emit_c is on, then even with emit_h on, the header only contains functions / decls needed by the .c file
<g-w1>
yeah
<pixelherodev>
It makes sense not to want that
<g-w1>
maybe call it something different
<g-w1>
for zig/cbe
<pixelherodev>
Currently, the header is generated at the top of the .c file
<pixelherodev>
Actually, a better idea is to make it an enum for the active mode
<pixelherodev>
C, Header, or None
<g-w1>
yeah
<pixelherodev>
There shouldn't be an option to generate a separate header from a c file
<pixelherodev>
The point of the CBE is machine code (in C89 form), not human code, so it shouldn't be trying to make it easier to read (though it obviously shouldn't go out of its way to make it harder either)
<pixelherodev>
A lot of the code is reusable, which is nice
<g-w1>
if i want to help with stage2 what should i do. i just started working on the emit-h but you are working on it :P is there anything that needs someone to work on that no one is doing
<pixelherodev>
astgen, maybe?
<pixelherodev>
Basically, AST->ZIR conversion
<g-w1>
is that not complete?
<pixelherodev>
That's one of the major focuses, because it contributes to *every* backend
<pixelherodev>
Nope
<g-w1>
ok
<pixelherodev>
You could also just try to get tests passing
<pixelherodev>
That's what I was doing initially, but now I'm focusing on the CBE
<ifreund>
wasm codegen could use a lot of love as well
<g-w1>
cool
<g-w1>
i just dont want to overlap with anyone else
<ifreund>
right now it's totally separate from the normal codegen but that should be fixed
<ifreund>
I'm the only one who's done stage2 wasm work so far and im currently occupied with other things so if you wanted to work on that there wouldn't be any conflicts
<ifreund>
you could also work on improving riscv support or add a new target or something
<g-w1>
ok. ill take a look at astgen. i dont know much about wasm or stack machines in general.
<ifreund>
go for it!
FireFox317_ has joined #zig
<g-w1>
i do have a powerpc mac sitting around so i could try to do stuff with that :)
<ifreund>
ppc would be neat :)
<ifreund>
vexu has at least one open PR doing astgen stuff you should probably be aware of
FireFox317 has quit [Ping timeout: 256 seconds]
<g-w1>
ok
<pixelherodev>
I'd base any astgen work off of that PR, yeah
rain1 has joined #zig
ryuukk_ has joined #zig
hnOsmium0001 has joined #zig
Akuli has joined #zig
skuzzymiglet has joined #zig
<pixelherodev>
Hm, a better idea is probably to not have emit-h go through the linking stage :P
<pixelherodev>
Makes more sense to have a separate part of the codebase which calls into the CBE for header generation instead
<g-w1>
yeah. I was thinking that std.c should have a function to translate zig types into c types so that it could be used by CBE. what do you think about that
<g-w1>
it could also be used by emit-h
<pixelherodev>
emit-j *is* part of the CBE
<pixelherodev>
Which already has such functionality
omglasers has joined #zig
<g-w1>
oh.
<pixelherodev>
This doesn't belong in std.c; this is part of the compiler, not the standard library
<pixelherodev>
emit-h*
<g-w1>
yeah. didn't you just say that you wanted to put emit-h in a seperate part of the codebase?
<pixelherodev>
g-w1: see renderType in codegen/c.zig
<pixelherodev>
No
<pixelherodev>
I meant the caller
<pixelherodev>
link/C.zig currently calls the CBE for source files
<pixelherodev>
I was thinking of adding the header part to Module or something
<g-w1>
oh
<pixelherodev>
The CBE gets called into by a separate piece which tells it where to render results
<pixelherodev>
The idea is to also have whatever calls it determine "source vs header"
<g-w1>
ok
<pixelherodev>
So it'd mean e.g. `header = std.ArrayList(u8).init(); cbe(.{ .out = header.writer(), .mode = .header});`
<g-w1>
ok
tsujp has quit [Ping timeout: 246 seconds]
tsujp has joined #zig
<g-w1>
when I do zig build --verbose-ir or zig run --verbose-ir nothing happens. how do i get the output of the --verbose flags?
omglasers has quit [Quit: Leaving]
<pixelherodev>
g-w1: I'm fairly certain they go to either stdout or stderr
<g-w1>
does it work for you?
xzto has joined #zig
xzto has left #zig [#zig]
<g-w1>
now it works. lol
donniewest has joined #zig
donniewest has quit [Client Quit]
donniewest has joined #zig
lltt has joined #zig
osa1 has quit [Remote host closed the connection]
xd1le has quit [Read error: Connection reset by peer]
xd1le has joined #zig
xzto has joined #zig
xzto has quit [Quit: WeeChat 2.9]
xzto has joined #zig
xzto has quit [Client Quit]
frett27 has joined #zig
ryuukk__ has joined #zig
ryuukk_ has quit [Ping timeout: 258 seconds]
xzto has joined #zig
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
xd1le has quit [Read error: Connection reset by peer]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
xd1le has joined #zig
xzto has quit [Quit: WeeChat 2.9]
xzto has joined #zig
yeti has quit [Ping timeout: 240 seconds]
layneson has joined #zig
yeti has joined #zig
xzto has quit [Quit: WeeChat 2.9]
xzto has joined #zig
AceNovo has quit [Quit: Konversation terminated!]
AceNovo has joined #zig
cole-h has joined #zig
wesleyac has joined #zig
<dutchie>
hrm
<dutchie>
why does my program segfault whenever i run in unsafe modes but run fine in safe modes
* dutchie
trying to poke it with gdb but not really sure what is going on
<dutchie>
it's in std.rand.Xoroshiro128.fill
cole-h has quit [Quit: Goodbye]
<pixelherodev>
Might be a bug
<FireFox317_>
dutchie, probably you are taking the address of a stack variable. Which is not clear when you are using the Random interface
<dutchie>
yeah, i guess
<pixelherodev>
but safe mode should fail too...
<pixelherodev>
Unless the safety checks are ironically enough adjusting the stack in such a way that it doesn't
cole-h has joined #zig
<dutchie>
i did think that, also that my stack variable should live longer than the call into another function?
<dutchie>
i can't reproduce it with a smaller example
cole-h has quit [Client Quit]
<dutchie>
i'll try rebuilding with master, i guess
<donniewest>
Are there any decent resources for getting into zig yet? I've been considering picking up something lower level than Java/Javascript/Kotlin that are my usual go-to. I've been tempted by both Rust and C but zig looks like the best of all worlds
<ifreund>
yes, but you don't have to have it in the api
<donniewest>
I've dipped my toes in a couple times, but gotten a bit perplexed by the C interop
<donniewest>
Lol, yeah, I figured as much. I was hoping there was something that'd get me 80% of the way there regarding using existing C libs
<ifreund>
that's one way, or you can do it like the example i posted up there with reallySpeak()
<jabb>
familiarity with low level stuff like memory and pointers will help immensely
<ifreund>
std.Allocator does this as well, you don't call allocFn or resizefFn directly
<jabb>
ohhhhh, nice
<ifreund>
yes, a solid mental model of how memory works is the single most valueable thing you can bring I think
<jabb>
yeah, this is awesome dynamic dispatch
<jabb>
feels closer to the metal
<jabb>
but saf
layneson has quit [Ping timeout: 256 seconds]
<ifreund>
indeed
<g-w1>
donniewest: what c libraries are you thinking of using
<ifreund>
and it doesn't need any special syntax
<jabb>
yeah
<jabb>
just @fieldParentPtr
<jabb>
donniewest: i'd say dive in and ask questions when you're stuck
<ifreund>
^
<jabb>
ziglearn is a good start
<donniewest>
Either Chromium Embedded Framework (CEF) or libgraphqlparser. I was playing with getting an http server to parse graphql queries and never actually got importing libgraphqlparser to work
<donniewest>
Granted, that's also what I get for not choosing basic enough of a problem, lol
wootehfoot has joined #zig
<donniewest>
I might give it another shot and see what happens. Zig's guide on memory management didn't confuse me but if someone has a good primer on memory management (even in a different lang) I'd be happy to dive in
<g-w1>
it seems like that is c++
<g-w1>
nvm
<donniewest>
From what I can tell, CEF and libgraphqlparser are written in C++ but have C interfaces
<g-w1>
yeah
<g-w1>
what I would do is look at how they do the ffi in other languages and then do the same
wootehfoot has quit [Read error: Connection reset by peer]
FireFox317_ has quit [Ping timeout: 256 seconds]
GrooveStomp has quit [Ping timeout: 272 seconds]
GrooveStomp has joined #zig
burkac has quit [Remote host closed the connection]
marnix has quit [Ping timeout: 260 seconds]
Akuli has quit [Quit: Leaving]
xackus has quit [Ping timeout: 258 seconds]
kristoff_it1 has quit [Ping timeout: 260 seconds]
donniewest has quit [Quit: WeeChat 2.9]
<frett27_>
hello, i got a compiler bt on this line, is it legal ? : self_ptr.reconnect_registered_topics = mem.zeroes([10][*]u8);
<frett27_>
an array of unconstraint u8 slice
<frett27_>
Unreachable at /home/use/zig/src/stage1/analyze.cpp:5430 in hash_const_val_ptr. This is a bug in the Zig compiler.
<frett27_>
'll try the today master
<ifreund>
well, even if it didn't crash that shouldn't work
<ifreund>
you can't init a non-optional pointer to 0
ofelas has quit [Ping timeout: 246 seconds]
<frett27_>
what's the memory representation of [10][*]u8 in a struct ?
<companion_cube>
10 pointers next to one another, I think?
<ifreund>
yes
cole-h has quit [Quit: Goodbye]
<frett27_>
ifreund: i didn't caught you, and don't understand why it's not legal
<frett27_>
a fixed array of pointers is sized known ?
<companion_cube>
pointers have a known size, yes
<earnestly>
Typically languages that need to know sizes at compile time in certain constructions can be "worked around" by using pointers for that reason
<ifreund>
frett27_: [*] pointers may not be null
<ifreund>
?[*] pointers may be null
<ifreund>
0 is null
skuzzymiglet has quit [Ping timeout: 258 seconds]
<frett27_>
ifreund, thank's for the addition
<earnestly>
ifreund: So much in C would be fixed if pointers were not allowed to be null by default, with some qualifier that allowed it
<ifreund>
earnestly: I know, zig is so much easier to use because of that simple change
<ifreund>
the distinction between pointer-to-one and pointer-to-many and what not is nice as well
omglasers2 has quit [Read error: Connection reset by peer]
<frett27_>
ifreund, it compiles now,
cole-h has joined #zig
<frett27_>
thank's
<ifreund>
nice!
<companion_cube>
earnestly: and if C had arrays, too
<companion_cube>
ifreund: definitely is, C could have slices, strings, etc.
<companion_cube>
cuts heavily on the security faults
<companion_cube>
security flaws*
<earnestly>
I wish I could find that article which explains why a string type is a bad idea
<ifreund>
"arrays" are not slices or strings though...
kristoff_it1 has joined #zig
<ifreund>
and yeah, language level string types don't make sense imo
<ifreund>
what is or isn't a valid character is a social construct
<earnestly>
Well the article mentioned their replacement with standard arrays, whereby the bytes are then encoded/decoded as needed
<earnestly>
A string is technically a monoid
<earnestly>
(Unrelated fact about strings)
<ifreund>
that's pretty much zig's approach
<ifreund>
a "string" is just a []const u8
<companion_cube>
earnestly: even [u8] would be a good string type
<ifreund>
(slice of raw bytes)
<earnestly>
companion_cube: Exactly
<companion_cube>
but that's not something C can do
<earnestly>
Yeah I'm going for the "C doesn't have arrays" bait
<earnestly>
But perhaps you're refering to how you access them compared with the underlying memory model where "parallel arrays" means something else
<companion_cube>
I just mean it doesn't have any meaningful notion of array, except those with fixed length
<companion_cube>
the rest is just pointers without the associated length, and it's a terrible footgun
xd1le has quit [Remote host closed the connection]
<ifreund>
i'd call pointer + length a slice
<ifreund>
don't "arrays" always have fixed length?
<earnestly>
In my mind, yeah
<earnestly>
ifreund: As for slices, consider: https://0x0.st/iG7j.txt () is also array notation, think q.data[
<companion_cube>
depends whether the "fixed length" is an actual comptime constant
<earnestly>
companion_cube: Well, arrays that can change their length usually have a different name, such as dynamic arrays, vectors, etc.
<earnestly>
But it's a somewhat semantic point as I know what you meant
<ifreund>
earnestly: that's quite expressive
<ifreund>
also, this syntax makes my brain hurt
<earnestly>
ifreund: It's of the algol school, predates C heh
<earnestly>
ifreund: I'd like to see this sort of thing more too: https://0x0.st/zXYw.txt -- here provers can use this information to prove the implementation. zig is nice in that much of this can be made compile-time whereas these exist as runtime "asserts"
<earnestly>
If you prove the routines then you can turn off the asserts but that's eh.
<earnestly>
(Because proof doesn't compose; and provers tend to make a few assumptions about the global state)
<earnestly>
ifreund: This is a specification, not an implementation, so a bit like a header
<companion_cube>
earnestly: there's a third thing
<companion_cube>
array of fixed lenght, but length is known at runtime
<companion_cube>
length*
<companion_cube>
vectors/dynamic arrays are something else indeed
<ifreund>
earnestly: what happens if e.g. enqueue is called when the queue is full?
<earnestly>
companion_cube: The only way the runtime can know that length is by inserting checks every time its accessed. This could be too much of a performance burden
<g-w1>
if a string type is a bad idea then why do some things use it in the standard lib ([:0]u8)? Is it just for convenience to c apis?
<ifreund>
or can that be statically prevented somehow?
<earnestly>
ifreund: exceptions
<ifreund>
g-w1: convinince and it prevents unecessary copies
<ifreund>
earnestly: ew
<companion_cube>
earnestly: you mean, bound checking? yup
<earnestly>
ifreund: Ada is a bit more sane about exceptions, but yeah. A bit like Standard ML it has them
<companion_cube>
the default should always be bound checking
<companion_cube>
with a possibility of disabling them in bottlenecks
<companion_cube>
(as in, "hold my bottle" ? :DD)
<earnestly>
companion_cube: That's pretty much Ada's attitude. It gives you plenty of pragmas to turn off checking on specific things
<earnestly>
ifreund: (It's not like C++'s exceptions)
ryuukk__ has joined #zig
<ifreund>
that's good
<ifreund>
I'm still not a fan of jumpy control flow though
<earnestly>
There's no "try"
<ifreund>
ok yoda
<earnestly>
:D
<earnestly>
ifreund: Oh they have goto as well
<ifreund>
that seems like it shouldn't be needed if you have exceptions already
<earnestly>
Yes, such things typically aren't used for error handling like goto out in C
<earnestly>
But it's pragmatic I suppose
ryuukk_ has quit [Ping timeout: 272 seconds]
<earnestly>
ifreund: The main thing I've seen it used for are jumping around in loops but it's very rare (not that I've seen much)
<ifreund>
i feel like people writing ada are likely to be aware of the perils of goto
<ifreund>
C really does need it to handle errors properly though
<earnestly>
They're all retraining to C++ lul
<earnestly>
"Looking for Ada developer to help port the Apache platform to C++"
<ifreund>
writing C++ depresses me
<ifreund>
I'm pretty good at it, but I just can't enjoy it
<earnestly>
(By Apache I mean the helicoptor)
<ifreund>
awe, really?
<earnestly>
Apparently so
<earnestly>
*shrug*
kristoff_it1 has quit [Ping timeout: 256 seconds]
<companion_cube>
earnestly: that's pretty much what every language but C has
frett27_ has quit [Ping timeout: 256 seconds]
<earnestly>
companion_cube: Meanwhile ESA has left more crators in Mars than NASA :p
<earnestly>
craters*
<earnestly>
At that level the language doesn't really matter so much
<companion_cube>
not everyone writes C the way JPL does.
<companion_cube>
if C were restricted to such domains, I wouldn't care indeed…
<earnestly>
companion_cube: tbf, they generate most of their C from python, heh