I will never get tired of commenting things like that. I'm pretty amazed that Zig community becomes more about programming in general, not just focused on Zig and it's pretty cool. Also people are very friendly and topics are interesting.
This is amazing. The location with the chairs, then smoothly going to an auidience and present your passion, then go back to the chair to chill and answer questions. I think this "sit down" thing makes is so much more enjoyable than standard talks and their setups. Thank you for this!
An interesting recommendation I got from senior developers about embedded programming was to construct everything at the start of the execution and then never again, this makes OOM basically impossible (unless you run out at the initialization) and simplifies a lot of logic.
We do this on all embedded systems where i work. I personally think its a great way to design reliable systems, at least for the purposes i am designing for.
It's a good principle if resource hogging isn't a problem. But if you need to share the system with other software that might need sporadic amounts of memory it makes more sense to "be nice" and only hog a sensible amount of resources, and in exchange expect the other processes will be nice enough to let you get more memory when you need it. For a "dumb" web server though, where you know it's always going to be running on the same hardware that only serves that purpose. Then yeah, just allocating in advance might be a lot smoother.
Feels like memory and threads management has very similar problems. Allocation of memory "buckets" to requests runs into strategies analogous to those applying GPU (or CPU) threads to multiple concurrent tasks. Not surprising, since we're still a while away from having "infinite" local threads. ;-)
He did mention implementing setjmp and longjmp with inline assembly. And in unsafe code, data races can happen. It's your job to ensure that an unsafe code block becomes safe.
"it's written in language X which this audience (Zigmas) isn't familiar with, but don't worry, you don't need any familiarity with it to understand my presentation" I think your response to the statement moreso indicates your own biases
I will never get tired of commenting things like that. I'm pretty amazed that Zig community becomes more about programming in general, not just focused on Zig and it's pretty cool. Also people are very friendly and topics are interesting.
This is amazing. The location with the chairs, then smoothly going to an auidience and present your passion, then go back to the chair to chill and answer questions. I think this "sit down" thing makes is so much more enjoyable than standard talks and their setups. Thank you for this!
An interesting recommendation I got from senior developers about embedded programming was to construct everything at the start of the execution and then never again, this makes OOM basically impossible (unless you run out at the initialization) and simplifies a lot of logic.
We do this on all embedded systems where i work. I personally think its a great way to design reliable systems, at least for the purposes i am designing for.
Some games also do this. Tiger beetle database written in zig also does this.
It's a good principle if resource hogging isn't a problem. But if you need to share the system with other software that might need sporadic amounts of memory it makes more sense to "be nice" and only hog a sensible amount of resources, and in exchange expect the other processes will be nice enough to let you get more memory when you need it.
For a "dumb" web server though, where you know it's always going to be running on the same hardware that only serves that purpose. Then yeah, just allocating in advance might be a lot smoother.
> A webserver that never allocates
> Look inside
> Memory allocation
> Car that runs on electricity
> Follow the power line
> Coal burning
> Large cap company that isn't evil
> Look up subcontractors
> Evil
Man these are fun!
This is so old school with ideas from late 1980’s.
people got real excited over functional programming when it got popular, even though it existed since the late 1950s
Roc platforms remind me a lot of John Ousterhout's TCL language with it's Wish and Expect "platforms"....
Feels like memory and threads management has very similar problems. Allocation of memory "buckets" to requests runs into strategies analogous to those applying GPU (or CPU) threads to multiple concurrent tasks. Not surprising, since we're still a while away from having "infinite" local threads. ;-)
ah yes, a webserver that never allocates, just what I need for my web application that never works
36:29 Loris's gears were spinning the whole time Folkert was saying that 😂
hahaha "i use rust actually" :D to funny ngl i really like this though
Shoutout to the Thy Catafalque shirt
wonder if they would add support for surrealdb
Given that safe rust can prevent data race, what are the causes of the race conditions? What do you need to do that requires unsafe rust?
Is this a question about something said in the video, or is it about Rust in general?
@@jaysistar2711 The video. The talker mentioned that he needs to fix some race conditions in the talk, and I am wondering why he needs to
@@re-lax3580Oh, 29:18 . I'm not sure what race conditions to which he may be refering.
He did mention implementing setjmp and longjmp with inline assembly.
And in unsafe code, data races can happen. It's your job to ensure that an unsafe code block becomes safe.
Race condition is not a data race
Ohh that "Don't be scared.." when he explained that it's written in Rust is so cult-like LOL.
I don't see how 'Don't be scared' is cult like...
he only said that cause many people are biased against rust and the language itself has pretty intimidating syntax, i assume
"it's written in language X which this audience (Zigmas) isn't familiar with, but don't worry, you don't need any familiarity with it to understand my presentation"
I think your response to the statement moreso indicates your own biases
Setjmp / longjmp aka “try catch” lol