| 00:09:07 | * | jmdaemon joined #nim |
| 00:46:52 | * | khazakar joined #nim |
| 01:44:49 | * | jmdaemon quit (Ping timeout: 264 seconds) |
| 01:53:38 | * | jmdaemon joined #nim |
| 01:59:59 | * | jmdaemon quit (Ping timeout: 264 seconds) |
| 02:22:57 | * | krux02 quit (Remote host closed the connection) |
| 02:29:44 | * | jmdaemon joined #nim |
| 02:56:05 | * | jmdaemon quit (Ping timeout: 252 seconds) |
| 03:05:04 | FromDiscord | <girvo> sent a code paste, see https://play.nim-lang.org/#pasty=TKDUGXtQyTfm |
| 03:09:40 | * | jmdaemon joined #nim |
| 03:11:50 | FromDiscord | <girvo> `--passC:"-I$PWD/shoco"` in my nim.cfg doesn't quite work, is there a way to grab the absolute path of the workspace? |
| 03:13:22 | FromDiscord | <girvo> sent a code paste, see https://play.nim-lang.org/#pasty=EETlbfohfuwX |
| 03:32:09 | FromDiscord | <Elegantbeef> @girvo https://github.com/beef331/wasm3/blob/master/src/wasm3/wasm3c.nim#L3-L11 might help |
| 03:32:15 | FromDiscord | <Elegantbeef> Not ideal of course |
| 03:39:11 | * | jkl__ joined #nim |
| 03:41:23 | * | jkl quit (Ping timeout: 256 seconds) |
| 03:47:27 | * | SchweinDeBurg joined #nim |
| 03:51:17 | FromDiscord | <girvo> Hah yeah that was the next approach I was going to pull out! |
| 03:51:38 | FromDiscord | <girvo> If my existing one doesn't work robustly I'll try that instead |
| 05:15:10 | * | jkl__ is now known as jkl |
| 06:07:26 | * | disso-peach joined #nim |
| 06:14:50 | * | rockcavera quit (Remote host closed the connection) |
| 06:22:16 | * | disso-peach quit (Quit: Leaving) |
| 06:56:06 | * | advesperacit joined #nim |
| 07:28:34 | * | PMunch joined #nim |
| 07:37:41 | FromDiscord | <pierce.jason> would appdev be the Chan to ask about TUI/GUI libs for generic tooling? |
| 07:44:05 | FromDiscord | <odexine> “Generic tooling”? #appdev perhaps |
| 07:46:30 | * | azimut joined #nim |
| 07:48:33 | FromDiscord | <user2m> sent a code paste, see https://play.nim-lang.org/#pasty=rseADoQTPhbj |
| 07:49:45 | FromDiscord | <odexine> Nil isn’t a compile time thing |
| 07:49:58 | FromDiscord | <odexine> On the other hand, in Nim, “is not” is one word |
| 07:50:08 | FromDiscord | <odexine> is_not |
| 07:50:46 | FromDiscord | <user2m> In reply to @odexine "Nil isn’t a compile": the when statement makes it compile time I believe |
| 07:51:29 | Amun-Ra | that's why it shouldn't work |
| 07:51:38 | FromDiscord | <user2m> so I guess in this case how would I check for null then? |
| 07:51:39 | Amun-Ra | unless the whole proc is compiletime |
| 07:51:41 | FromDiscord | <Elegantbeef> `when accordion.onclose != nil` |
| 07:51:47 | FromDiscord | <Elegantbeef> If it's a const |
| 07:51:49 | FromDiscord | <Elegantbeef> Otherwise use `if` |
| 07:52:42 | FromDiscord | <user2m> ok ` if accordion.onClose != nil:` seems to work |
| 07:54:28 | FromDiscord | <user2m> sent a code paste, see https://play.nim-lang.org/#pasty=mecSACDthXYd |
| 07:54:58 | FromDiscord | <Elegantbeef> is it a `const` or `static` parameter? |
| 07:56:16 | Amun-Ra | user2m: the whole accordion has to be created during compile time |
| 07:56:55 | FromDiscord | <user2m> Ahhh ok that makes sense |
| 08:04:51 | FromDiscord | <tapeda> Maybe a concept is what you want to ensure onClose exists at compiletime? |
| 08:09:41 | * | xutaxkamay quit (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 08:10:51 | FromDiscord | <user2m> In reply to @tapeda "Maybe a concept is": lol I'm not really sure what a concept is. I'm compiling down to JS and was trying to do conditonal compilation where if the "onClose" is nil the code to handle onClose isn't even generated. I think what I want is a template, but I'm not sure it's working out |
| 08:11:41 | * | xutaxkamay joined #nim |
| 08:12:16 | Amun-Ra | use 'if' for that |
| 08:17:23 | FromDiscord | <Robyn [She/Her]> A concept is what you'd want then, they're basically generic constraints, though I don't have an example of how to use them, Beef would probably be able to help |
| 08:17:55 | FromDiscord | <Elegantbeef> `when compiles(bleh.onClose): bleh.onClose(...)`? |
| 08:18:20 | FromDiscord | <Robyn [She/Her]> That's also an option :P |
| 08:18:30 | Amun-Ra | but that would always be true |
| 08:18:36 | FromDiscord | <Robyn [She/Her]> Oh yeah true |
| 08:19:02 | FromDiscord | <Elegantbeef> I mean what the hell are they doing that they want compilation dependent? 😄 |
| 08:19:30 | FromDiscord | <user2m> In reply to @Elegantbeef "I mean what the": lol maybe I'm not explaingin myself super well |
| 08:19:42 | FromDiscord | <Robyn [She/Her]> I have that issue too, you aren't alone xD |
| 08:19:46 | Amun-Ra | what I suspect: save two lines of javascript code if onClose is nil in runtime |
| 08:19:59 | Amun-Ra | you can't do that with 'when' in this case |
| 08:20:00 | FromDiscord | <Elegantbeef> Which you cannot do |
| 08:20:34 | FromDiscord | <Robyn [She/Her]> Oh well |
| 08:22:21 | FromDiscord | <user2m> sent a code paste, see https://play.nim-lang.org/#pasty=tzhEcjtwDiFs |
| 08:23:02 | FromDiscord | <Elegantbeef> No |
| 08:23:08 | FromDiscord | <Elegantbeef> When debug is set to true code is still generated |
| 08:23:09 | FromDiscord | <user2m> I think the key here is that debug is a const |
| 08:23:16 | FromDiscord | <Elegantbeef> `if` is not `when` |
| 08:23:27 | FromDiscord | <Elegantbeef> If you used when you'd be right |
| 08:24:11 | Amun-Ra | user2m: https://play.nim-lang.org/#pasty=CRBRadHAzaCt |
| 08:25:52 | FromDiscord | <user2m> In reply to @Amun-Ra "<@419925691832991754>: https://play.nim-lang.org/#p": ahh ok that makes things much clearer |
| 08:26:17 | Amun-Ra | user2m: to be honest, your template could be optimized out with higher -O level, but that depends solely on the compiler |
| 08:26:45 | FromDiscord | <user2m> In reply to @Amun-Ra "<@419925691832991754>: to be honest,": -O ? |
| 08:26:55 | Amun-Ra | user2m: with when you don't risk anything, just switch this part of the code off yourself |
| 08:27:21 | Amun-Ra | user2m: compilers have different optimization levels, usually passed using -O option, -O0 … -O3, etc |
| 08:30:47 | FromDiscord | <user2m> In reply to @Amun-Ra "<@419925691832991754>: compilers have different": urghhh just when I thought i was getting a grasp on the language lol can you link me some documentation about these optimization levels? I only see `--opt:none|speed|size` |
| 08:31:14 | Amun-Ra | user2m: these are nim optimization flags |
| 08:32:09 | Amun-Ra | user2m: long story short: use when :P |
| 08:37:54 | FromDiscord | <Elegantbeef> To the original query there is no way to do compilation dependent logic with runtime values by the very nature that it's impossible to generate code ahead of time for data you don't know |
| 08:45:44 | Amun-Ra | mhm |
| 08:51:19 | FromDiscord | <Robyn [She/Her]> In reply to @Amun-Ra "<@419925691832991754>: compilers have different": This is with Nim's JS backend so that's not doable I don't think |
| 08:52:11 | Amun-Ra | right, in this case the decision whether to optimize that code out is up to nim and nim only |
| 08:52:22 | Amun-Ra | well, let me check that out |
| 08:56:01 | Amun-Ra | https://play.nim-lang.org/#pasty=YXMmPrxMBHzp |
| 10:05:06 | FromDiscord | <narimiran> Here are the results of the 2023 Community survey: https://nim-lang.org/blog/2024/01/31/community-survey-results-2023.html |
| 10:08:43 | FromDiscord | <nnsee> glad to see that tooling is one of the main priorities this year |
| 10:08:59 | FromDiscord | <nnsee> i feel like it's a major pain point right now |
| 10:17:56 | PMunch | 10% of respondents haven't tried Nim? |
| 10:18:09 | PMunch | How did they find the survey? :P |
| 10:18:39 | PMunch | narimiran, do you have absolute numbers for how many people have taken the survey each year? |
| 10:20:14 | PMunch | "Compared to the response from last year, our user-base has more Nim experience than before." well you'd hope we'd have about a year each more :P |
| 10:21:16 | PMunch | But I guess what it actually means is that we manage to retain people (at least get them to answer the survey) |
| 10:22:45 | PMunch | What would be interesting for next year is to draw a small black line or something for where the values where this year |
| 10:23:42 | PMunch | Or if you want to keep the graphs clean maybe if you hover over them they show the graph from last year :) |
| 10:23:44 | FromDiscord | <nnsee> In reply to @PMunch "But I guess what": or from an alternative viewpoint, fail to attract new people? |
| 10:24:24 | PMunch | Well for our collective experience to decline without loosing anyone we'd need quite a lot of new people |
| 10:25:09 | FromDiscord | <narimiran> In reply to @PMunch "<@719992187890434069>, do you have": 2020: 769↵2021: 825↵↵but they had even more non-users, because the link for the survey was shared on HN etc. |
| 10:25:36 | PMunch | And this year? |
| 10:26:54 | FromDiscord | <narimiran> (edit) "In reply to @PMunch "<@719992187890434069>, do you have": 2020: 769↵2021: 825↵↵but they had even more non-users, because the link for the survey was shared on HN etc." => "sent a long message, see https://pasty.ee/sMrMmnBMUGzh" |
| 10:27:16 | FromDiscord | <narimiran> In reply to @PMunch "And this year?": it's written in the first sentence in the article, but now i added it to the comment above too |
| 10:27:52 | PMunch | Ah right |
| 10:28:08 | FromDiscord | <ringabout> It should be "plan 2024" => https://github.com/nim-lang/website/pull/389 |
| 10:28:27 | PMunch | And I swear I read the first paragraph trice before asking.. |
| 10:29:38 | PMunch | Huh, the Nim community skews pretty old and experienced |
| 10:31:08 | PMunch | Just noticed that it also references "last year" for all the comparisons, even though the last survey was 2021 |
| 10:34:42 | FromDiscord | <narimiran> In reply to @PMunch "Just noticed that it": ...and now is 2024 😛↵yeah, "last survey" might be a better choice of words |
| 10:34:57 | FromDiscord | <narimiran> In reply to @ringabout "It should be "plan": good catch! fixed, thanks. |
| 10:36:42 | PMunch | All in all a fun read, and good to see that it's mostly a positive change in trends :) |
| 10:58:29 | FromDiscord | <tauruuuuuus> In reply to @nnsee "i feel like it's": Totally agree, coming from something like go, the experience here is subpar at best |
| 10:59:24 | FromDiscord | <tauruuuuuus> For tooling at least |
| 11:00:33 | FromDiscord | <odexine> I moved from Nim to, well the regulars know where, Haskell and Elixir and holy Christ the tooling was so much better there that I was surprised that I thought “oh is that supposed to be the norm???” |
| 11:04:04 | FromDiscord | <jmgomez> In reply to @chronos.vitaqua "<@726017160115126333> works on NimForUE": @mengu The cpp interop is one of the best in the industry. The project that Demo shared can be helpful to see examples on how to do things. But also take a look at the manual and the experimental docs |
| 11:04:36 | FromDiscord | <tapeda> In reply to @odexine "I moved from Nim": Anything super specific jump out at you? Maybe I'm just old school and a text editor showing errors already feels like luxury, and build systems are cope for weird architectures but again don't mind me |
| 11:04:51 | FromDiscord | <tapeda> (edit) "In reply to @odexine "I moved from Nim": Anything super specific jump out at you? Maybe I'm just old school and a text editor showing errors already feels like luxury, and build systems are cope for weird ... architectures" added "code" |
| 11:05:06 | FromDiscord | <odexine> I also thought that way, to me even highlighting was a luxury |
| 11:05:43 | FromDiscord | <odexine> But the flow is much faster when your editor recommends refactors and whatnot |
| 11:06:04 | FromDiscord | <odexine> Especially the Haskell ones, it’s like they gave the compiler a fucking brain or something |
| 11:08:41 | FromDiscord | <tapeda> Ok fair, I don't need convincing that Haskell is big brained |
| 11:11:45 | FromDiscord | <odexine> In any case it’s not my intention to do so |
| 11:12:05 | FromDiscord | <zumi.dxy> I do wonder if challenges in Nim's tooling could be caused by having to account for UFCS |
| 11:12:11 | FromDiscord | <zumi.dxy> Does D have the same problem? |
| 11:12:56 | FromDiscord | <zumi.dxy> Then again, for me it's less that and more random crashes I haven't yet looked into :p |
| 11:24:31 | FromDiscord | <odexine> In reply to @zumi.dxy "I do wonder if": Doubt |
| 11:24:45 | FromDiscord | <odexine> I don’t see why that would be the case |
| 11:25:29 | FromDiscord | <odexine> I’d say the most problematic thing is the compiler architecture perhaps |
| 11:30:22 | FromDiscord | <jmgomez> I'd say resources has been limited and the focus has been in other areas |
| 11:56:26 | FromDiscord | <saint.___.> Has there been any news on IC yet? |
| 12:02:01 | FromDiscord | <nnsee> not this year, i don't think |
| 12:02:38 | FromDiscord | <nnsee> this is quite interesting though https://media.discordapp.net/attachments/371759389889003532/1202222406236639232/image.png?ex=65ccabdd&is=65ba36dd&hm=0ac80cc8705f3c18e4bae35b66e495fc43fad0ea03c1f9d0859a08c1b0d91d1f& |
| 12:02:40 | FromDiscord | <nnsee> finally |
| 12:24:35 | FromDiscord | <saint.___.> In reply to @nnsee "not this year, i": Wow not this year at all huh |
| 12:25:28 | FromDiscord | <nnsee> i think there have been a few commits by araq regarding nir but otherwise yeah |
| 12:29:09 | FromDiscord | <saint.___.> Gotcha |
| 13:43:49 | * | rockcavera joined #nim |
| 13:59:16 | * | lucasta joined #nim |
| 15:16:17 | anddam | IC == ? |
| 15:17:13 | FromDiscord | <nnsee> incremental compilation |
| 15:20:50 | FromDiscord | <griffith1deadly> In reply to @nnsee "incremental compilation": this mean nim to c incremental compilation, c compilation produced by nim, or both? |
| 15:21:20 | FromDiscord | <odexine> nim to some other language IC |
| 15:21:35 | FromDiscord | <griffith1deadly> (edit) "c" => "c/cpp/js" |
| 15:21:50 | FromDiscord | <griffith1deadly> (edit) "c" => "c/cpp/js" |
| 15:24:40 | FromDiscord | <jviega> Generally when people talk about incremental compilation for Nim, they're talking particularly cross-module dependencies. The pattern of loading all your data structures into some base file to avoid cross-module dependencies should die. |
| 15:42:11 | * | PMunch quit (Quit: Leaving) |
| 16:08:53 | * | azimut quit (Ping timeout: 255 seconds) |
| 16:50:38 | * | lucasta quit (Quit: Leaving) |
| 16:53:43 | * | SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev) |
| 17:47:50 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 17:49:43 | * | antranigv joined #nim |
| 18:05:39 | * | derpydoo joined #nim |
| 18:12:32 | arkanoid | how silly would be a backend that compiles nim to sh/bash? |
| 18:14:13 | FromDiscord | <Robyn [She/Her]> In reply to @arkanoid "how silly would be": Absolutely hilarious, you should do it xD |
| 18:14:29 | FromDiscord | <Robyn [She/Her]> Compiling various Nim libs to sh seems horrid |
| 18:32:11 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 18:33:31 | * | antranigv joined #nim |
| 18:33:43 | arkanoid | really horrid |
| 18:34:06 | arkanoid | but thing about it: sh is everywhere, and it's really a shitty and error prone language |
| 18:34:30 | arkanoid | compiling nim to the most available scripting language in the world seems like a win, to me |
| 18:35:03 | FromDiscord | <graveflo> but C is the most available compiler and that is more available then bash is. Why not just compile to c? |
| 18:36:45 | FromDiscord | <penguinite> Don't worry, no one is actually going to implement a Nim-to-sh compiler... at least, hopefully... |
| 18:37:03 | FromDiscord | <penguinite> You'd have to maintain your own fork of the standard library, and compiler just to make sh work. |
| 18:37:48 | FromDiscord | <penguinite> NimScript to sh might be a good idea tho. But not normal nim. |
| 18:44:06 | FromDiscord | <graveflo> also, bash is a shitty lang that is for sure but somehow it's a good shell lang. That is more of a problem with shell langs. If you are doing anything complicated I would just make a binary or shebang python or something. I never write anything that isn't a "dumb" dispatch script in bash. It's basically tech illiterate to do that at this point |
| 18:44:39 | FromDiscord | <penguinite> Agreed. csh syntax is way better, but thats not nearly as common as bash unfortunately. |
| 18:49:13 | Amun-Ra | arkanoid: which one? sh subset? bash? zsh? |
| 18:49:41 | arkanoid | posix sh |
| 18:50:26 | Amun-Ra | performance will be horrible |
| 18:51:13 | Amun-Ra | only strings, no arrays, etc. |
| 18:51:15 | arkanoid | who cares. The issue to solve here is easier development of sh files due to static typing |
| 18:52:40 | Amun-Ra | static typing → typeless |
| 18:55:48 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 18:58:09 | * | antranigv joined #nim |
| 19:05:09 | FromDiscord | <graveflo> I think static typing only makes things harder. It's only real use is to assist the compiler in making machine language |
| 19:06:09 | FromDiscord | <graveflo> That is assuming there are some linting systems for tracking things when the programmer chooses to |
| 19:06:51 | FromDiscord | <anuke> I think static typing is necessary and required for anything beyond a trivial project. I want to know what a function takes and returns, regardless of whether that helps the compiler produce more performany code (Typescript exists and is popular for this reason) |
| 19:06:58 | FromDiscord | <anuke> (edit) "performany" => "performant" |
| 19:07:20 | FromDiscord | <penguinite> Same. Static typing enables us to do overloading and many other wonderful things. |
| 19:07:25 | FromDiscord | <graveflo> I get that but when a program is designed differently it matter less what types things are and more what the function does |
| 19:07:30 | FromDiscord | <graveflo> that's why nim has generics |
| 19:08:42 | FromDiscord | <penguinite> Idk tbh, I dont think static typing is such a nuisance. Most of the time when I have had issues due to static typing, it was because of a typo or other user-error. |
| 19:08:48 | Amun-Ra | static and dynamic typings have their pros and cons; what really I'd count as requires is strong typing |
| 19:09:22 | Amun-Ra | required* |
| 19:10:39 | FromDiscord | <graveflo> its not really a nuisance it's just not necessary often and therefore doesn't need to be a requirement to assist the programmer. If you can chose when to denote a type and when not to that is better because you get all the utility you need. The compiler is the needy one that uses the information to make a more efficient executable |
| 19:16:30 | FromDiscord | <summarity> What C standard version does the Nim C backend require? |
| 19:17:34 | Amun-Ra | C99 iirc |
| 19:31:51 | FromDiscord | <jviega> Yeah, static typing's primary purpose is catching errors before running code. You don't need to generate faster code from it, full stop. |
| 19:32:39 | FromDiscord | <jviega> You can do overloading w/o static typing, too. Dynamically dispatching based on type is not an issue |
| 19:40:14 | FromDiscord | <graveflo> sent a long message, see https://pasty.ee/VHHOPfxeLGOF |
| 19:40:34 | FromDiscord | <graveflo> (edit) "https://pasty.ee/oSenLBzlCsmP" => "https://pasty.ee/SuwYNfqSVKHs" |
| 19:40:36 | * | spacelucy quit (Quit: WeeChat 4.2.1) |
| 19:40:54 | * | spacelucy joined #nim |
| 19:42:33 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 19:42:36 | FromDiscord | <jviega> Of course it is why static typing is a thing. Anyone who compares error rates for, for instance, Python programs that have static type checking added, and ones that don't, will see that it's much, much higher. That's why such systems have been quite popular with some kinds of people, even in environments (like Python) where performance is not a big concern for anyone. |
| 19:43:48 | FromDiscord | <jviega> Hindly and Milner were not focused on optimization, they were focused on correctness. Plenty of implementations don't generate efficient code, leaving, for instance, one generic function instead of specializing for each type. |
| 19:43:56 | * | antranigv joined #nim |
| 19:43:59 | FromDiscord | <graveflo> sure. It's a skill to know when to use it and when not to. I did say that it's helpful when intentionally used for that purpose. My point is that people don't need it as much as the compiler does (not anywhere near as much really) |
| 19:45:11 | FromDiscord | <jviega> Well, that's not really true in a sense. C is pretty poorly typed in general and produces code that's much faster than most code that is far better typed in Java and Go, for instance. |
| 19:45:37 | FromDiscord | <jviega> And asm basically just has one type |
| 19:46:05 | FromDiscord | <jviega> Can type info help improve performance? Yes. |
| 19:46:15 | FromDiscord | <jviega> But, meh. |
| 19:47:19 | FromDiscord | <graveflo> right but that's just further evidence that the notion of strict typing isn't fundamentally tied to the problems that are being solved on either end. It's just a system that solves imposed constraints by the nature of the system. We don't have to think in types but we can solve plenty hard problems. |
| 19:48:42 | FromDiscord | <jviega> That sentence doesn't parse for me. Strict typing is primarily about helping remove errors before running. Sure, it's not necessary to do that to run code? |
| 19:49:33 | * | krux02 joined #nim |
| 19:51:25 | FromDiscord | <graveflo> it is but why stop there? You can do all sorts of things to bug squash. It's not that it isn't worth it. I'm saying the restriction exists for the reasons I said earlier. These languages haven't even been around that long. I understand that some people will find comfort in the potential bugs the type system can find but it's just not the only way to find them. You can also just use linting to find bugs with static code analysis and you h |
| 19:51:42 | * | spacelucy quit (Quit: WeeChat 4.2.1) |
| 19:51:55 | FromDiscord | <graveflo> of course no language exists that can do all that and still produce an efficient binary but thats my point. |
| 19:52:00 | * | spacelucy joined #nim |
| 19:52:45 | FromDiscord | <jviega> Huh??? Full static typing dates back to 1969, and many, many seasoned programmers think it's very worth it. |
| 19:53:04 | FromDiscord | <graveflo> that is not long ago at all |
| 19:53:07 | FromDiscord | <jviega> Good linting makes good use of strong type info too |
| 19:54:14 | FromDiscord | <jviega> It's well over half a century? The only real language people still commonly write from back then is Fortran. It's pretty long ago. |
| 19:54:45 | FromDiscord | <graveflo> no it's extremely modern tech that is still being iterated on and will be for a long time |
| 19:55:29 | FromDiscord | <graveflo> how many years did it take us to invent calculus? maybe like over 10k |
| 19:55:57 | FromDiscord | <jviega> 🙄 Have fun in your little fantasy bubble, I'm done. |
| 19:56:53 | FromDiscord | <kiloneie> https://nim-lang.org/docs/tables.html#basic-usage-hashing↵↵Did this used to be a compiler error but now it's not ? |
| 19:57:11 | FromDiscord | <kiloneie> e.g. using an Object for the key of a Table ? |
| 19:58:54 | FromDiscord | <penguinite> how do you get the amount of free memory on a system? |
| 20:00:20 | FromDiscord | <graveflo> In reply to @pengwyns "how do you get": easier said then done. You have to ask the OS and it's not going to be extremely precise |
| 20:00:41 | FromDiscord | <penguinite> Alright. time to dive deep into POSIX and Win32 |
| 20:06:24 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 20:06:43 | * | antranigv joined #nim |
| 20:07:30 | FromDiscord | <jviega> Are you looking to get it on a particular type of system? There's not a posix way to do it, but it's easy on some OSes |
| 20:09:31 | FromDiscord | <penguinite> I found this: https://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g#2513561 and I am currently trying to wrap it using nim's ffi. But I am not exactly sure how I should do the _SC_PHYS_PAGES stuff. If I try to declare a let variable with importc in it then nim will fail since the variable has an underscore in it. |
| 20:10:28 | FromDiscord | <penguinite> (edit) "in it." => "as its first character." |
| 20:11:37 | FromDiscord | <jviega> Yeah, you can do {.importc:"_SC_PHYS_PAGES"} to express the C name |
| 20:12:07 | FromDiscord | <jviega> the name you're specifying think of as the Nim name, which by default is the external symbol |
| 20:14:11 | FromDiscord | <penguinite> Oh thank you! I got it to work now! |
| 20:14:18 | FromDiscord | <jviega> Awesome |
| 20:16:19 | FromDiscord | <jviega> sysconf() doesn't always support the same params everywhere, BTW. I think for memory the header file is different on MacOS, but the keys are the same? Been a minute, so I don't quite remember but you should just be on the lookout |
| 20:17:22 | FromDiscord | <penguinite> Well thats strange. But I don't think anyone on Mac OS will run this so it should be fine. |
| 20:27:45 | FromDiscord | <␀ Array 🇵🇸 🍉> lol↵(@graveflo) |
| 20:28:46 | FromDiscord | <jviega> Well, it's not posix standard, like I said |
| 20:29:13 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 20:30:33 | * | antranigv joined #nim |
| 20:47:41 | * | azimut joined #nim |
| 20:53:01 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 20:53:57 | FromDiscord | <saint.___.> @graveflo Just curious are you more in favor of dynamically typed langs? |
| 20:58:18 | FromDiscord | <graveflo> In reply to @saint.___. "<@200775012796334081> Just curious are": practically, no, but that's because there isn't a dynamically typed language that can compete with a statically typed one in execution speed. Idk what a language that manages both would have to look like. I think that dynamic typing relaxes a constraint that is not necessary to express logic so it is better. Any benefit to development that static typing has can be substi |
| 20:58:38 | * | advesperacit quit () |
| 20:59:41 | FromDiscord | <graveflo> or eliminated all together tbh. Not sure about that one. |
| 21:01:17 | * | antranigv joined #nim |
| 21:08:45 | FromDiscord | <saint.___.> What about user error though |
| 21:09:05 | FromDiscord | <graveflo> you mean the developer user or the user user 😛 |
| 21:09:09 | FromDiscord | <saint.___.> developer |
| 21:09:51 | FromDiscord | <graveflo> yea programs are always going to have bugs in them, but ask anyone who develops professionally if "it compiled" is good enough to say a program is tested and stable |
| 21:10:42 | FromDiscord | <saint.___.> Isn't that taking things to the extreme though |
| 21:10:53 | FromDiscord | <graveflo> you determine that from testing. There's no situation where testing will fail to find an error that static typing will find, or if it is we are just talking about freak stuff.. its not why static typing exists. It was never a bug prevention mech |
| 21:11:17 | FromDiscord | <graveflo> its not extreme to do things that make sense. want less errors -> test more |
| 21:11:26 | FromDiscord | <saint.___.> Yeah but why catch it in testing when I can catch it sooner |
| 21:11:41 | FromDiscord | <saint.___.> Are you against like python types |
| 21:11:48 | FromDiscord | <graveflo> the extreme thing would be having an unnecessary testing mech active all the time and you cant turn it off. That's not a safety net. |
| 21:11:57 | FromDiscord | <saint.___.> (edit) "Are you against like python ... types" added "hint" |
| 21:12:52 | FromDiscord | <graveflo> no python type hints are more like what I mean when I say linting. They aren't perfect but that is the right idea |
| 21:13:18 | FromDiscord | <graveflo> you can still put that in there to help you write code and express to other devs what the intent is, but its not a hard restriction that you cannot break |
| 21:13:33 | FromDiscord | <graveflo> it's not gunna segfault when you throw the "wrong" type in there |
| 21:14:33 | FromDiscord | <graveflo> and of course, like I said, languages like Nim and C++ and rust have stuff like that too. Generics are what matches that closest in Nim. They make life easier and open up different ways of designing code |
| 21:14:38 | FromDiscord | <graveflo> because they relax constraints |
| 21:14:55 | FromDiscord | <saint.___.> So u are against any hard constraints |
| 21:14:58 | FromDiscord | <saint.___.> Ideally |
| 21:15:22 | FromDiscord | <graveflo> yea that would be ideal. If you know what you are doing you can break the rule, otherwise just stick with the hint |
| 21:15:22 | FromDiscord | <saint.___.> That kinda makes sense |
| 21:16:17 | FromDiscord | <graveflo> and thinking of them as rules at that point would be wrong, of course... its just a different way of problem solving. I wasn't used to it at first but once you get it, it does make sense |
| 21:19:33 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 21:20:23 | * | antranigv joined #nim |
| 21:36:57 | FromDiscord | <jviega> Well, that's just laughable. I've been writing software professionally for 30 years, and have seen many, many, many bugs that survived testing, and bit real people in production, but would have been trivially found via static typing. That is why TypeScript has gotten so big, as has type hinting for Python. |
| 21:39:23 | FromDiscord | <jviega> The level of effort in some of those projects on testing was massive specifically because it was a more dynamic language too, and yet people got bit all the time... sometimes months after a bug got introduced, because it was on some rarely executed path (and some paths didn't have a type problem, so they got coverage).... but again, would have been found statically. |
| 21:40:50 | FromDiscord | <graveflo> like what then? That would be an interesting case study. Also, I did say quite a few times that linting (like type hints in python) should still be a thing.. again so you can still have the benefits without the restrictions. |
| 21:40:55 | FromDiscord | <jviega> You're entitled to your opinion, but my experience maps with most people that have been developing this long. When people don't prefer static types it's either because, a) They want to make it easier for newbies to work on the code base, b) want to type less, or c) really have never ever used static systems. |
| 21:41:43 | FromDiscord | <jviega> No, good linting requires a good understanding of the context, which requires type info |
| 21:41:55 | FromDiscord | <jviega> What you might prefer is types to be automatically inferenced whenever possible |
| 21:42:15 | FromDiscord | <Elegantbeef> F# style type inference |
| 21:42:17 | FromDiscord | <Elegantbeef> Where everything is static but you do not need type annotations |
| 21:42:17 | FromDiscord | <jviega> That's not done well in most languages; a lot of people do prefer to always write types |
| 21:42:19 | FromDiscord | <graveflo> no I think higher level languages like python are better suited for more knowledgeable people than less. That is just one of those beginners traps where hiding complexity looks more approachable |
| 21:42:55 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 21:43:48 | * | antranigv joined #nim |
| 21:44:09 | FromDiscord | <graveflo> In reply to @Elegantbeef "Where everything is static": This is the opposite of what I am talking about, but who knows. Maybe that is nice? lol |
| 21:44:28 | FromDiscord | <jviega> @ElegantBeef while it's possible to fully statically type inference a useful turing complete language (ML indeed did it back in 1969), most languages will want to support some kind of non-parametric polymorphism which will require occasional annotation |
| 21:45:15 | FromDiscord | <Elegantbeef> I mean static typing does prevent bugs so idk what we're talking about |
| 21:45:48 | FromDiscord | <graveflo> I think that is wildly overstated. It's not very good at doing that |
| 21:46:12 | FromDiscord | <Elegantbeef> I massively disagree, but without any empirical evidence I'll just shush |
| 21:46:15 | FromDiscord | <graveflo> otherwise statically typed languages would produce much less buggy code but they dont |
| 21:46:38 | FromDiscord | <Elegantbeef> They remove a whole suite of logical errors |
| 21:46:38 | FromDiscord | <Elegantbeef> They do not remove all logical errors |
| 21:47:03 | FromDiscord | <jviega> Well, it shouldn't feel different. The types are all there, in any of those languages. w/ Python is they're not checked until runtime, so you might miss bugs. With more static systems, you tend to write all your types out. But if you're not worried about performance why would you care if the type is checked statically or dynamically? You'd just care about whether you want to have to write types or not (some people want to) |
| 21:47:34 | FromDiscord | <jviega> And it not only dramatically reduces bug rates, it dramatically reduces the average time a bug lays unfound. |
| 21:48:10 | FromDiscord | <Elegantbeef> Indeed it does not rely on a codepath to be hit to find a bug |
| 21:48:27 | FromDiscord | <Elegantbeef> type errors can lay dormant in python due to the fact the code path needs to be hit to emit an error |
| 21:48:39 | FromDiscord | <jviega> Exactly, I've seen them take months to fire |
| 21:49:11 | FromDiscord | <Elegantbeef> I also have an issue with Zig's lazy semantic analysis for this same reason |
| 21:49:59 | FromDiscord | <jviega> I remember a Typescript study from a few years ago that showed a 15% reduction in bugs, and anecdotally, most people like Beef and I here who have experience on both sides have measured a higher reduction |
| 21:50:05 | FromDiscord | <graveflo> unless you annotate it, or you design the code well, or you test it. Good python code, for example, is designed in such a way that you either annotate a type or you write the function such that it doesn't care what type you use. You don't make functions dependent on a structures interface you create structures that are built to interface with functions |
| 21:50:52 | FromDiscord | <jviega> You know that you have been able to do that in static type systems since 1969? And it's possible without writing types too. |
| 21:51:11 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=ctnTVjRXqpne |
| 21:51:18 | FromDiscord | <graveflo> of course, why wouldn't it be possible |
| 21:51:32 | FromDiscord | <jviega> And just because you don't like writing types doesn't mean you shouldn't. Some people think it's important info to communicate. |
| 21:51:43 | FromDiscord | <graveflo> I do write types |
| 21:52:03 | FromDiscord | <Elegantbeef> Even the haskell people write typeclasses 😄 |
| 21:52:09 | FromDiscord | <jviega> Here you go, 15% indeed. https://paperpile.com/shared/tlQYUA/download/502ddee4-693b-088d-8265-8f59aa403b39 |
| 21:52:35 | FromDiscord | <graveflo> but when I'm using a dynamic language I also write functions that are meant to be an interface not conform to the interface of the types I define |
| 21:52:47 | FromDiscord | <jviega> YOU CAN DO THAT IN STATIC LANGUAGES TOO |
| 21:52:51 | FromDiscord | <graveflo> I know |
| 21:53:07 | FromDiscord | <Elegantbeef> I don't know about jvg but I do not write dynamic language so I'm certainly heavily biased against them 😄 |
| 21:53:09 | FromDiscord | <jviega> So then what's your point? |
| 21:53:59 | FromDiscord | <graveflo> My point is they are both capable of doing the same thing. One imposes a restriction, the other doesn't. Clearly this restriction has no real function since they both can do it. Why have the restriction then? For compiling machine language. thats why |
| 21:54:51 | FromDiscord | <jviega> No, they both impose the same restrictions in terms of correctness. The differences are WHEN the restrictions are enforced, and what hinting the language asks for. |
| 21:55:03 | FromDiscord | <jviega> So you're just wrong on that too. |
| 21:55:10 | FromDiscord | <graveflo> yea always vs sometimes. One is less restrictive |
| 21:55:19 | FromDiscord | <jviega> Absolutely not. |
| 21:55:50 | FromDiscord | <Robyn [She/Her]> Duck typing is an example of what Graveflo means, right? Like how Python typically does it without mypy? |
| 21:56:07 | FromDiscord | <Robyn [She/Her]> "If it quacks like a duck, it must be a duck"? |
| 21:56:11 | FromDiscord | <Elegantbeef> > Why have the restriction then↵Static assurances |
| 21:56:15 | FromDiscord | <jviega> That's 100% possible in a staticly typed language, Robyn |
| 21:56:15 | FromDiscord | <graveflo> the strictly typed language always needs to know the type because it can't compute offsets and stuff without it. We both know what this is. |
| 21:56:46 | FromDiscord | <jviega> Nim's awfully close to providing it w/ concepts, it's odd that you have to go to an unofficial macro to go the final mile |
| 21:56:55 | FromDiscord | <graveflo> you're getting hung up on "its possible". Python is implemented in C. We know it's possible. thats not the point |
| 21:57:02 | FromDiscord | <jviega> The dynamic language always needs to know the type, unless you want random crashes. |
| 21:57:08 | FromDiscord | <jviega> C doesn't give a crap what the type is |
| 21:57:13 | FromDiscord | <jviega> And then you get random crashes |
| 21:57:17 | FromDiscord | <Robyn [She/Her]> In reply to @jviega "That's 100% possible in": With interfaces and concepts yeah |
| 21:57:25 | FromDiscord | <Robyn [She/Her]> I'm kinda lost on the convo so trying to catch up |
| 21:57:26 | FromDiscord | <jviega> When you type check is orthoganal to SOUND typing |
| 21:57:29 | FromDiscord | <graveflo> no dynamic languages don't need to know about the type. Thats the whole deal |
| 21:57:36 | Amun-Ra | sometimes would be gradual typing, not dynamic one |
| 21:57:36 | FromDiscord | <Elegantbeef> It does need the type |
| 21:57:46 | FromDiscord | <Elegantbeef> Why does `"hmm" + 10` error in python? |
| 21:57:47 | FromDiscord | <jviega> YES THEY DO, I have implemented many languages in my career. |
| 21:58:04 | FromDiscord | <Elegantbeef> Even JS has types |
| 21:58:04 | FromDiscord | <Elegantbeef> Last time I checked it emits a `TypeError` |
| 21:58:07 | FromDiscord | <jviega> If Python didn't know the type, Beef's example would end up w/ a crash |
| 21:58:38 | Amun-Ra | "hmm" + 10 is weak vs strong, not dynamic vs static |
| 21:58:41 | FromDiscord | <graveflo> In reply to @Elegantbeef "Why does `"hmm" +": when you put it like that yea |
| 21:58:42 | FromDiscord | <Elegantbeef> You need internal types to do operations else you just have integers |
| 21:58:51 | FromDiscord | <Elegantbeef> Amun it was not dynamic vs static |
| 21:58:55 | FromDiscord | <Robyn [She/Her]> In reply to @graveflo "no dynamic languages don't": Isn't that because they're typically interpreted? Python has PyObject in it's C API which has a type attached? |
| 21:58:55 | FromDiscord | <Elegantbeef> It was proving python has types |
| 21:59:24 | FromDiscord | <graveflo> yes I know about the internal implementation. We are talking about the restrictions of the system again. |
| 21:59:36 | FromDiscord | <Elegantbeef> If you pass a function to a function then call it how do you know what operation to do if you have no typing |
| 21:59:41 | FromDiscord | <jviega> "weak vs. strong" aren't formal terms in type theory with widely agreed on definitions. "Sound vs. unsound" is, and that's orthoganal to WHEN you check |
| 22:00:13 | FromDiscord | <jviega> But what do I know, I also have taught graduate programming languages and compilers at NYU a bunch over the years. |
| 22:00:23 | FromDiscord | <Elegantbeef> Eh I just say "good vs. bad" |
| 22:00:24 | FromDiscord | <Elegantbeef> 😄 |
| 22:00:32 | FromDiscord | <graveflo> In reply to @Elegantbeef "If you pass a": There is a semantic difference between defining that statically vs dynamically |
| 22:00:38 | Amun-Ra | "object language" isn't formal either |
| 22:00:48 | Amun-Ra | -ive |
| 22:01:01 | FromDiscord | <Elegantbeef> If an error that can easily be caught at compile time is allowed to get to runtime I consider that bad... yes I'm very biased |
| 22:01:16 | FromDiscord | <graveflo> then annotate the type |
| 22:01:41 | Amun-Ra | Elegantbeef: yes, that's one of the proc dynamic typing doesn't have |
| 22:01:42 | FromDiscord | <Elegantbeef> I mean I do since I write Nim and not python where not all libraries use `typings` |
| 22:01:43 | FromDiscord | <graveflo> in the dynamic language. Then you have what you want. Sometimes it's counter productive to do that so don't. |
| 22:02:07 | FromDiscord | <graveflo> well, like I said python is not ideal. It's just a good example |
| 22:02:40 | FromDiscord | <Elegantbeef> If any library I could import might cause me to lose static typing I do not care about static typing |
| 22:02:45 | Amun-Ra | def foo(x: print('foo')) -> None: pass |
| 22:02:54 | FromDiscord | <Elegantbeef> It's pretty simple that unless it's forced or inferred you do not have static typing |
| 22:02:59 | FromDiscord | <jviega> I'm not sitting here arguing that static typing is always right. I'm just saying you're objectively wrong about almost every single thing you're stating as fact, from the error rate issue, to how these things are implemented. |
| 22:03:09 | FromDiscord | <girvo> The amount of unit tests necessary to make dynamic languages work at scale just to catch invariants that a type system in a static language makes it untenable. Signed: I’ve been doing this professionally 17 years, and used PHP JS and Python. Errors at runtime that can be caught at compile time is such a waste |
| 22:03:17 | Amun-Ra | python typing system is just a hint, like typescript one |
| 22:03:50 | FromDiscord | <Elegantbeef> Atleast the way I see it is that if any subset of your program does not use type annotations you lose any benefit of your type safety |
| 22:04:47 | FromDiscord | <graveflo> if you define type safety as statically typed then yes. but at that point its just circular logic |
| 22:04:53 | FromDiscord | <jviega> Yeah, and Python's SUCKS because it got shoehorned in so late in its life. Had to work around the rest of the language |
| 22:06:04 | FromDiscord | <jviega> I don't define type safety as statically typed. Almost no languages are fully statically typed anyway. Things like inheritance require dynamic type information and checks. |
| 22:06:18 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 22:06:39 | * | antranigv joined #nim |
| 22:07:16 | FromDiscord | <jviega> I don't use the term "type safe" because most people don't have a good firm definition of that. I'd say you want a "sound" type system, which means "all type errors get caught", but the % that get caught statically vs dynamically will vary based on language. |
| 22:07:36 | FromDiscord | <jviega> Soundness is orthogonal to when type errors are found |
| 22:08:47 | FromDiscord | <jviega> And again, yes, there are languages that don't even bother to try to address the problem until runtime, but most languages do some dynamic type checking, not just the ones you think of. |
| 22:08:54 | FromDiscord | <girvo> Typescripts unsoundness doesn’t matter in practice most of the time, and it can still give you module level type safety. In the “unsound but still useful” it’s one of the better ones, albeit not perfect. |
| 22:11:22 | FromDiscord | <jviega> I don't know why I get so riled up when people assert things as fact where they clearly don't know what the F they're talking about. I should have made peace with Dunning Kruger by now. |
| 22:12:09 | FromDiscord | <graveflo> I think you are just getting overly upset. If I said something wrong I prob just misspoke or you misunderstood. This isn't complicated |
| 22:13:05 | FromDiscord | <jviega> I'm not upset in the slightest; it's the opposite, I have fun telling people they're just 100% wrong (the way you are here), which is why I'm absolutely wasting time I should be doing other things. |
| 22:13:43 | FromDiscord | <jviega> But only when they're acting like experts in areas where they clearly are far from it 😉 |
| 22:13:46 | FromDiscord | <Elegantbeef> I mean I'm openly biased to the fact that types should protect you at compile time |
| 22:13:46 | FromDiscord | <Elegantbeef> What is the point of dicking around with types if you have to run the code to get protections |
| 22:13:47 | FromDiscord | <Elegantbeef> To me that's the no different to going "Oh it's raining, better put my rain boots on my head" |
| 22:13:47 | FromDiscord | <Elegantbeef> You get the intention but you failed the execution |
| 22:13:48 | FromDiscord | <Elegantbeef> Right but even with inheritance you cannot do `int(someInheritedType)` |
| 22:13:49 | FromDiscord | <Elegantbeef> There are still reasonable type protections that the static system can provide |
| 22:13:49 | FromDiscord | <Elegantbeef> Can you convert to the wrong type due to lacking information, yes. Can you migrate to a completely different family tree... not without `cast` 😄 |
| 22:13:51 | FromDiscord | <Elegantbeef> Heh, I'm just a numpty with a keyboard |
| 22:13:51 | FromDiscord | <Elegantbeef> So what I say hardly matters |
| 22:13:51 | FromDiscord | <Elegantbeef> Give me a soapbox and I'll ramble until the street is empty |
| 22:13:52 | FromDiscord | <Elegantbeef> Then I'll ramble further |
| 22:13:52 | FromDiscord | <Elegantbeef> I know why, but I'm still completely baffled by the fact TS has no overloading |
| 22:13:54 | FromDiscord | <Elegantbeef> Sorry 😄 |
| 22:13:56 | FromDiscord | <jviega> Wow, welcome back |
| 22:14:17 | FromDiscord | <graveflo> well the most you've been able to prove is that you claim "X years of experience" and "statistics" and "this one time it was really bad error" |
| 22:14:26 | systemdsucks | wtf was that lag? |
| 22:15:58 | FromDiscord | <jviega> False, I linked you to a paper, and I can point you at 20 more. But if you really want to become an expert, then go get some basic understanding. Go back to the old Carelli and Abadi papers |
| 22:18:21 | FromDiscord | <aziz6004> sent a long message, see https://pasty.ee/UTnhrAfuOBbc |
| 22:18:54 | FromDiscord | <saint.___.> Lol |
| 22:23:13 | FromDiscord | <Robyn [She/Her]> That's... Pathetic of you to use a genuine crisis to line your pocket via spam |
| 22:23:23 | FromDiscord | <saint.___.> <@&371760044473319454> |
| 22:23:46 | FromDiscord | <Robyn [She/Her]> They're already on it I think |
| 22:24:03 | FromDiscord | <jviega> If I wanted to argue for preferring full dyanmic typing, I absolutely could, BTW. Data tends to indicate that in Python, only about 5% of the bugs that make it to production tend to be type errors, maybe less. Like I said, I have no problem w/ people preferring one paradigm, it's just that you're so spectacularly uninformed but acting like you're an expert. |
| 22:24:59 | FromDiscord | <graveflo> who are you trying to impress? What did I say that was so wrong then? |
| 22:26:49 | FromDiscord | <jviega> Nobody, just hoping you'll actually go educate yourself and not assert things as fact where you have little expertise. The entire conversation has been about you being wrong, ask ChatGPT to summarize the instances for you if you are incapable of doing it for yourself 🙂 |
| 22:27:15 | FromDiscord | <graveflo> nah you're just power tripping. but w/e |
| 22:28:01 | FromDiscord | <jviega> No, I'm in no position of authority here whatsoever 🙂 |
| 22:28:37 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 22:29:08 | FromDiscord | <Phil> In reply to @girvo "Typescripts unsoundness doesn’t matter": ~~It doesn't matter in practice because I pull out the ruler when somebody starts using `any` explicitly or implicitly in TS~~ |
| 22:29:23 | FromDiscord | <Phil> (edit) "In reply to @girvo "Typescripts unsoundness doesn’t matter": ~~It doesn't matter in practice because I pull out the ruler ... when" added "for hitting evil people with" |
| 22:29:36 | FromDiscord | <girvo> Pfft any is a compile error in our code bases lol |
| 22:29:41 | FromDiscord | <girvo> Including any dependency |
| 22:30:03 | FromDiscord | <Phil> Not sure on dependency since I can't know what all the fuck angular is using on my end |
| 22:30:20 | FromDiscord | <Phil> But the rule of any being a compiler error seems compelling.↵Forgot that that could be an option |
| 22:30:35 | FromDiscord | <girvo> Yee it’s well worth turning it on and seeing what you get! |
| 22:30:51 | FromDiscord | <girvo> Will show you places it might’ve crept in, even if you turn it off again afterward |
| 22:31:08 | FromDiscord | <girvo> But Angular is pretty good, doesn’t use any but does use unknown which is better |
| 22:31:58 | FromDiscord | <Phil> In reply to @graveflo "nah you're just power": Ma man, that's my job on this server, ruthlessly abusing my privileges and so on |
| 22:32:45 | Amun-Ra | Phil: speaking of ts typing system, have you seen that? https://matt-rickard.com/typescript-type-system-hacks |
| 22:33:29 | FromDiscord | <Phil> I have in fact not.↵Work stuff I tend to not expose myself tooooo much of in my spare time, which I count TS towards when I'm not having my own project |
| 22:34:06 | FromDiscord | <Phil> Sidenote: I really need to either shell out for copilot or get myself something similar.↵The amount of boilerplate-y code it auto-writes for you is really nice+ |
| 22:34:09 | FromDiscord | <Phil> (edit) "nice+" => "nice" |
| 22:35:25 | FromDiscord | <Phil> Just as a general timesaver I've started tremendously appreciating what it does at work.↵It would be even nicer if it weren't near 100% certain that the datasets it was trained on were violating licenses left and right, |
| 22:35:26 | FromDiscord | <jviega> Wow there's some crazy stuff in there |
| 22:36:06 | * | antranigv joined #nim |
| 22:43:55 | FromDiscord | <graveflo> Alright I have an idea of how we can get to the bottom of this if you are still interested. If we are comparing a string statically typed language vs a dynamically typed language that has type annotations and proper linting are there bugs that the annotated dynamic language would fail to catch while the statically typed one would? |
| 22:44:07 | FromDiscord | <graveflo> (edit) "string" => "strong" |
| 22:47:24 | FromDiscord | <jviega> "Get to the bottom of this" where "this" is what? |
| 22:47:27 | FromDiscord | <Robyn [She/Her]> In reply to @isofruit "Sidenote: I really need": Look into Codeium and TabNine? |
| 22:47:43 | FromDiscord | <Robyn [She/Her]> Also CodeClippy |
| 22:51:20 | FromDiscord | <jviega> sent a long message, see https://pasty.ee/smFiUZhYEncr |
| 22:52:14 | FromDiscord | <jviega> And again, languages like ML don't require you to write any type ever, yet find all type errors before running. |
| 22:54:11 | FromDiscord | <graveflo> sometimes you just have to accept an a mutually understood concept even if they are not formally defined. It seems you understand what I meant when I said "proper linting". So you are saying it is possible for that dynamic language to be capable of finding all the same types of error at the time of linting in that case. Okay, just wanted to make sure I wasn't missing anything |
| 22:54:37 | FromDiscord | <jviega> No, I'm saying you're adding words that are not even remotely germane to anything being discussed. |
| 22:55:06 | FromDiscord | <graveflo> what the "proper linting" thing? Those were my words |
| 22:56:37 | FromDiscord | <jviega> Right, I am talking about things that are well defined to the point of formalized with math underpinning most of the results from the last half century. That might apply for some type of non-type system-based error checking, but that has been part of 0% of the conversation. |
| 22:56:58 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 22:57:34 | FromDiscord | <jviega> If you want to talk about the "impact of linting" you'd have to get a lot more specific to make it even remotely relevent. |
| 22:57:52 | FromDiscord | <graveflo> It's the fist thing that I said. I said that a dynamic language with hinting and linting has everything you need to get the static error checking. |
| 22:58:20 | FromDiscord | <jviega> "And linting" adds exactly 0 meaning. |
| 22:58:37 | FromDiscord | <graveflo> ok that's fine. I'll stop bugging you then |
| 22:59:18 | FromDiscord | <jviega> It's not bugging me |
| 22:59:28 | FromDiscord | <jviega> I'm happy to discuss this stuff |
| 23:00:30 | FromDiscord | <khazakar> Eh, typing topic. Don't get me started on python with mypy at work, where I need to fix 500+ findings, and second that with pylint ones |
| 23:00:38 | FromDiscord | <jviega> Personally, w/ Python I'm not sure the pain of using their annotations is worth it unless you're building a large scale system. And if you don't use them for everything, their value is a little dubious. |
| 23:01:03 | FromDiscord | <jviega> The system is so klunky the work created isn't worth the benefit for me personally |
| 23:01:10 | FromDiscord | <khazakar> As of typing enforcement, beartype or type guard gets you covered |
| 23:01:18 | FromDiscord | <jviega> Tho rational people have different opinion |
| 23:01:19 | FromDiscord | <khazakar> (edit) "type guard" => "typeguard" |
| 23:01:26 | FromDiscord | <jviega> (edit) "opinion" => "opinions" |
| 23:02:28 | FromDiscord | <graveflo> I usually annotate in python if I am wiring a function that is purpose built or has no regard for other types |
| 23:03:01 | FromDiscord | <khazakar> Other than that, usage of non statically typed langs at larger scale than small size projects like simple full stack, wrappers around libraries and so on will bite you quickly in the ass |
| 23:03:17 | FromDiscord | <khazakar> In reply to @graveflo "I usually annotate in": I must annotate at work. More the better |
| 23:03:53 | FromDiscord | <jviega> Well, not according to Graveflo 🙂 |
| 23:04:51 | FromDiscord | <khazakar> But problem with type annotations in python is that even tooling around typing itself can be biting you hard af |
| 23:05:01 | FromDiscord | <khazakar> Mypy strict mode, brrrr |
| 23:05:17 | FromDiscord | <khazakar> (edit) "be biting" => "bite" |
| 23:05:50 | FromDiscord | <jviega> Being bolted on a quarter century later, it's quite a monstrosity. I am not a fan. |
| 23:06:54 | FromDiscord | <khazakar> At least you can speed up this chore by using tools like mypy, ruff or pylyzer |
| 23:07:07 | FromDiscord | <graveflo> In reply to @jviega "Well, not according to": well yea there are instances where you are intentionally writing code that doesn't care what the type is. It's an abstraction |
| 23:07:19 | FromDiscord | <khazakar> For linting (ruff) and type checking (mypy and pylyzer/ |
| 23:07:25 | FromDiscord | <khazakar> (edit) "pylyzer/" => "pylyzer)" |
| 23:07:47 | FromDiscord | <khazakar> In reply to @graveflo "well yea there are": Then you probably didn't saw how generic types work 😉 |
| 23:08:08 | FromDiscord | <jviega> No, being generic to work across multiple types should still be a type. This is a type of polymorphism called parametric polymorphism |
| 23:08:50 | FromDiscord | <khazakar> And for that we have TypeVars etc in python 😉 |
| 23:09:09 | FromDiscord | <jviega> Pretending otherwise is where you end up accidentally running code that tries to execute `"foo" + 12` in Python |
| 23:09:22 | * | antranigv joined #nim |
| 23:22:10 | systemdsucks | yeah it's nice to check things befor running them |
| 23:24:34 | * | xet7 joined #nim |
| 23:25:50 | FromDiscord | <khazakar> Yup |
| 23:25:55 | FromDiscord | <khazakar> Independent of language |
| 23:26:11 | FromDiscord | <khazakar> That's why we should use type checkers and linters |
| 23:30:10 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
| 23:34:29 | * | antranigv joined #nim |
| 23:39:04 | * | oprypin quit (Quit: Bye) |
| 23:39:14 | * | oprypin joined #nim |
| 23:55:31 | * | antranigv quit (Quit: ZNC 1.8.2 - https://znc.in) |
