<< 20-01-2025 >>
01:16:04*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)
01:25:10*krux02 quit (Remote host closed the connection)
01:49:05*beholders_eye quit (Ping timeout: 248 seconds)
02:28:52*rockcavera joined #nim
02:45:51*SchweinDeBurg joined #nim
03:19:10*tiorock joined #nim
03:19:10*tiorock quit (Changing host)
03:19:10*tiorock joined #nim
03:19:10*rockcavera quit (Killed (tantalum.libera.chat (Nickname regained by services)))
03:19:10*tiorock is now known as rockcavera
04:01:51*xet7 quit (Remote host closed the connection)
04:03:59*rockcavera quit (Remote host closed the connection)
06:36:08*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
06:40:34*Lord_Nightmare joined #nim
07:50:18FromDiscord<peachey2k2> In reply to @Amun-Ra "peachey2k2: int64 will be": yup that does it
07:50:35FromDiscord<peachey2k2> thank you so much
08:12:15*ntat joined #nim
09:41:45Amun-Rapeachey2k2: mind that anything that goes above the limit is going to give you interesting results
09:42:25Amun-RaJS switches the type to float in that case, Nim code will end up not as you'd like
09:42:47Amun-RaI'd keep the switch on and convert to uint32 on nim side
10:34:26FromDiscord<ravinder387> i can't able to install nim in windows
10:35:22FromDiscord<ravinder387> I'm using nim in wsl since 6 month what should i do
10:35:39FromDiscord<nnsee> what do you mean exactly? what error are you getting?
10:38:07*ensyde joined #nim
10:38:11FromDiscord<ravinder387> In reply to @nnsee "what do you mean": https://media.discordapp.net/attachments/371759389889003532/1330848846695370763/Screenshot_7.png?ex=678f7913&is=678e2793&hm=29d2a0bdecda3237d48f86446d1b736061bd8f9464d41f02ca9d2ecfda19cf4f&
10:38:57FromDiscord<nnsee> what antivirus product are you using?
10:39:20FromDiscord<nnsee> you should add an exception for the zip. it's a false positive
10:39:47FromDiscord<ayex> ..if the sha matches..
10:39:55FromDiscord<ravinder387> how to add exception for zip
10:40:14FromDiscord<nnsee> In reply to @ravinder387 "how to add exception": well if you don't tell me what antivirus product you're using, i can't tell you
10:40:43FromDiscord<ravinder387> I don't hv any antivirus. it's default window defender
10:41:19FromDiscord<ravinder387> i disabled everything but still i get this error
10:41:27FromDiscord<nnsee> then you go into defender settings. there should be a list of recently detected threats with the zip in them. you have to select "Allow" on the zip, instead of "quarantine" or whatever it's selected
10:42:19FromDiscord<nnsee> either that or you add `C:\Users\[your username]\Downloads\nim-2.2.0_x64.zip` to exceptions manually
10:45:11FromDiscord<ravinder387> In reply to @nnsee "then you go into": do u mean i should off realtime protection https://media.discordapp.net/attachments/371759389889003532/1330850605035683842/Screenshot_8.png?ex=678f7ab6&is=678e2936&hm=56f19ec74f1da3cff7aa10b3b3464a2cbcd6488c433f5c1c71c408665f7169ef&
10:45:37FromDiscord<ravinder387> i hv done it it don't work
10:48:00Amun-RaI wonder whether self-signing exe helps
10:48:47FromDiscord<nnsee> In reply to @ravinder387 "do u mean i": no, that's not what I'm saying
10:49:17FromDiscord<nnsee> please google "how to add exception in windows defender"
10:51:33*beholders_eye joined #nim
11:06:39*beholders_eye quit (Ping timeout: 272 seconds)
11:11:20FromDiscord<peachey2k2> In reply to @Amun-Ra "I'd keep the switch": but i can't do that because some webgl stuff in the bindings are typed for 64 bit ints
11:11:52FromDiscord<peachey2k2> i doubt i'll have 2^52 vertices tho so it's not a big deal
11:11:57Amun-Raright
11:12:06Amun-RaI see
11:24:26*beholders_eye joined #nim
11:29:20FromDiscord<pmunch> How can you compare two symbols?
11:30:40FromDiscord<pmunch> I have a `Sym "string"` from a proc definition and another `Sym "string"` from a call to `getTypeImpl` but the normal `==` compare doesn't match
11:32:42Amun-Rahmm, would $x == $y work?
11:33:04Amun-RaI alway try these things as I type (macros)
11:33:27Amun-Ragive me two weeks and I'll forget ast details
12:04:44FromDiscord<pmunch> That's ugly though..
12:05:09FromDiscord<pmunch> Figured out that `sameType` was a thing 🙂
12:06:14FromDiscord<pmunch> Hmm, the `treeRepr` for `varargs[string]` and `varargs[string, $]` is identical
12:09:29FromDiscord<solitudesf> In reply to @pmunch "Hmm, the `treeRepr` for": not on my machine
12:19:10*xaltsc quit (Quit: WeeChat 4.5.1)
12:22:51FromDiscord<pmunch> Really?
12:26:07FromDiscord<solitudesf> sent a code paste, see https://play.nim-lang.org/#pasty=QutPLXbA
12:27:39FromDiscord<solitudesf> with typed macro too, just varargs and string are `Sym`
12:33:07*beholders_eye quit (Ping timeout: 264 seconds)
12:47:14*beholders_eye joined #nim
12:49:27FromDiscord<pmunch> Hmm
12:56:17*krux02 joined #nim
13:34:02FromDiscord<peachey2k2> In reply to @Amun-Ra "give me two weeks": you can forget anything in 2 weeks
13:36:26FromDiscord<jseb> sent a code paste, see https://play.nim-lang.org/#pasty=nhWiBsLQ
13:37:40FromDiscord<solitudesf> nimble install nimble
13:38:37FromDiscord<jseb> ah it's `install` now, thank you
13:38:48*ensyde quit (Ping timeout: 276 seconds)
13:41:19FromDiscord<jseb> « faild to clone vendor/zippy »
13:41:44FromDiscord<jseb> (edit) "»" => "»↵same error than yesterday, though i've all reinstalled from scratch following the manual"
13:43:03FromDiscord<jseb> (edit) "« faild to clone vendor/zippy »↵same error than yesterday, though i've all reinstalled from scratch following the manual" => "sent a code paste, see https://play.nim-lang.org/#pasty=iyoQLREM"
14:01:39FromDiscord<Clonkk>
14:02:21FromDiscord<Clonkk> In reply to @.sneakybaguette "": Replying you here to avoid spamming the other channel. Yes, Nim can replace C in the sense that everything you can do with C, you can do with Nim - including using other C library (like firmware / driver)
14:03:25FromDiscord<Clonkk> For example, I once wrote binding to the C library of some user-space Linux driver, and then made a higher level, nicer to use Nim API
14:03:55FromDiscord<Clonkk> Alternative to C, usually means "you can use C library, you can do everything C can do, and you can target the same HW architecture as C"
14:04:14FromDiscord<zimzozaur> In reply to @.sneakybaguette "Replying you here to": You replace the 2nd layer of abstraction the language to do the thing but you do not change the eco this way right (like C based Linux instead of Unikernel in Odin for example)?
14:04:59FromDiscord<zimzozaur> (edit) "instead of" => "to"
14:06:19FromDiscord<Clonkk> From C file (.c / .so / .a + .h usually), you derive C function in Nim using `importc` . Then you can handle those C style function better in Nim. For example, C function that require a `char` , `len` pair you can easily create a Nim function that takes `string` as input and from that string passes a `mystr.cstring, mystr.len`
14:06:47FromDiscord<Clonkk> There's library like [Futhark](https://github.com/PMunch/futhark) that can do that automatically
14:09:28FromDiscord<Clonkk> Another example, can be for error handling. C-style error handling will usually be : passing the output argument as mutable parameters and returning an int from the function. Then checking the returned value against a table of error message (`errno` style). This is extremely verbose and non-intuitive and that's something you can easily change with Nim; a simple template can convert a C-error into an exception
14:09:52FromDiscord<Clonkk> Or if you know what the C library is doing, you can re-implement it natively in Nim 🙂
14:10:01FromDiscord<zimzozaur> In reply to @.sneakybaguette "From C file (.c": Hmmm it sounds interesting. Do you import C for convince or/and performance?
14:10:11FromDiscord<Clonkk> For convenience mostly
14:11:04FromDiscord<Clonkk> The perf in difference between naive C and naive Nim is at best negligible (although it's easier to write better code in Nim than in C IMO). Optimised Nim will run just as fast as optimised C assuming same level of optimisation
14:11:22FromDiscord<Clonkk> (edit) "(although" => "(sometimes even in favor of Nim since"
14:14:06FromDiscord<Clonkk> Also there's no need to re-write from scratch fundational C library who have had decade of work and battle-tested
14:14:17FromDiscord<Clonkk> (edit) "Also there's no need to re-write from scratch fundational C library who have had decade of work and ... battle-tested" added "are"
14:15:33FromDiscord<zimzozaur> How about use cases. I am for now only a Humble Python Intern. Learning ASM and C (I am at the beginning) but wanted to learn something niche and new but fast (I believe thing should be fast by default) and Nim sounded very very intriguing that looks like Python, but is much faster and allows you to play with memory to make it even faster. But I don’t found much on Internet which means it is really niche and I didn’t hear about use
14:16:36FromDiscord<zimzozaur> In reply to @.sneakybaguette "Also there's no need": Right! It is a little like with Power Plants in Fortran. Why would you update if it works.
14:19:07FromDiscord<Clonkk> sent a long message, see https://pasty.ee/tEPzAEaE
14:19:40FromDiscord<Clonkk> To interact with python there's an excellent bindings to libpython : https://github.com/yglukhov/nimpy
14:20:23FromDiscord<Clonkk> We actually wrote a guide a while ago about using Python and Julia from Nim to extend the ecosysten https://scinim.github.io/getting-started/external_language_integration/index.html
14:20:40FromDiscord<Clonkk> For ML, the most important Nim library would be https://github.com/mratsim/Arraymancer
14:20:57FromDiscord<Clonkk> (edit) "ML," => "ML or numerical computation,"
14:21:29FromDiscord<zimzozaur> How about backend. How would you compare Nim to Go?
14:21:29FromDiscord<Clonkk> For backend stuff I'd probably start with Happyxhttps://github.com/HapticX/happyx
14:21:31FromDiscord<nervecenter> For data frames there's https://github.com/SciNim/Datamancer which is pretty fantastic
14:21:54FromDiscord<Clonkk> Yeah @vindaar has done an excellent work as a dataframe library with that 🙂
14:22:08FromDiscord<Clonkk> Favorite ORM in Nim is https://github.com/moigagoo/norm
14:22:34FromDiscord<Clonkk> I think lots of people have used https://github.com/planety/prologue as well
14:22:42FromDiscord<Clonkk> (edit) "I think lots of people have used https://github.com/planety/prologue as well ... " added "for backend"
14:25:09FromDiscord<Clonkk> sent a long message, see https://pasty.ee/KfmcMqBI
14:26:59FromDiscord<Clonkk> There's nothing you can do in Go you can't do in Nim. There's lots of things you can do in Nim you CAN'T do in Go. ↵BUT you may find Go has libraries that don't exists in Nim (especially if you're looking into ops stuff or database drivers)
14:28:25FromDiscord<zimzozaur> @Clonkk thank you for all your input. Now I have to digest it 😊
14:30:43FromDiscord<Clonkk> My overall opinion is that Nim is worth learning, and it's nice enough to work with (especially with the recent improvement on tooling and the work of @jmgomez ). That said, it all depend on the environment you're in (are you working for a big company ? Is it a personnal project ?) and the goal you have
14:31:50FromDiscord<Clonkk> If all you want is "faster python" you could also look into alternative Python compiler (either using JIT like Numba or through "Python-compatible" language like Mojo or Codon are doing)
14:43:11FromDiscord<ravinder387> i successfully extract nim-2.2.0 but when i tried to run finish.exe window remove this file https://media.discordapp.net/attachments/371759389889003532/1330910500027891722/Screenshot_9.png?ex=678fb27e&is=678e60fe&hm=13321f63d719b724b649b6b44a3b7daa00e5f1b4bb3c199e25a10da3339c43e5&
14:43:35FromDiscord<ravinder387> do i need to again install nim in windows
14:44:19FromDiscord<jseb> there is still the AV problem with nim in windows ? I thought it was history
14:49:57FromDiscord<peachey2k2> wait you can just use |block:` as an expression?
14:50:04FromDiscord<peachey2k2> (edit) "|block:`" => "`block:`"
14:50:25FromDiscord<lainlaylie> https://nim-lang.github.io/Nim/manual.html#statements-and-expressions-block-expression
14:50:54FromDiscord<lainlaylie> In reply to @ravinder387 "i successfully extract nim-2.2.0": windows doesnt like finish.exe but it's not difficult to do what it does manually
15:01:18FromDiscord<peachey2k2> In reply to @lainlaylie "https://nim-lang.github.io/Nim/manual.html#statemen": yeah cool shit
16:16:12*fallback joined #nim
17:21:41*beholders_eye quit (Quit: WeeChat 4.1.2)
17:23:16FromDiscord<michael.lenz.> @zimzozaur as far as I know nim directly generates js code.
17:33:29FromDiscord<michael.lenz.> So to compile directly into machine code, you needed your own assembler, compiler, and linker. What's a bit difficult to create a piece of software
17:38:16FromDiscord<michael.lenz.> Having an intermediate translation to C gives ability to utilize top optimizations that clang and gcc has. Most operating systems are also written in C/C++.
17:39:19FromDiscord<muddmaker> It also lets nim support all of the CPU architectures that have C compilers without needing to implement all of that as part of the project
17:40:07FromDiscord<muddmaker> Which is all of them (except for m88k, which GCC dropped support for in v4, therefore is too old for nim's c generator)
17:40:42FromDiscord<muddmaker> (edit) "Which is all of them ... (except" added "that are supported by modern operating systems"
17:45:33FromDiscord<solitudesf> also allows for source level interop, which can matter if you're using a cpp library.
17:47:12*beholders_eye joined #nim
17:48:12FromDiscord<muddmaker> Also true for macro heavy C libraries
17:51:23FromDiscord<lainlaylie> what even are the benefits of going straight to binary? one fewer dependency?
17:52:04FromDiscord<muddmaker> You could say "one" fewer dependency, but it is a giant complex dependency
17:52:49FromDiscord<muddmaker> And it would also be faster to compile if nim didn't need to first translate to C and invoke a C compiler
17:52:59FromDiscord<muddmaker> Getting good debug symbols might also be easier
17:53:15FromDiscord<muddmaker> But is it worth it? Probably not
17:53:18FromDiscord<Robyn [She/Her]> In reply to @lainlaylie "what even are the": You could say optimisations specific to your language? Though that's with LLVM IR backing you, if you wanna go directly to ASM it'll probably be a lot more work on your part
17:54:12FromDiscord<Robyn [She/Her]> Even going to LLVM is some effort and it's still another dependency you gotta ship with the compiler, a rather large one at that
17:54:37FromDiscord<Robyn [She/Her]> Though there is a LLVM compiler backend at https://github.com/arnetheduck/nlvm
17:55:33FromDiscord<muddmaker> And if you chain yourself to LLVM, then you also need to track LLVM's development cycle and are also limited to LLVM's architectures
17:56:17FromDiscord<muddmaker> Which is what happened to zig, for example
17:56:47FromDiscord<Robyn [She/Her]> Yeah, which is why they've been working on their own compiler IR for a while now, right?
17:56:52FromDiscord<muddmaker> Yeah
17:57:04FromDiscord<muddmaker> But that's a _huge_ effort, but it may pay off
17:57:22FromDiscord<Robyn [She/Her]> mhm for sure
17:57:46FromDiscord<muddmaker> If it does, and they are able to support every arch that people care about, maybe a Nim->Zig set up can be made...
17:57:54FromDiscord<lainlaylie> we will watch with interest but to me it looks very reinventingthewheel-y
17:57:58FromDiscord<Robyn [She/Her]> Though they still do need to maintain their LLVM stuff because of the easy interop with C
17:58:09FromDiscord<muddmaker> I think they are making a C compiler as well
17:58:21FromDiscord<Robyn [She/Her]> In reply to @muddmaker "I think they are": Jeez, really? Good luck to them
17:58:24FromDiscord<Robyn [She/Her]> In reply to @lainlaylie "we will watch with": Fair
17:58:27FromDiscord<muddmaker> C isn't _that_ hard
17:58:35FromDiscord<muddmaker> C++ is _way_ harder
17:58:38Amun-Rathere's no need to dig into llvm if the target you'd like to port nim code to can be adopted to posix; I ported my nim code to good old AmigaOS
17:58:41FromDiscord<Robyn [She/Her]> Doesn't Rust support Cranelift for debug builds now? Or is that a fantasy thing
17:59:11FromDiscord<muddmaker> Yeah, they have some support for Cranelift, and it's faster than LLVM, but far more limited in hardware support
17:59:11FromDiscord<Robyn [She/Her]> (edit) "Doesn't Rust support Cranelift for debug builds now? Or is that a fantasy thing ... " added "I had"
17:59:44FromDiscord<Robyn [She/Her]> Yeah, but I'd say the benefit of rapid debug builds outweigh it, especially since it's still pretty fast despite having less optimisations as LLVM
17:59:51FromDiscord<Robyn [She/Her]> (edit) "as LLVM" => "than /LVM"
17:59:54FromDiscord<Robyn [She/Her]> (edit) "/LVM" => "LLVM"
18:00:42FromDiscord<muddmaker> For sure
18:01:05FromDiscord<Robyn [She/Her]> Araq did look into a Cranelift backend for NIF briefly but quickly dumped it because of no decent ASM format
18:01:16FromDiscord<Robyn [She/Her]> And it'd be a time sink to work on that too
18:01:25FromDiscord<muddmaker> I thought it was because of a lack of documentation
18:01:30FromDiscord<Robyn [She/Her]> this was a while ago in #internals
18:01:33FromDiscord<Robyn [She/Her]> In reply to @muddmaker "I thought it was": that too
18:05:47FromDiscord<michael.lenz.> In reply to @muddmaker "I think they are": Who? Zig team?
18:06:15FromDiscord<muddmaker> In reply to @michael.lenz. "Who? Zig team?": Here: <https://github.com/ziglang/zig/tree/master/lib/compiler/aro>
18:07:01FromDiscord<lainlaylie> must be nice having the hype and the people-hours that come with it on your side
18:07:15FromDiscord<Robyn [She/Her]> yeahh
18:08:51FromDiscord<michael.lenz.> Crazy, translate to zig to have llvm again?
18:09:14FromDiscord<muddmaker> Zig has an LLVM backend, but they are also trying to make their own code gen backend that doesn't require it
18:09:29FromDiscord<michael.lenz.> Ah, ok
18:09:34FromDiscord<muddmaker> Along with a complete toolchain down to the low level, e.g. a linker and the like
18:10:09FromDiscord<Robyn [She/Her]> In reply to @muddmaker "Along with a complete": huh, why their own linker?
18:10:14FromDiscord<muddmaker> They want incremental linking
18:10:21FromDiscord<muddmaker> Hot reloading for native code
18:10:22FromDiscord<michael.lenz.> Sounds like scifi
18:10:31FromDiscord<Robyn [She/Her]> In reply to @muddmaker "They want incremental linking": linkers don't have that stuff?
18:10:38FromDiscord<michael.lenz.> Do they have huge team?
18:10:51FromDiscord<muddmaker> I think it was just 1 or 2 guys that were working on the linker part of it
18:10:54FromDiscord<Robyn [She/Her]> In reply to @muddmaker "Hot reloading for native": huh...
18:11:10FromDiscord<muddmaker> It's a large group of people for the complete project, but people can find their own niches
18:11:36FromDiscord<Robyn [She/Her]> In reply to @muddmaker "I think it was": focus will probably be adjusted once other crucial parts are closer to a complete implementation
18:12:02FromDiscord<michael.lenz.> Its not like a kernel or os userspace apps development. Way too complicated
18:12:05FromDiscord<muddmaker> It's nothing we couldn't use for inspiration either. It's all MIT licensed
18:12:26FromDiscord<muddmaker> <https://github.com/ziglang/zig/tree/master/src/link>
18:12:52FromDiscord<Robyn [She/Her]> In reply to @muddmaker "It's nothing we couldn't": that's true, maybe someone will work on a pure Nim C compiler and linker, but certainly not me
18:13:05*xaltsc joined #nim
18:13:30FromDiscord<muddmaker> There was already a little interest in nimony, with preasm + direct asm generation (with no optimizations) as part of nifc
18:13:37FromDiscord<michael.lenz.> There’s no need to have own compiler toolchain. Even intel uses clang
18:13:55FromDiscord<muddmaker> It's not about needs, but wants
18:17:00FromDiscord<Robyn [She/Her]> honestly if i ever manage to make my own language, I'm probably jumping off of the Nim train for that
18:17:21FromDiscord<Robyn [She/Her]> Since I'd get to customise it to my heart's content since I'd be familiar with the internals
18:17:38FromDiscord<Robyn [She/Her]> Nim is a great language but some features it lacks that macros can't fill
18:18:20FromDiscord<Robyn [She/Her]> Or some tasks just feel too big for someone like me to take the time to properly dive into (I did wanna make a JVM backend, probably revisiting the idea once NIF lands)
18:20:02FromDiscord<muddmaker> I think for now, focusing on nimony is a good thing for the nim team
18:20:40FromDiscord<muddmaker> Building a nim-native "lower end" of the compiler toolchain could be a nice to have, but it is not a must have, for the language
18:20:43FromDiscord<Robyn [She/Her]> yeah, gives a chance to work with a fresh codebase without legacy cruft
18:21:32FromDiscord<nervecenter> So much of this work has already been done to an extensive level by existing compiler toolchains, you'd need a really good justification to reinvent a very very refined wheel
18:22:15FromDiscord<nervecenter> Most complaints about compiler backends I've seen concern C++ binary output
18:22:31Amun-Rarolling your own language nowadays is just like rolling your own crypto
18:25:46FromDiscord<zimzozaur> In reply to @muddmaker "And it would also": I listened to one cppcon talk where a guy from Google said that there were compiling one file from dozens of them for 15 min each. Jonathan Blow was saying that completion times are important for him when desiging Jai.
18:27:19FromDiscord<zimzozaur> In reply to @muddmaker "And if you chain": GingerBill was complaining about it and saying that you shouldn't use LLVM.
18:27:47FromDiscord<michael.lenz.> And what they use? Gcc?
18:27:55FromDiscord<muddmaker> Yeah, LLVM is very sophisticated, but it also sucks to actually use
18:28:32FromDiscord<muddmaker> In reply to @michael.lenz. "And what they use?": Odin uses LLVM
18:28:58FromDiscord<zimzozaur> In reply to @muddmaker "Odin uses LLVM": Aren't they moving to their own compiler?
18:29:14FromDiscord<muddmaker> I don't follow its development close enough to know. Maybe?
18:34:15FromDiscord<zimzozaur> In reply to @muddmaker "There was already a": Is it not common to look at ASM that Nim produces?
18:35:03FromDiscord<zimzozaur> In reply to @battery.acid.bubblegum "Nim is a great": What does it lacks?
18:35:14FromDiscord<muddmaker> IIRC, that was an experiment of Araq's that he was trying to demonstrate for nimcon
18:35:35FromDiscord<muddmaker> It hasn't really been maintained since
18:36:21*mengu1 joined #nim
18:36:23FromDiscord<bostonboston> In reply to @zimzozaur "Is it not common": Not that I've heard of
18:36:36FromDiscord<muddmaker> But also, this is in _nimony_, not _nim_, which is a highly WIP compiler rewrite
18:36:54FromDiscord<muddmaker> I don't know if the current nim implementation even does direct ASM generation
18:37:48FromDiscord<nervecenter> In reply to @muddmaker "I don't know if": It does not
18:38:00Amun-Raall these third party implementations will be lost like tears in rain
18:38:12FromDiscord<zimzozaur> In reply to @nervecenter "It does not": Sad
18:38:18FromDiscord<muddmaker> In reply to @Amun-Ra "all these third party": ?
18:38:34FromDiscord<bostonboston> In reply to @zimzozaur "Sad": Why
18:38:55FromDiscord<nervecenter> In reply to @zimzozaur "Sad": Like I said in #internals, that's extraordinarily difficult, and gcc and llvm have decades and millions of man-hours invested into doing that already
18:39:26FromDiscord<zimzozaur> In reply to @bostonboston "Why": I like to see ASM. Recently, I started learning ASM and C. In CLion you can easily go through ASM and learn a lot from it
18:39:49FromDiscord<bostonboston> In reply to @zimzozaur "I like to see": Then view the ASM output of the c compiler you're not stopped from doing that
18:39:52FromDiscord<zimzozaur> In reply to @nervecenter "Like I said in": I am not disagreeing with you.
18:39:57FromDiscord<muddmaker> I mean, there's nothing stopping you from looking at the ASM generated from Nim -> C -> ASM
18:40:02FromDiscord<zimzozaur> In reply to @bostonboston "Then view the ASM": True
18:40:18FromDiscord<bostonboston> Them has two maybe three core developers and as a result that's not enough people to write an entire compiler but because we are built on top of c compilers we have a very powerful very functional language
18:40:27FromDiscord<bostonboston> (edit) "Them" => "Nim"
18:40:53FromDiscord<zimzozaur> In reply to @muddmaker "I mean, there's nothing": man I could just write Nim. Look at C in CLion with ASM on the split panel, that's a suitable option.
18:41:01FromDiscord<zimzozaur> (edit) "man" => "Man,"
18:41:58FromDiscord<nervecenter> In reply to @zimzozaur "Man, I could just": Nim is supported on Godbolt if you want to see the breakdown of specific procedures. `-d:release` generates more optimized code.↵https://godbolt.org/
18:42:00FromDiscord<zimzozaur> In reply to @bostonboston "Nim has two maybe": I hope I will enjoy it too. Not { } is awesome :nim1:
18:42:01FromDiscord<muddmaker> In reply to @bostonboston "Nim has two maybe": And this is also ok because when looking at the nimony development process, there's a lot in flux as they try to figure out what it _should_ look like
18:42:27FromDiscord<zimzozaur> In reply to @nervecenter "Nim is supported on": Nice, thanks for info!
18:42:52FromDiscord<zimzozaur> Btw I get the point of translating to C but to JS?
18:43:02FromDiscord<muddmaker> Running nim in the browser is a lot easier
18:43:23FromDiscord<muddmaker> WASM isn't actually good outside of _very_ niche uses
18:44:03FromDiscord<zimzozaur> In reply to @muddmaker "Running nim in the": How do you access all of the DOM API etc with it? Do you mean I can use it instead of React?
18:44:34FromDiscord<muddmaker> There's DOM bindings. Nim has karax and a few other frontend frameworks to use instead of React
18:44:42FromDiscord<nervecenter> In reply to @zimzozaur "How do you access": https://nim-lang.org/docs/dom.html
18:44:51FromDiscord<zimzozaur> In reply to @muddmaker "WASM isn't actually good": I remember when year ago on my feed there was quite a lot of WASM and people saying not JS finally LOL
18:45:36FromDiscord<nervecenter> Has anyone tried using Nim with Emscripten?
18:45:39FromDiscord<muddmaker> WASM was an opportunity to do something awesome and it was very poorly done
18:45:55FromDiscord<zimzozaur> In reply to @nervecenter "https://nim-lang.org/docs/dom.html": Wait, can I learn Nim instead of JS? Too good to be true!
18:46:25FromDiscord<zimzozaur> In reply to @muddmaker "WASM was an opportunity": Can you elaborate?
18:47:14FromDiscord<bostonboston> In reply to @nervecenter "Has anyone tried using": I've heard mention of it around here, I think one or two people have apps using it
18:48:00FromDiscord<muddmaker> In reply to @zimzozaur "Can you elaborate?": The browser works as a specific VM, and instead of being a bytecode for shipping optimized code for that VM, Wasm is a _completely separate VM_ that does not provide anything that the browser's VM gives you
18:48:36FromDiscord<muddmaker> So actually binding to things in the DOM or JS world is slow and requires a lot of string copying
18:49:04FromDiscord<muddmaker> Wasm is good if you are doing some compute heavy things
18:49:10FromDiscord<zimzozaur> In reply to @muddmaker "The browser works as": Now I thought why the browser cannot read any byte code so you write any Lang to it like LLVM?
18:49:16FromDiscord<muddmaker> But it's horrible as a JS replacement
18:50:22FromDiscord<muddmaker> In reply to @zimzozaur "Now I thought why": ?
18:50:59FromDiscord<muddmaker> In reply to @muddmaker "But it's horrible as": If you look at the bundle sizes and performance of wasm frameworks, they are significantly bigger, use more memory, and are typically slower than equivalent JS frameworks
18:51:09FromDiscord<muddmaker> Slower by 4% at minimum
18:51:13FromDiscord<muddmaker> And that's with a lot of optimization
18:51:40FromDiscord<zimzozaur> In reply to @muddmaker "?": Why do browser not read bytecode instead of JS?
18:51:42FromDiscord<muddmaker> Leptos (Rust/wasm) is slower than Solid (JS) and they are architecturally very similar
18:52:05FromDiscord<muddmaker> In reply to @zimzozaur "Why do browser not": Ask the wasm team, not me lol
18:52:10FromDiscord<zimzozaur> In reply to @muddmaker "If you look at": Yeas sound bad
18:52:16FromDiscord<muddmaker> Wasm _should_ have been that bytecode format
18:52:21FromDiscord<muddmaker> But it _wasn't_
18:52:29FromDiscord<nervecenter> In reply to @zimzozaur "Why do browser not": Historyical reasons
18:52:31FromDiscord<mjsdev> sent a code paste, see https://play.nim-lang.org/#pasty=GEtIvuHI
18:52:35FromDiscord<nervecenter> (edit) "Historyical" => "Historical"
18:52:53FromDiscord<zimzozaur> In reply to @muddmaker "Ask the wasm team,": I am asking because maybe you know some secret stuff and want to share it with use!
18:52:54FromDiscord<muddmaker> Now, the question is with WebGPU compute shaders on the way, how many of the tasks that Wasm was actually better at could be done _even_ better with those
18:53:06FromDiscord<zimzozaur> In reply to @muddmaker "Wasm _should_ have been": Even more sad
18:53:48FromDiscord<muddmaker> In reply to @zimzozaur "I am asking because": I don't really know any secrets. I just follow the development of web frameworks and browsers and observe what people complain about lol
18:53:57FromDiscord<muddmaker> I'm a web dev for my day job
18:54:13FromDiscord<zimzozaur> In reply to @muddmaker "Wasm _should_ have been": It sounds like a good 5 billion seed first phase startups. Browser with a good bytecode engine and clear docs on how to use it.
18:54:33FromDiscord<muddmaker> It's not about the browser, but about the standards
18:54:37FromDiscord<zimzozaur> In reply to @muddmaker "I don't really know": That's somehing
18:55:49FromDiscord<zimzozaur> In reply to @muddmaker "It's not about the": Yeah. So you can be the first Nim-based Browser company that is not a next trash Chromium homunculus but the real safe and private open for any language browser.
18:55:57FromDiscord<muddmaker> LOL
18:56:27FromDiscord<muddmaker> First of all, building a browser is an insanely expensive endeavor. The only new browser engine of interest is Ladybird
18:56:43FromDiscord<muddmaker> But also, developers aren't going to make anything browser-exclusive
18:56:52FromDiscord<zimzozaur> In reply to @muddmaker "First of all, building": This is why I said - `It sounds like a good 5 billion seed first phase startups. `
18:56:56FromDiscord<zimzozaur> (edit) "startups. `" => "startups.`"
18:57:11FromDiscord<muddmaker> For it to be mainstream, a standards body MUST standardize it so that multiple browsers can implement it
18:57:40FromDiscord<muddmaker> And I don't think the standards bodies are going to standardize a _second_ attempt at WASM
18:57:45FromDiscord<muddmaker> Targetting JS is fine
18:57:52FromDiscord<muddmaker> (edit) "Targetting" => "Targeting"
18:58:05FromDiscord<zimzozaur> In reply to @muddmaker "Targeting JS is fine": You like JS more then me I think
18:58:13FromDiscord<zimzozaur> In reply to @muddmaker "And I don't think": XD
18:58:15FromDiscord<odexine> In reply to @muddmaker "But also, developers aren't": except if its of the majority browser
18:58:29FromDiscord<muddmaker> Which your new browser _isn't going to be_
18:58:40FromDiscord<odexine> prolly never tbh
18:59:17FromDiscord<muddmaker> I'd like to see Ladybird try, but yeah, I'd rather contribute to that instead of trying to _make my own browser engine_
18:59:24*beholders_eye quit (Ping timeout: 252 seconds)
18:59:26FromDiscord<muddmaker> Unless I were a billionaire and just wanted to throw money around
19:00:04FromDiscord<zimzozaur> In reply to @muddmaker "For it to be": How said it has to start with being standardized. Windows is used everywhere, and it wasn't standardized, I think. Just build so people want to use it and the rest will come naturally.
19:00:30FromDiscord<odexine> well it was a different time then
19:00:36FromDiscord<muddmaker> Well, for it to be standardized, you'd need to make a prototype and talk with the committees and the like
19:00:41FromDiscord<odexine> then there wasnt a very strong majority of operating systems
19:00:51FromDiscord<odexine> then you could still fuck around and maybe get a good amount of people onboard
19:01:28FromDiscord<muddmaker> Windows was the one that won because Microsoft both understood what businesses needed and was willing to use criminal means to crush competition
19:02:44FromDiscord<zimzozaur> You have DuckDuckGo that does not use chrome nor Firefox engine. Why not adopt DOM/HTML related API, write good docs make it open source? I think it is just a matter of money and will to do it
19:02:52FromDiscord<muddmaker> ?
19:03:03FromDiscord<muddmaker> DDG is a search engine that is a thin wrapper around Bing
19:03:13FromDiscord<zimzozaur> In reply to @muddmaker "DDG is a search": They have browser
19:03:37FromDiscord<muddmaker> https://en.wikipedia.org/wiki/DuckDuckGo_Private_Browser
19:03:55FromDiscord<muddmaker> It's Chrome or Safari depending on the platform
19:04:42FromDiscord<zimzozaur> https://en.wikipedia.org/wiki/DuckDuckGo_Private_Browser
19:06:31FromDiscord<zimzozaur> In reply to @muddmaker "It's Chrome or Safari": Even if. It does not matter. My statement is. Build a browser with a byte code API that is good and allow people to use it and make it open source, so others can build it something that is a real tech.
19:06:44FromDiscord<muddmaker> >Build a browser
19:07:31FromDiscord<muddmaker> The problem with this is that I don't think this is a good idea. Targeting JS is _fine_
19:08:01FromDiscord<muddmaker> We don't need browsers to adopt a second bytecode system
19:08:57FromDiscord<muddmaker> The most you could save is a little bit of parsing time, but even then, it's typically not the case that the browsers are slow from _parsing_ JS
19:09:45FromDiscord<bostonboston> You would dramatically save on used bandwidth
19:09:58FromDiscord<Robyn [She/Her]> In reply to @Amun-Ra "rolling your own language": why's that? Is it not good for a portfolio?
19:09:59FromDiscord<muddmaker> Dramatically?
19:10:17FromDiscord<zimzozaur> Who likes writing JS here. Maybe I am alone in this conversion
19:11:18FromDiscord<Robyn [She/Her]> In reply to @zimzozaur "What does it lacks?": Sane sum types is the main one I want (Beef's fungus lib doesn't count because it doesn't integrate with the type system well, and my attempt explodes with generics and still lacks match statements like Rust), and I'd also like to be able to hack away at a small codebase
19:11:31FromDiscord<muddmaker> In reply to @bostonboston "You would dramatically save": JS bandwidth has a lot more to do with shipping too much code than how the code is encoded
19:12:14FromDiscord<muddmaker> (As long as you are using a code minifier, of course)
19:13:56FromDiscord<zimzozaur> In reply to @battery.acid.bubblegum "Sane sum types is": Maybe it is a naive question, but if you are talking about creating a new lang. Why not create PR that solves part of what it lacks?
19:14:26FromDiscord<zimzozaur> In reply to @muddmaker "JS bandwidth has a": Do you mean all dependencies?
19:15:02FromDiscord<muddmaker> In reply to @zimzozaur "Who likes writing JS": TypeScript is good enough for most client-side work. Writing in Nim instead would be good because I do not want to use it for server-side stuff, but there are massive advantages to using the same language for both client and server
19:15:13FromDiscord<muddmaker> (For specific types of websites)
19:15:54FromDiscord<muddmaker> (edit) "it" => "JS/TS"
19:15:59FromDiscord<Robyn [She/Her]> In reply to @zimzozaur "Maybe it is a": Because then I have complete freedom over a small codebase rather than trying to familiarise myself with a large codebase, especially since I'm a Uni student, i can't dedicate much time
19:16:51FromDiscord<muddmaker> In reply to @battery.acid.bubblegum "Because then I have": I can almost completely guarantee that familiarizing yourself with Nim's codebase and making a PR to it would be less time intensive than writing a codebase from scratch
19:16:56FromDiscord<muddmaker> (edit) "codebase" => "new language"
19:17:10FromDiscord<muddmaker> In reply to @zimzozaur "Do you mean all": This is def part of it
19:18:30FromDiscord<Robyn [She/Her]> In reply to @muddmaker "I can almost completely": ...how?
19:19:19FromDiscord<muddmaker> Do you know how much work it is to make a new language from scratch, including all of the libraries and dev tools to make it possible to be productive in it?
19:20:26FromDiscord<zimzozaur> In reply to @muddmaker "TypeScript is good enough": So you can write full stack nim?
19:20:50FromDiscord<muddmaker> Yes. See the forum for an example: <https://github.com/nim-lang/nimforum>
19:21:20FromDiscord<nnsee> In reply to @muddmaker "Do you know how": to play devil's advocate, i don't think making a new language is hard at all. but making your language useful is something else entirely
19:21:57FromDiscord<muddmaker> That was part of what I was getting at. A new "language" can be easy. A new _useful_ language is very very hard
19:22:27FromDiscord<zimzozaur> In reply to @nnsee "to play devil's advocate,": Do you mean writing a parser in Python is easy and writing something that is no useless is hard?
19:23:14FromDiscord<muddmaker> In reply to @zimzozaur "So you can write": One thing I will say about nim's web frameworks is that they are still fairly rudimentary compared to a lot of the stuff you see elsewhere, but it _can_ be done
19:23:47FromDiscord<zimzozaur> In reply to @muddmaker "Yes. See the forum": Sound so sexy
19:24:16FromDiscord<nnsee> In reply to @zimzozaur "Do you mean writing": not even python, there are specialized tools specifically for writing languages, ie lex/yacc etc
19:24:38FromDiscord<muddmaker> Writing a parser in Python would be easier than using lex/yacc to be fair
19:24:47FromDiscord<nnsee> fair point
19:24:58FromDiscord<muddmaker> Especially using some Python parser library
19:26:23FromDiscord<Robyn [She/Her]> In reply to @muddmaker "Do you know how": Yeah making it useful is a different matter, since I'm gonna be targeting the JVM primarily, everything I'd want is already made, it's easy to create bindings via reflection
19:27:00FromDiscord<muddmaker> That's fair
19:27:45FromDiscord<nnsee> being able to leverage an existing ecosystem is almost always a smart move, but then you're still at the whims of whoever is writing the standard, as your language has to implement that correctly
19:27:59FromDiscord<nnsee> which is not as easy as it may at first seem
19:28:39FromDiscord<nnsee> if you're going the jvm route, iirc graal has an extensive test suite for verifying jvm bytecode behaves as it should
19:28:53FromDiscord<nnsee> not sure how easy it would be to shoehorn that into your project though
19:29:57*mengu1 quit (Quit: Client closed)
19:31:14FromDiscord<nnsee> or, well, you're emitting jvm not writing an implementation
19:31:18FromDiscord<nnsee> never mind me i'm tired
19:31:44FromDiscord<zimzozaur> In reply to @battery.acid.bubblegum "Yeah making it useful": Btw why do you want to use JVM?
19:38:01*ntat_ joined #nim
19:38:20FromDiscord<Robyn [She/Her]> In reply to @zimzozaur "Btw why do you": Minecraft modding :)
19:38:22*ntat quit (Ping timeout: 272 seconds)
19:38:38FromDiscord<Robyn [She/Her]> In reply to @nnsee "or, well, you're emitting": Yeah I'm emitting, not implementing :P
19:44:56FromDiscord<muddmaker> In reply to @battery.acid.bubblegum "Minecraft modding :)": I'm surprised it wasn't Android development or similar
19:49:10*ntat_ is now known as ntat
19:52:03FromDiscord<fabric.input_output> In reply to @zimzozaur "Do you mean writing": the parser is simply a chore and maybe the least significant part of a compiler/interpeter
19:56:06FromDiscord<Elegantbeef> Hey the parse looks hard until you get to type analysis and code generation
20:31:53FromDiscord<zimzozaur> In reply to @battery.acid.bubblegum "Minecraft modding :)": In nim?
20:43:55FromDiscord<Robyn [She/Her]> In reply to @zimzozaur "In nim?": I wish, it might be a possibility with Nimony, or maybe with Chicory and a WASM language adapter for Fabric or something
20:51:53FromDiscord<zimzozaur> In reply to @battery.acid.bubblegum "I wish, it might": And then the main use case of Nim will be Minecraft and Roblox modding
21:14:23FromDiscord<kapendev> A language optimized for Minecraft and Roblox. Should be on the main site.
21:39:26*ntat quit (Quit: Leaving)
22:01:02*rockcavera joined #nim
22:22:23*beholders_eye joined #nim