<< 21-09-2024 >>
00:10:54*wikipedia joined #nim
00:32:31*beholders_eye quit (Quit: WeeChat 4.1.2)
01:22:48*lucasta joined #nim
01:30:20*krux02 quit (Remote host closed the connection)
02:53:57*nerthus joined #nim
03:34:44FromDiscord<graveflo> what do you mean dead code though? could `used` pragma help? I dunno if that will stop the C compiler from omitting it though
03:36:02FromDiscord<Elegantbeef> If you want to keep the code alive you make it a dynlib proc
03:36:28FromDiscord<graveflo> yea that makes sense, but I guess that wasn't what he was asking then
03:36:42FromDiscord<Elegantbeef> We'll never know
03:36:52FromDiscord<graveflo> its killing me
03:54:30*rockcavera joined #nim
04:22:17FromDiscord<carogaph_> why is he an app
04:22:31FromDiscord<oye> In reply to an unknown message: -# oye requested by @carogaph_ https://media.discordapp.net/attachments/371759389889003532/1286905375706320936/2024-06-18_14-58-49_UTC_3.jpg?ex=66ef9b87&is=66ee4a07&hm=01e2ce69bdba386c71a05cd5d837d8411cf727be3b0bba9839f2e9f364377445&
04:22:47*lucasta quit (Quit: Leaving)
04:45:41*xet7 quit (Remote host closed the connection)
06:13:20FromDiscord<Robyn [She/Her]> In reply to @carogaph_ "why is he an": beef is a hyperintelligent AI with a built-in humour module
06:14:31FromDiscord<Elegantbeef> It's a pretty faulty module
06:33:41*alexdaguy joined #nim
06:40:02FromDiscord<xkonti> sent a code paste, see https://play.nim-lang.org/#pasty=keylPmgO
06:41:01FromDiscord<Elegantbeef> It's a tagged union so the largest branch is the size
06:43:09FromDiscord<carogaph_> In reply to @chronos.vitaqua "beef is a hyperintelligent": no wayi don't believe that for a second
06:52:20FromDiscord<Robyn [She/Her]> In reply to @carogaph_ "no wayi don't believe": no shit lmao
06:52:31FromDiscord<Robyn [She/Her]> he's a matrix user, this discord has a bridge
06:54:49FromDiscord<carogaph_> Ah
07:07:03FromDiscord<Elegantbeef> Beep boop booooop
07:37:03FromDiscord<xkonti> In reply to @Elegantbeef "It's a tagged union": That's awesome news! I read up on "tagged unions" and it seems like a good choice for encoding/decoding CBOR values.
07:37:51FromDiscord<Elegantbeef> You can just steal Nim's `std/json` if you want a short path
07:38:38FromDiscord<Elegantbeef> It's a nice goto for whenever you want runtime typed information since it's a tagged union that has float, int, string, bool, array, fields
07:39:20FromDiscord<Elegantbeef> It's not really done to the proper spec of json, but it's nice on the front that it's a prepackaged object variant
07:44:56FromDiscord<xkonti> sent a code paste, see https://play.nim-lang.org/#pasty=AGrULRdH
07:45:28FromDiscord<Elegantbeef> `copyMem` is right there 😄
07:45:57FromDiscord<xkonti> (edit) "https://play.nim-lang.org/#pasty=ooxXNWHH" => "https://play.nim-lang.org/#pasty=vQHbQoQR"
07:46:44FromDiscord<xkonti> That sounds like a nice shortcut 😄
07:48:19FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=xNVkdrvq
07:48:42FromDiscord<Elegantbeef> I think that's right, if it's not do the math on a napkin or something
07:51:09FromDiscord<Elegantbeef> You can probably do `bigEndian64(result.addr, data[read.pos].addr)` from `std/endian`
07:51:49FromDiscord<Elegantbeef> Guess it's actually `littleEndian`
07:53:43FromDiscord<Elegantbeef> This is why I just pretend there is a single endianess as my code never will enter the realm of BE
07:55:55FromDiscord<xkonti> I'll need to check the CBOR specification for that... I looked at copyMem and I'm secretly hoping that Nim types align with CBOR as it could save some headaches when encoding/decoding integers, floats, byte arrays and string arrays 😄
07:56:26FromDiscord<xkonti> (edit) "secretly" => "not-so-secretly"
08:02:55*ntat joined #nim
08:15:08*nerthus quit (Quit: Client closed)
08:30:22*coldfeet joined #nim
08:37:26*Guest82 joined #nim
09:37:35*ntat quit (Ping timeout: 260 seconds)
09:37:52FromDiscord<odexine> CBOR has a few libraries already made for it doesn’t it?
09:39:54*ntat joined #nim
09:40:42*ntat quit (Read error: Connection reset by peer)
09:41:17FromDiscord<blashyrk> sent a code paste, see https://play.nim-lang.org/#pasty=IWeElwht
09:41:54FromDiscord<blashyrk> (edit) "https://play.nim-lang.org/#pasty=EbDdcdFX" => "https://play.nim-lang.org/#pasty=BsgIfmCd"
09:47:30*SchweinDeBurg quit (Read error: Connection reset by peer)
09:52:26*SchweinDeBurg joined #nim
10:07:45*FromDiscord quit (Remote host closed the connection)
10:07:58*FromDiscord joined #nim
10:08:05*beholders_eye joined #nim
11:01:09FromDiscord<elykpha> is it currently possible to build a production ready android app in nim?
12:56:35FromDiscord<Robyn [She/Her]> In reply to @blashyrk "Hi all! Does anyone": if the value of the identifier is not known at compile-time, best you can do is something like emitting an `{.error: "`iden` is not of type `C`"}.`
12:57:44FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=XudBDjpd
12:57:48FromDiscord<Robyn [She/Her]> @blashyrk
12:59:26FromDiscord<Evaluate>
13:08:57FromDiscord<demotomohiro> sent a code paste, see https://play.nim-lang.org/#pasty=lcYFyLQH
13:14:13FromDiscord<blashyrk> Thanks!
13:32:27*xet7 joined #nim
13:52:19*ntat joined #nim
14:59:51*coldfeet quit (Remote host closed the connection)
15:32:56*alexdaguy quit (Quit: WeeChat 4.4.2)
15:47:32FromDiscord<Nlits (Ping on reply)> Is there some standardization for a useChronos instead of asyncdispatch flag? Or does each library have it's own flag
15:50:01FromDiscord<odexine> there was an attempt at standardisation
15:52:38FromDiscord<Nlits (Ping on reply)> In reply to @odexine "there was an attempt": Which was?
15:54:41FromDiscord<odexine> -d:asyncBackend
15:55:32FromDiscord<odexine> =chronos or =asyncdispatch
15:55:38FromDiscord<odexine> does not work for many libraries
15:56:32FromDiscord<Nlits (Ping on reply)> Ah yes, i just found that
15:56:34FromDiscord<Nlits (Ping on reply)> Thx
15:57:45FromDiscord<Nlits (Ping on reply)> In reply to @odexine "-d:asyncBackend": Is that provided or should i manually make a define variable
15:57:56FromDiscord<odexine> "provided"?
15:57:56FromDiscord<Nlits (Ping on reply)> (edit) "define" => "strdefine"
15:58:10FromDiscord<Nlits (Ping on reply)> In reply to @odexine ""provided"?": As in native in nim
15:58:12FromDiscord<odexine> the library has to support it explicit
15:58:15FromDiscord<odexine> (edit) "explicit" => "explicitly"
15:58:27FromDiscord<odexine> if its not mentioned by the library it wont do anything at all
15:59:05FromDiscord<Nlits (Ping on reply)> In reply to @odexine "the library has to": I mean do i need to `const asyncBackend {.strdefine.} =""`
15:59:14FromDiscord<odexine> if you want to make a library work with chronos generally just replacing the import in the library should work
15:59:36FromDiscord<odexine> In reply to @nlits "I mean do i": that wont do anything, the library has to support the define
15:59:45FromDiscord<Nlits (Ping on reply)> 🤦
15:59:55FromDiscord<odexine> you dont have to define it in any case
16:00:20FromDiscord<odexine> either the library says it supports the define or you have to manually patch the library
16:00:22FromDiscord<Nlits (Ping on reply)> In reply to @odexine "you dont have to": All i am asking is weather i can directly reference asyncBackend, nothing else
16:00:45FromDiscord<Nlits (Ping on reply)> I am currently trying to make a pr to a library to add chronos support
16:00:49FromDiscord<odexine> oh okay
16:01:29FromDiscord<odexine> one moment let me check how its implemented
16:01:38FromDiscord<Nlits (Ping on reply)> So `asyncBackend` is not some constant in the system library and must be defined manually correct?
16:01:59*Guest82 quit (Quit: Client closed)
16:03:55FromDiscord<odexine> i believe you do yes, create the strdefine
16:05:28FromDiscord<odexine> wait wait wait
16:05:47FromDiscord<odexine> no yes you make the define, sorry i misread some code
16:06:23FromDiscord<ieltan> In reply to @nlits "So `asyncBackend` is not": It's a convention
16:06:49FromDiscord<ieltan> So no, it's not done by the system library but by the user library
16:07:23FromDiscord<ieltan> In reply to @odexine "if you want to": It's more complex than this
16:08:02FromDiscord<odexine> In reply to @ieltan "It's more complex than": i intended to say that it was a first step but forgot to xd
16:08:25FromDiscord<ieltan> Trying to port a library to chronos and you need to take care of exceptions because chronos will say "NO you must not raise `Exception` but every exception raised by asyncdispatch is `Exception` so you need to at least refractor error handling
16:08:26FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "So no, it's not": Ok, there finally the answer i was looking for
16:09:00FromDiscord<odexine> didnt i say that you do create the strdefine?
16:09:31FromDiscord<ieltan> You did say that lol
16:10:00FromDiscord<odexine> it was my mistake for thinking that you were using a library, that was my first assumption
16:10:07FromDiscord<ieltan> But I guess most people don't know `asyncBackend` is a convention when they first see it
16:10:22FromDiscord<ieltan> So they don't know where the hell it comes from
16:11:25FromDiscord<ieltan> Also another refactoring is when you use other async libraries using asyncdispatch you'll have to use the chronos equivalent
16:13:40FromDiscord<ieltan> Good luck for this, since there the "asyncdispatch to chronos" guide is the chronos wiki and it doesn't cover much, and there's no "use those libraries instead" guide either
16:15:52FromDiscord<ieltan> So honestly, I guess you're better off supporting one or the other unless you're willing to spend a lot of time doing shims
16:17:23FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "So honestly, I guess": The library i am working on supports only asyncdispatch but i need some support that only chronos has so i am attempting to port it
16:17:46FromDiscord<Nlits (Ping on reply)> I would prefer to stick to one but it doesn't seem like an option
16:20:25*SchweinDeBurg quit (Quit: WeeChat 4.5.0-dev)
16:20:44FromDiscord<Nlits (Ping on reply)> Do you think it would be simpler to remake httpclient for asyncdispatch than port the library to chronos to use chronos' httpclient
16:20:49*SchweinDeBurg joined #nim
16:21:21FromDiscord<Nlits (Ping on reply)> (The original issue that lead to all of this is that std/httpclient doesn't fully support Http 1.1)
16:26:28FromDiscord<Nlits (Ping on reply)> Honestly, ditching std/httpclient and reworking something is starting to seem like the better option
16:28:19FromDiscord<ieltan> In reply to @nlits "(The original issue that": Oh I see
16:28:38FromDiscord<ieltan> Lemme check something first
16:30:02FromDiscord<ieltan> You forced to used http 1.1? Cuz there's a good library that supports http 2, it's also blocking so you can just wrap it in a async proc
16:30:47FromDiscord<ieltan> https://github.com/guzba/curly
16:32:43FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "You forced to used": No, i was planning on switching to curly as my alternative and most likely will. Currently in the process of abandoning the pr idea
16:33:56FromDiscord<ieltan> In reply to @nlits "No, i was planning": I'd recommend you do so since it seems like the fastest, sure fire way to get your things done
16:34:05FromDiscord<ieltan> Switching to curly I mean
16:34:51FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "I'd recommend you do": I will have to make an async wrapper but it shouldn't be too hard
16:38:16FromDiscord<Nlits (Ping on reply)> Thanks you to all who helped me get through this process
16:38:25FromDiscord<Nlits (Ping on reply)> And saved me a bunch of time
16:38:57FromDiscord<Phil> In reply to @nlits "No, i was planning": Seems pretty fair
16:40:21FromDiscord<Phil> Like, doing the jump to chronos would've been a strenuous jump even for me and I'm at least somewhat in depth familiar with the concept behind everything involved (asyncdiapatch, chronos, httpx and prologue itself)
16:40:22FromDiscord<ieltan> Well I don't think it's gonna be too hard yeah just make a async prow and requests stuff inside. I personally don't like the whole `asyncBackend` shtick because you end up refactoring a bunch of stuff so I would skip the wrapping and support either one of the other. Maybe doing it the chronos way first would make it easier to make it work with asyncdispatch later one but I dunno
16:42:30FromDiscord<Nlits (Ping on reply)> Btw, what was the shared library depedency system again for .nimble? The one that has you install the library when you nimble install the package
16:43:15FromDiscord<odexine> In reply to @ieltan "Well I don't think": it prolly would have worked if chronos was "just a better asyncdispatch"
16:45:35FromDiscord<ieltan> In reply to @odexine "it prolly would have": I mean, it is a better asyncdispatch. Exceptions tracking work for one
16:45:55FromDiscord<odexine> it is, but it also has a lot of additions that as you say make migration more difficult
16:46:05FromDiscord<odexine> i guess i mean a "better dropin replacement"
16:46:19FromDiscord<ieltan> since the std library is kinda broken fixing it would break stuff, which is kinda ironic
16:46:28FromDiscord<ieltan> It's not a drop in for sure tho
16:46:44FromDiscord<odexine> ah the good ol "i relied on the cpu heating up" kinda shit
16:46:54FromDiscord<ieltan> Don't think it was ever advertised as such either :p
16:47:21FromDiscord<odexine> not really, i think thats the impression it left on me
16:48:37*wikipedia quit (Read error: Connection reset by peer)
16:49:28*wikipedia joined #nim
16:51:20FromDiscord<ieltan> Also another thing about supporting two async backend is that the feature set you can use is strictly the features that both libraries support, in other words you can't use all the niceties chronos offers like cancelation...
17:00:02FromDiscord<Nlits (Ping on reply)> Is it threadsafe to share one curly for all threads or should i create a new instance for each thread
17:02:49FromDiscord<ieltan> Looks like it https://github.com/guzba/curly/blob/master/examples/advanced_nonblocking.nim
17:02:59FromDiscord<ieltan> (edit) "it" => "it's thread safe"
17:04:20FromDiscord<ieltan> Maybe add `{.threadvar.}` to the global curly instance, run it for a while and remove it and see if anything quirky happens
17:06:01FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "Maybe add `{.threadvar.}` to": Won't that create a new one for each thread anyways
17:08:34FromDiscord<ieltan> That's the point, you're trying to see if you can if you can safely reuse the instance across threads, make a test with the pragma to have a baseline and then remove it to see if it still holds
17:09:20FromDiscord<ieltan> But my gut feeling is that it's multithreaded and it seems to be made for this purpose so you'll be fine I think
17:18:10FromDiscord<xkonti> sent a code paste, see https://play.nim-lang.org/#pasty=ptIYBihO
17:19:48FromDiscord<Nlits (Ping on reply)> Wrapping curly for async is proving harder than expected. I can't exactly keep on checking until the request is found then complete the fut, i have to have a table and everything.
17:20:02FromDiscord<Nlits (Ping on reply)> it is still much easier than any other option
17:21:53FromDiscord<odexine> In reply to @xkonti "Is there a way": are you doing anything else in decode?
17:22:02FromDiscord<odexine> (edit) "decode?" => "`decode`?"
17:25:35FromDiscord<ieltan> In reply to @nlits "Wrapping curly for async": Seems weird to me, what's the issue that prevents from completing the future when the request is done?
17:26:50FromDiscord<Nlits (Ping on reply)> In reply to @ieltan "Seems weird to me,": The non-blocking poll for request doesn't give any details about which request it is the response to. So if request B finished before request A then the results would be mixed up
17:28:52FromDiscord<Nlits (Ping on reply)> I am fixing that by using ID's
17:29:38FromDiscord<ieltan> In reply to @xkonti "Is there a way": It should be `cast[ptr string](value.addr)[]` btw
17:30:01FromDiscord<ieltan> And if you want zero copy, move it
17:30:58FromDiscord<ieltan> Or maybe `{.cursor.}`, but I haven't tested that one yet
17:32:16FromDiscord<odexine> In reply to @nlits "I am fixing that": you could make a proxy object that dispatches requests into threads and then uses the nonblocking curly procs in those threads
17:35:30FromDiscord<blashyrk> sent a code paste, see https://play.nim-lang.org/#pasty=zncaLVmo
17:36:58FromDiscord<ieltan> In reply to @nlits "The non-blocking poll for": Welp I have no clue how to solve this one sorry bud
17:37:22FromDiscord<blashyrk> (edit) "https://play.nim-lang.org/#pasty=gMMoFQMB" => "https://play.nim-lang.org/#pasty=CgsUzkcq"
17:37:33FromDiscord<ieltan> Sounds like you know what you're doing tho
17:38:07FromDiscord<odexine> In reply to @ieltan "Welp I have no": one moment i think i have something in mind
17:38:11FromDiscord<xkonti> sent a code paste, see https://play.nim-lang.org/#pasty=lQVpkWkz
17:39:22FromDiscord<ieltan> Keep in mind that the cast string doesnt add the `\0` terminator when you cast it
17:39:52FromDiscord<ieltan> (edit) "the cast string" => "it"
17:40:40FromDiscord<xkonti> In reply to @ieltan "Keep in mind that": Yeah. There should be no terminator as far as I know, as I'm just reading raw bytes, that won't ever have a terminator.
17:41:22FromDiscord<odexine> sent a code paste, see https://play.nim-lang.org/#pasty=NjIMrarg
17:41:35FromDiscord<odexine> this is very placeholdery sorry but i hope the intent isnt lost
17:42:23FromDiscord<odexine> if you dont want the type it can be global too i guess, just have a threadpool global var
17:45:25FromDiscord<odexine> my knowledge is generally asyncdispatch .. i didnt check if chronos functions similarky
17:45:54FromDiscord<ieltan> In reply to @xkonti "Yeah. There should be": If you first do str.setLen(myseq.len-1) to not count \0 before you do the cast you should not have the weird char at the end....
17:46:50FromDiscord<ieltan> It's kinda weird if it still happened after this, might be undefined behavior
17:47:39FromDiscord<ieltan> But I never had this issue with this method so... a mystery 😃
17:48:53FromDiscord<ieltan> You could do setLen after it too ig
17:50:56FromDiscord<Nlits (Ping on reply)> sent a code paste, see https://play.nim-lang.org/#pasty=JNtjzAtK
17:51:32FromDiscord<odexine> well use a threadpool instead of spawning a thread every request and it should be more reasonable
17:51:34FromDiscord<Nlits (Ping on reply)> My current setup holds a table and when a request comes in it looks up rhe corresponding future and resolves it
17:51:49FromDiscord<Nlits (Ping on reply)> Using an id
17:52:00FromDiscord<Nlits (Ping on reply)> But i will try your method if mine doesn't work
17:52:26FromDiscord<odexine> okie
18:10:40*ntat quit (Remote host closed the connection)
18:11:18*ntat joined #nim
18:24:42*beholders_eye quit (Read error: Connection reset by peer)
18:27:37FromDiscord<.bobbbob> are ref object types always dynamically allocated? also are strings dynamically allocated? is there something like a string slice that's not?
18:30:24*beholders_eye joined #nim
18:40:59FromDiscord<ieltan> In reply to @.bobbbob "are ref object types": 1. Yes↵2. strings and seq are dynamically allocated to allow growing the size at runtime↵3. `toOpenArray` is used for non allocating slices
18:43:30FromDiscord<.bobbbob> thx
18:49:53*coldfeet joined #nim
18:59:44*beholders_eye quit (Ping timeout: 260 seconds)
19:11:14FromDiscord<Nlits (Ping on reply)> Async curly achieved: https://gist.github.com/thatrandomperson5/8709ced4ff2e6ab84193725692a7dc99↵How did I do?
19:20:32FromDiscord<odexine> didnt realise theres a tag you can add
19:20:39FromDiscord<odexine> if it works it works
19:27:47*tobb joined #nim
19:46:01*ntat quit (Quit: Leaving)
19:57:29*tobb quit (Ping timeout: 260 seconds)
20:01:15*tobb joined #nim
20:07:02*tobb quit (Quit: Leaving)
20:33:27*pbsds3 quit (Quit: The Lounge - https://thelounge.chat)
20:35:38*pbsds3 joined #nim
21:13:14*pqflx3 joined #nim
21:16:22*coldfeet quit (Remote host closed the connection)
21:36:04*pqflx3 quit (Ping timeout: 260 seconds)
21:36:40*pqflx3 joined #nim
21:37:39*pqflx3 quit (Remote host closed the connection)
22:06:53FromDiscord<Robyn [She/Her]> In reply to @nlits "Async curly achieved: https://gist.github.com/thatr": oh neat
22:07:22FromDiscord<Robyn [She/Her]> i wonder if i can make it work with cps instead lmao
22:26:04FromDiscord<rasmolaxsus> So, Nim still alive
22:26:46FromDiscord<rasmolaxsus> i have been wrestling with a decision : Nim, Zig or Mojo ?
22:27:14FromDiscord<rasmolaxsus> anyone else been through that before ? if so, what resolution did you come to ?
22:31:33*wikipedia quit (Read error: Connection reset by peer)
22:34:02*lucasta joined #nim
22:53:42FromDiscord<zumi.dxy> me:↵- Mojo is here, but still not as "open" as would be expected of programming environments these days↵- Zig I've tried to break into for a bit but some things scare me a bit still at the moment (such as the language itself still being somewhat in flux)↵- Nim seems just right
23:24:20FromDiscord<swrge> In reply to @rasmolaxsus "i have been wrestling": depends on what you're planning to do ...
23:24:31FromDiscord<rasmolaxsus> In reply to @zumi.dxy "me: - Mojo is": Yeah, so far the only thing that scares me about nim, is the popularity, that is my main issue, am afraid of not being able to find stuff i search for them. Otherwise, great language.
23:24:56FromDiscord<rasmolaxsus> In reply to @swrge "depends on what you're": Prototyping game systems, and using raylib for visualization
23:25:59FromDiscord<rasmolaxsus> i want to be able to talk to the gpu's to
23:26:02FromDiscord<swrge> there's atleast some raylib content for zig and nim, mojo i dunno...
23:26:46FromDiscord<rasmolaxsus> In reply to @swrge "there's atleast some raylib": Yeah honestly, i dont know why i listed mojo, it is still in its baby stages, i guess i named it cause i come from python.
23:27:15FromDiscord<swrge> In reply to @rasmolaxsus "Yeah, so far the": well if your only criteria is popularity there's python, which is more popular than zig, nim and mojo
23:28:40FromDiscord<rasmolaxsus> In reply to @swrge "well if your only": 😅 performance is also important
23:29:22FromDiscord<swrge> In reply to @rasmolaxsus "Yeah honestly, i dont": from what i've seen from mojo the more you use their language specific features the more you stray away from the python syntax and it starts looking more like rust lol
23:30:16FromDiscord<rasmolaxsus> plus i remember craving c++ macros, in python, but they didnt have, i see nim has like 3 levels of ermmmm ..... zero abstraction code gen ... .generics -> templates -> macros ( very tempting features )
23:30:37FromDiscord<rasmolaxsus> (edit) "plus i remember craving c++ macros, in python, but they didnt have, i see nim has like 3 levels of ermmmm ..... zero ... abstraction" added "cost"
23:31:17FromDiscord<swrge> In reply to @rasmolaxsus "😅 performance is": no issues, since python libraries tend to use bindings to c code, so you'll be calling c code from python code. Nim can do the same things but it's hard to make a choice since your only criteria is popularity 😛
23:31:40FromDiscord<swrge> In reply to @rasmolaxsus "plus i remember craving": now we're talking
23:34:34FromDiscord<swrge> Both can be used for low-level, high performance programming but the difference comes down to the views of their creators and how it will affect your expenrience as a programmer. They can do the same things but imo Zig is basically the anti-thesis to Nim (very little abstractions and no hidden execution path) while Nim tries to take care of as much stuff as possible for you while giving your escape hatches (unsafe features) when you want mo
23:35:19FromDiscord<swrge> i recommend you pick the one view that appeals more to you
23:36:14FromDiscord<rasmolaxsus> Nice summary
23:36:31FromDiscord<swrge> and i promise i did it without chatgpt 😛
23:38:54FromDiscord<swrge> I find Zig makes a lot of sense as a "better C, not a better C++", afaik the only metaprogramming is conditional compilation `comptime` which is equivalent to Nim `static` and `when`, but i dont think they have anything like `macro`
23:39:26FromDiscord<leorize> zig comptime is not to be underestimated
23:39:41FromDiscord<leorize> it's features rivals what nim macros can do
23:39:59FromDiscord<swrge> well i didn't know they could manipulate ast, that's wild 😄
23:40:00FromDiscord<rasmolaxsus> In reply to @swrge "i recommend you pick": will do, i am already biased towards nim, so that is most likely where i am leaning. However how could you not like the idea of zig, what you see is what you get, nothing sneaky happening in the background you know, i wonder if that only applies to memory allocation
23:40:09FromDiscord<Elegantbeef> They cannot manipulate ast
23:40:27FromDiscord<rasmolaxsus> In reply to @swrge "well i didn't know": plus it does not look intuitive
23:40:36FromDiscord<leorize> but they can do some useful stuff even without that
23:40:45FromDiscord<swrge> In reply to @rasmolaxsus "will do, i am": you pass around allocators for memory allocation
23:40:50FromDiscord<leorize> like making types, which is tricky to get right even in nim
23:41:03FromDiscord<swrge> i like it alot
23:41:08FromDiscord<swrge> but i prefer nim
23:41:32FromDiscord<rasmolaxsus> In reply to @swrge "but i prefer nim": did nim promise the ability to choose how you want memory to be managed ?
23:41:44FromDiscord<swrge> In reply to @leorize "like making types, which": what does "making types" mean ? Like generate a new object from a macro ?
23:41:54FromDiscord<leorize> making the `type X = object` part
23:45:01FromDiscord<swrge> In reply to @rasmolaxsus "did nim promise the": You can already choose how the memory is managed, it's called the `mm` switch. If you're talking about the allocator Nim only has a global allocator and it's used transparently for every builtins types that requires heap allocation, the only way to change that is to override that hacks like `patchFile` 😦
23:45:20FromDiscord<Elegantbeef> You can just `-d:useMalloc` and not rely on patch file
23:45:43FromDiscord<swrge> then you have to override `malloc.h` ?
23:45:48FromDiscord<Elegantbeef> No
23:45:52FromDiscord<rasmolaxsus> In reply to @Elegantbeef "You can just `-d:useMalloc`": I see
23:45:55FromDiscord<Elegantbeef> You just make your own malloc dynlib
23:46:24FromDiscord<swrge> (edit) "that" => "with"
23:46:53FromDiscord<swrge> i see but it's still bad lol
23:46:54FromDiscord<Elegantbeef> On glibc linux atleast `malloc` is dynamically loaded inside glibc
23:47:15FromDiscord<Elegantbeef> It's not that bad
23:47:24FromDiscord<Elegantbeef> You can make your own colllections and data types all day long
23:48:53FromDiscord<rasmolaxsus> Amazing, you see, that is what i like about zig, before you start using it, you have to know how it behaves with memory, i feel like nim is built in a way that, you can use it and not know anything about memory allocation, i have an issue with languages trying to abstract stuff, i think there is benefit in a language that shows it's true nature up front, so that there is no surprises in the future, but I digress.
23:49:09FromDiscord<rasmolaxsus> In reply to @Elegantbeef "You can make your": I just wana use the ArenaAllocation pattern
23:50:31FromDiscord<rasmolaxsus> or its equivalent, what ever that may be in nim.
23:51:26FromDiscord<swrge> I think Nim should have a `Allocator` and `Box` api, then you can `importc` your favorite allocator and pass it in the `Box`, and then the destructors takes care of allocation and dealloc
23:53:04FromDiscord<rasmolaxsus> https://tenor.com/view/you%27re-amazing-gif-14801587834669693516
23:54:12FromDiscord<rasmolaxsus> Ok, i think i need to do some more personal research, thanks for the info @swrge @zumi.dxy @ElegantBeef @leorize
23:56:38FromDiscord<swrge> In reply to @rasmolaxsus "I just wana use": i remember seeing arena allocators libraries being advertised around here there's surely choice