<< 09-12-2025 >>
00:00:21FromDiscord<aethrvmn> owlkettle is nice for GTK↵(@.aizon)
00:00:42FromDiscord<aethrvmn> There is a person in the chat developing their own too
00:18:57*tanami quit (Ping timeout: 250 seconds)
00:44:11FromDiscord<Buckwheat> from what I know, it's a common choice for offensive tooling especially on Windows due to winim, and there were some fairly solid obfuscation libraries floating around for it↵(@rustelle)
00:44:24FromDiscord<Buckwheat> also in contrast to Python, excessive more performant
00:45:10FromDiscord<Buckwheat> also in contrast to Python, excessively more performant
01:14:54*natrys quit (Quit: natrys)
01:21:25*thunder quit (Killed (NickServ (GHOST command used by metasintactic)))
01:21:25*metasintactic joined #nim
01:34:40*SchweinDeBurg quit (Quit: WeeChat 4.8.0-dev)
01:38:47*SchweinDeBurg joined #nim
01:50:34*rockcavera quit (Remote host closed the connection)
02:12:26*xutaxkamay_ joined #nim
02:12:38*xutaxkamay quit (Ping timeout: 265 seconds)
02:13:24*xutaxkamay_ is now known as xutaxkamay
02:30:53*tanami joined #nim
05:09:37FromDiscord<mjsdev> And terrible at HTML/XML
05:23:21*metasintactic quit (Quit: Leaving)
06:24:38FromDiscord<Chebudumpling Temper> In reply to @rustelle "What about V lang": C language for dev who doesnt like C-syntax
06:28:18FromDiscord<Chebudumpling Temper> In reply to @kawaiiselbst "C language for dev": I don't try it, so i don't know who realy need that. But if its compiler less annoing than zig's one, i think it have rights to live
06:28:36FromDiscord<Chebudumpling Temper> (edit) "realy" => "really" | "that." => "yet another C, that not C."
06:47:35Amun-Rathe most annoying thing with zig compiler is building it (the same common denominator of all llvm based programs)
07:52:06FromDiscord<ieltan> sent a long message, see https://pasty.ee/cHBEMkmU
07:53:09FromDiscord<ieltan> Nim may be familiar to you if you're used to python syntax wise so it's a plus
07:53:47FromDiscord<ieltan> Nim compiles to C so you can write extensions that have a C api exposed
07:54:30FromDiscord<ieltan> I can go on and on but at the end of the day I think the only one to make the best judgement is yourself
07:55:43FromDiscord<Buckwheat> > "\>except straight up C↵> ↵only lie you told but that's pulling hairs
07:55:48FromDiscord<Buckwheat> everything else is true however
07:57:37FromDiscord<Buckwheat> but also Nim has some solid C interop through Futhark, though there's still growing pains with it (but I personally do Nim/C interop with it)
07:58:15FromDiscord<Buckwheat> but also Nim has some solid C interop through Futhark, though there's still growing pains with it (but I personally do Nim/C interop with it and have a proof of concept for Nim/Assembly interop with it)
08:04:28FromDiscord<ieltan> sent a long message, see https://pasty.ee/rgqXGkxL
08:05:00FromDiscord<ieltan> (edit) "https://pasty.ee/rqAYDFvG" => "https://pasty.ee/yvcdLLSV"
08:06:06FromDiscord<ieltan> One obvious thing is that most of the c standard library is straight up too unsafe to use, will fail in silence and blow up later, etc
08:06:37FromDiscord<ieltan> So to use C you have to essentially write a "standard library" yourself, so fun!
08:06:44FromDiscord<Chebudumpling Temper> In reply to @Amun-Ra "the most annoying thing": Building zig compiler itself?
08:07:41FromDiscord<Buckwheat> everyone does have their own convention, yeah, and that can cause problems. though at the same time, taking the time to read these standards is still probably a good thing too. and yeah, there are a lot of unsafe things in the standard library, and you need to make sure you know which ones are dangerous and how you can make them dangerous. at the same time, whether we like it or not, to do any sort of cybersec stuff, gotta know C (and s
08:07:41FromDiscord<Buckwheat> if you're doing reversing or exploit stuffs
08:07:55FromDiscord<Buckwheat> but, if you can write some solid C/Assembly for offensive tooling that you can then write Nim bindings for, now you just made your life easier every time you gotta build something
08:08:20FromDiscord<Buckwheat> [Edit](https://discord.com/channels/371759389889003530/371759389889003532/1447862251959750706): if you're doing reversing or exploit stuffs. you really can't have any abstraction there, and C is one of the closest to the hardware still.
08:10:47Amun-RaChebudumpling Temper: yes
08:11:31FromDiscord<Buckwheat> "ah I gotta do this... hey at least I made this library for myself so I don't gotta write all that low-level stuff again!"
08:12:50FromDiscord<ieltan> In reply to @Buckwheat "[Edit](https://discord.com/channels/371759389889003": This myth of "you can't do anything if you're not close to the metal, like C!" needs to actually die. I agree that low level languages are important to understand the fundamentals but they are in no way "needed" unless you want high performance or need to expose a api for other languages. For example angr is a state of the art scriptable reverse engineering pla
08:14:08FromDiscord<ieltan> It would have been better if it was made in Nim though, I don't think the creators of angr knows about this 🙂
08:15:17FromDiscord<ieltan> Also one good point I can give to python is that it's so slow it force the need to care for your data structures and asymptomatic performance
08:16:24FromDiscord<ieltan> It means you don't just get to bruteforce a problem with compute, you need to actually think about the algorithms and data structures used to improve anything and this ports to any language including Nim
08:30:19*redj quit (Ping timeout: 264 seconds)
08:30:45*redj joined #nim
11:22:30*CypherCat quit (Changing host)
11:22:30*CypherCat joined #nim
13:08:25*beholders_eye joined #nim
13:13:55FromDiscord<kapendev> Yeah. Algorithmic complexity often will trump optimizations and interpretation speed.
13:14:15FromDiscord<kapendev> But Python bad. And I am biased.
14:11:04FromDiscord<nervecenter> In reply to @Buckwheat "but also Nim has": You definitely don't need Futhark for interop when the surface of C code you're calling is small enough. It easy to write a few FFI procs.
14:16:33FromDiscord<nervecenter> Nim's innovation is that it achieves a maximum of expression with a minimum of cost. Most programs will only ever pay for runtime bounds checking. With scope-managed data by default, you're getting "best-practices modern C++" performance without having to do all the twisting and contorting best-practices modern C++ requires you to do to get it. I think the Nim website front page does a good job of demonstrating that.
14:18:45FromDiscord<nervecenter> Python is "slow" because every piece of data is wrapped in an object full of information that is checked every time you do anything with it. In the typical case you're talking a 100x slowdown over Nim binaries.
14:22:52FromDiscord<nervecenter> Python has significant performance costs everywhere. It's dynamic, so types are checked at runtime. To do that, every piece of data is contained in a heap-allocated object, and every data structure is a variant of a linked list. In the typical case, this all adds up to a 100x slowdown over a native binary like Nim.
14:23:21FromDiscord<nervecenter> (edit) "is a variant of" => "uses links like"
14:24:15FromDiscord<nervecenter> (edit) "every" => "most"
14:25:19FromDiscord<nervecenter> Python has significant performance costs everywhere. It's dynamic, so types are checked at runtime. To do that, every piece of data is contained in a heap-allocated object, and data structure often use links like a linked list. In the typical case, this all adds up to a 100x slowdown over a native binary like Nim.
14:25:27FromDiscord<nervecenter> (edit) "structure" => "structures"
14:31:48FromDiscord<nervecenter> I specifically could not make Python work for my use case at work for that reason. Nim had the expressiveness and development speed I needed, while having native performance with very little cost. Making the tool I made in C++ or C would be torture.
16:05:52FromDiscord<kapendev> Well, best practice is subjective. Would be nice if more C++ people used arena allocators instead of allocating randomly.
16:18:50FromDiscord<Buckwheat> you don't, but it's the solution that feels nicest↵(@nervecenter)
16:19:01FromDiscord<Buckwheat> sorry, I disagree with Araq regarding that
16:21:26FromDiscord<Buckwheat> I definitely have done past projects where I wrote a lot of C and wanted higher-level bindings and the Futhark-style approach is how I did it with other languages
16:28:48FromDiscord<Buckwheat> [Edit](https://discord.com/channels/371759389889003530/371759389889003532/1447985854000791574): you don't, but it's the solution that feels nicest to me personally
16:52:57FromDiscord<user2m> Hey guys I'm working on a framework built on top of pixie to programatically genearte visuals for social media, but the speed of actually rendering / testing examples is slowing me down. All the rendering is being done on the CPU - is there any way to offload this to the GPU?↵↵I read something about boxy, but I'm not sure if that would help render speeds
16:53:23FromDiscord<user2m> (edit) "speeds" => "speeds."
16:54:14FromDiscord<user2m> (edit) "Hey guys I'm working on" => "sent" | "framework built on top of pixie to programatically genearte visuals for social media, but the speed of actually rendering / testing examples is slowing me down. All the rendering is being done on the CPU - is there any way to offload this to the GPU?↵↵I read something about boxy, but I'm not sure if that would help render speeds." => "long message, see https://pasty.ee/fHQqhVNn"
17:29:26*xet7 joined #nim
17:29:52FromDiscord<saint._._.> In reply to @mjsdev "And terrible at HTML/XML": What is terrible at html/xml?
17:30:30FromDiscord<mjsdev> It was a joke about the two parsers.
17:31:26FromDiscord<mjsdev> Converting entities to single character text nodes, parsing HTML within <script> tags in the html parser
17:31:27FromDiscord<saint._._.> In reply to @user2m "Hey guys I'm working": Would this have to do with nim?
17:31:39FromDiscord<saint._._.> In reply to @mjsdev "Converting entities to single": Oh I think I get it
17:32:09FromDiscord<mjsdev> There's just a bunch of hacks you need to do to make them usable
17:34:44FromDiscord<saint._._.> I thought you were mentioning that nim doesn't do it well
17:34:52FromDiscord<mjsdev> Yeah, nim doesn't do it well
17:34:55FromDiscord<saint._._.> I was writing a binding lib for libxml fir nim
17:34:58FromDiscord<saint._._.> (edit) "fir" => "for"
17:35:06FromDiscord<saint._._.> cause yeah the std xml thing doesn't work that good
17:35:20FromDiscord<mjsdev> libxml (in my experience) is also pretty terrible?
17:35:34FromDiscord<saint._._.> Works for what I need it to do
17:35:50FromDiscord<saint._._.> The weird thing that I encountered was using the html parsrer for xml
17:36:08FromDiscord<mjsdev> I've worked with that on PHP side where the xml extension uses it, similar situation, so much so I think I ended up switching to a fully PHP written parser.
17:36:11FromDiscord<saint._._.> And it mostly was working except there was some weird behavior and then I realized it was cause I was using the html parser
17:36:30FromDiscord<mjsdev> Which was obviously slower...
17:36:31FromDiscord<saint._._.> In reply to @mjsdev "I've worked with that": Interesting well I think the ruby xml parser uses libxml2 and I think the python one
17:36:35FromDiscord<saint._._.> Like the main libraries not native
17:36:36FromDiscord<mjsdev> but worth not fighting it
17:36:44FromDiscord<saint._._.> I think nokogiri for ruby and beautifulsoup for python
17:37:06FromDiscord<mjsdev> Nim has a lower level parser which I'll probably write something on top of eventually
17:37:10FromDiscord<saint._._.> the nim is missing some important features for children or something
17:37:17FromDiscord<mjsdev> It's basically a tokenizer
17:37:18FromDiscord<saint._._.> It's not low level enough
17:37:30FromDiscord<saint._._.> If I remember correctly
17:37:40FromDiscord<mjsdev> There's htmlparser, xmlparser, and parsexml
17:37:43FromDiscord<mjsdev> and xmltree of course
17:37:50FromDiscord<saint._._.> All of them I believe
17:38:01FromDiscord<mjsdev> parsexml is the low level, which is basically a tokenizer that htmlparser and xmlparser sit on top of and create nodes with xmltree
17:38:20FromDiscord<mjsdev> the parsexml, as it's pretty much just a tokenizer, seemed OK to me.
17:39:05FromDiscord<mjsdev> It's the two that sit on top that just do weird things. xmltree is OK, if not way too simple.
17:39:26FromDiscord<saint._._.> Right
17:39:39FromDiscord<mjsdev> Been working with it all here:↵↵https://github.com/primd-cooperative/mininim-web/blob/main/src/mininim/templates.nim
17:40:06FromDiscord<saint._._.> Oh nice
17:40:21FromDiscord<saint._._.> minimin is really complex when I was looking at it
17:40:34FromDiscord<saint._._.> Like a very general type of thing, not really just a web stack right?
17:40:41FromDiscord<mjsdev> complex in which way?
17:41:00FromDiscord<mjsdev> It's very general right now, yes, but the web pieces are a major component
17:42:09FromDiscord<mjsdev> I'd say mininim itself is fairly complex... the aim is to make the code you write easier
17:43:37FromDiscord<mjsdev> Like if you need to add a middleware -- here's a pretty simple example of one:↵↵https://github.com/primd-cooperative/mininim-web/blob/main/src/mininim/mdlw/public404.nim
17:48:38FromDiscord<user2m> In reply to @saint._._. "Would this have to": ? pixie is a nim lib
17:51:05FromDiscord<saint._._.> In reply to @user2m "? pixie is a": Ohh
17:51:42FromDiscord<saint._._.> Do you have a link? @user2m
17:52:39FromDiscord<saint._._.> In reply to @mjsdev "Like if you need": Gotcha nice
17:56:00FromDiscord<user2m> In reply to @saint._._. "Ohh": https://github.com/treeform/pixie it's another lib from the goat @treeform
18:09:08FromDiscord<saint._._.> In reply to @user2m "https://github.com/treeform/pixie it's another lib": Oh this is awesome
18:58:12*xet7_ joined #nim
18:58:35*xet7_ quit (Client Quit)
21:46:52*rockcavera joined #nim
22:07:26FromDiscord<gee.wzz> sent a code paste, see https://play.nim-lang.org/#pasty=CwUtLdPZ
22:08:19FromDiscord<gee.wzz> (edit) "https://play.nim-lang.org/#pasty=avqZSKSk" => "https://play.nim-lang.org/#pasty=ltPcFGax"
23:00:34*xet7 quit (Remote host closed the connection)
23:06:05*rockcavera quit (Remote host closed the connection)
23:16:55*zero`_ joined #nim
23:18:28*rockcavera joined #nim
23:19:44*zero` quit (Ping timeout: 240 seconds)
23:35:10*zero` joined #nim
23:38:07*zero`_ quit (Ping timeout: 240 seconds)
23:41:38*beholders_eye quit (Quit: WeeChat 4.7.2)