04:08 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1164384627838959646/image.png?ex=654304b0&is=65308fb0&hm=348be039fd8c808751faebf9b36721a18934ba90292700993810481f610fc6ce& 05:18 < bridge> https://tenor.com/view/thats-okay-larry-david-bernie-sanders-saturday-night-live-handshake-gif-16694855 05:20 < bridge> almost a perfect meme if the bottom right actually wrote SSL instead of SNL lmao 08:03 < bridge> Gm:feelsbadman: 08:28 < bridge> ☕ 08:31 < bridge> Morning 🍵 09:58 < bridge> @jupeyy_keks have any controversial or interesting topics crossed your mind today? 10:01 < bridge> https://youtu.be/sHzdsFiBbFc?si=izInuKUPozRlt3ki 10:01 < bridge> This for example? 10:01 < bridge> very interesting web development 10:05 < bridge> GM 12:07 < bridge> Yes. When do robots finally replace my boring useless work 12:37 < bridge> Interesting. A war could help 12:39 < bridge> In times of need people will be forced to innovate. 12:39 < bridge> Let's start a war 12:39 < bridge> No 12:39 < bridge> This is a common miss thinking 12:40 < bridge> The golden ages for humans were in longer peace times 12:40 < bridge> what do u do at work 12:40 < bridge> Coding xd 12:41 < bridge> Welp I mean if everything is at peace and everyone is happy then it's good and people have free time. 12:41 < bridge> to think of new things 12:41 < bridge> Yes. In fact most innovative ppl are not poor 12:41 < bridge> the world is ending 12:41 < bridge> So pressure is not a motivator 12:42 < bridge> So ideas come from boredom ig 12:42 < bridge> Mb 12:42 < bridge> I think they come only from motivation 12:43 < bridge> But having to think about, if u can manage life, does not help 12:43 < bridge> E.g. being poor and forced to work 12:43 < bridge> Hmm true 12:45 < bridge> My classmate says necessities makes inventions 12:46 < bridge> I'm really not sure about it. We have enough knowledge to print houses etc. But we don't do it 12:46 < bridge> Because rich society and/or politics doesnt seem interested 12:47 < bridge> It isn't necessary to print houses 12:47 < bridge> Doesn't have enough gains 12:47 < bridge> Rich Africans dont built wells 12:48 < bridge> I'd say it's a matter of motivation to see the problems and actually wanting to solve them. And it's a societally effort 12:49 < bridge> Some problems are simply complex and need lot of workers etc 12:50 < bridge> But yes i could imagine that this could at least be a starting factor to talk about it more 12:50 < bridge> Like if climate crisis hits harder. We will think about it more. But if we unlucky it will actually even demotivate ppl 12:50 < bridge> We'll see 12:51 < bridge> I guess there is no definite answer^^ 12:51 < bridge> thx for convo school is boring ^^ 12:52 < bridge> I might just invent something new 12:52 < bridge> Creating something is also a matter of discipline 12:53 < bridge> Sometimes it's hard and annoying and boring 12:53 < bridge> And if u give up because of that.. rip 12:58 < bridge> There are a couple things that were greatly accelerated by war and insane war budgets. The jet engine and radar technology both come to mind. Also the tiny vacuum tube transistors the US got made. 13:00 < bridge> Isn't it just less efficient than the precast concrete buildings we make nowadays? 13:04 < bridge> I bet the science behind these technologies were invented long before and probably not even by the military 13:04 < bridge> So the missing piece was cheap labor force or whatever was expensive about these processes 13:05 < bridge> That's true. Most was already discovered. Just needed the stupid levels of war budget 13:06 < bridge> Depends on the size of the buildings i guess. But in the end it probably also doesn't matter how high the price is.. at least in European countries u are probably low on humans rather than money xd 13:08 < bridge> I'd actually argue it's neither money nor labour. It's just not good for the old people in charge to build more. If they build more their own homes lose value 13:09 < bridge> Xd 13:09 < bridge> If they needed workers they would import them from wherever. When germany needed workers turkey was happy to oblige 13:09 < bridge> True 13:26 < bridge> As @gotroyb / (@gotroyb) would say C99 is the best language to build upon. But it still has problems. :tee_thinking:. So if the best things have problems why do invent new things which are easier to grasp at first but got more problems? Maybe it's because we want ppl to use smt that will not inovate things. (btw do not take this serious I just typed a word which would make sense after the previous with the context.) 13:27 < bridge> As @gotroyb / (gotroyb) would say C99 is the best language to build upon. But it still has problems. :tee_thinking:. So if the best things have problems why do invent new things which are easier to grasp at first but got more problems? Maybe it's because we want ppl to use smt that will not inovate things. (btw do not take this serious I just typed a word which would make sense after the previous with the context.) 13:28 < bridge> I read the msg and I can't remember a single word 13:28 < bridge> C best language tho 13:28 < bridge> See this ```I just typed a word which would make sense after the previous with the context.``` worked 13:28 < bridge> ghostGPT 13:28 < bridge> It was I. 13:34 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1164526893073170442/RDT_20231019_1333546757833912248675785.jpg?ex=6543892f&is=6531142f&hm=a945eb2105ce21256ecb29d9f07d9b08a7ab1160916fd348d80a7a44fdc44caa& 13:35 < bridge> Most annoying thing (my opinion) with not C programming languages is that they don't actually fix the many problems C has but instead add many other and very annoying problems. So, in the end, C is still a very good option, which is sad, because something with less problems would worth it (if it actually has less problems). 13:36 < bridge> wrong opinion 13:37 < bridge> rust fixes the biggest issue with C, it prevents memory unsafety (not totally, but an improvement is better than nothing), it also helps preventing data races 13:37 < bridge> u just dont want to accept progress 13:38 < bridge> the only place where rust is less right now is: support for obscure platforms (which is not a problem of the language itself, but a problem of the compiler backend implementation), and compile times (atleast vs C which compiles fast iirc) 13:38 < bridge> many lagn 13:38 < bridge> many lang does fix lol 13:38 < bridge> rust is as fast as C 13:39 < bridge> just you'll loose stuff such as performance 13:39 < bridge> (gc etc...), but rust does fix C issues without loosing perf 13:42 < bridge> Rust doesn't have the simplicity and the clarity C code can have (as I understand Rust by now) and that has great value by me. I'd better debug clearly-written programms instead of a big complicated stuff that its (only?) good is that is does not do invalid memory accesses and runs fast. 13:42 < bridge> Rust doesn't have the simplicity and the clarity C code can have (as I understand Rust by now) and that has great value for me. I'd better debug clearly-written programms instead of a big complicated stuff that its (only?) good is that is does not do invalid memory accesses and runs fast. 13:42 < bridge> the clarity of C is a double edge 13:42 < bridge> it hurts you more than not 13:42 < bridge> @gotroyb be honest, did u code rust for at least 6 months? xd 13:43 < bridge> but by what ur saying it shows u rly havent tried rust 13:43 < bridge> jupstar was the same 13:43 < bridge> :justatest: 13:43 < bridge> tbh Rust is hard when you start 13:43 < bridge> i think 13:43 < bridge> but after it's pure enjoyment 13:43 < bridge> C is hard too if u dont know C like langs 13:43 < bridge> i was always pro rust. and tbf i still think some things are annoying xd 13:43 < bridge> no u werent, i remember u not knowing rust 13:43 < bridge> i'm less of a fanboy than u xd 13:43 < bridge> xd 13:44 < bridge> i also acknowledge annoying things in rust 13:44 < bridge> and whish to be fixed 13:44 < bridge> @ryozuki send good rust books 13:44 < bridge> yes but i learned it, because i accepted that i should learn it xd 13:44 < bridge> yes but C is very small and "easy", like there's ,ot much stuff to learn tho. Only the way devs will write their code will make things harder 13:44 < bridge> the oficial rust book 13:44 < bridge> 13:44 < bridge> https://doc.rust-lang.org/book/ 13:44 < bridge> atomics 13:44 < bridge> https://marabos.nl/atomics/ 13:44 < bridge> and https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/ 13:44 < bridge> C is hot asf. Best language ever conceived 13:45 < bridge> wdym by that? 13:45 < bridge> It's proof of intelligent creation 13:45 < bridge> @ryozuki xddd 13:45 < bridge> rust is, its proof of improvement without a sacrificy thought to be needed (runtime speed with gained safety) 13:45 < bridge> ho lol the atomics book is definetly smth I need to read lmao 13:45 < bridge> read it, its one of the best books 13:45 < bridge> ty 13:45 < bridge> its online btw 13:46 < bridge> yeah saw 13:46 < bridge> windows is largely written in C++ afaik 13:46 < bridge> if you have a living standard that allows you to not care too much about money.. u can concentrate more about being innovative 13:46 < bridge> You meant C, right? 13:46 < bridge> scratch :giga_chad: 13:46 < bridge> I remember that I was learning OpenGL using C, but then learned about Rust and that felt that it could do things better and "clearer", like "match" etc, but I got annoyed by its pursue to hide complexity by introducing more complexity. 13:46 < bridge> It's the pursuit of every modern language. Extreme abstraction 13:47 < bridge> i think rust's enums are one of the coolest things. they are a clean way to represent variants 13:47 < bridge> match is at least as clean as a switch 13:48 < bridge> True. Rust enums are probably the best thing about rust after the way errors are handled 13:48 < bridge> I mean I'd better write `if (a > 0) { ... } else if (a < 0)` instead of `use std::signs; match signs::of(num) signs::Positive: ... signs::Negative: ...` 13:48 < bridge> in the context of enums actually cleaner, bcs you can only handle the data if you match the enum 13:48 < bridge> 13:48 < bridge> 13:48 < bridge> not like switch a.type {...} 13:48 < bridge> C code is not "simple" for me. e.g. any addition can invoke UB 13:48 < bridge> There isn't a single thing I hate more than exceptions in programming I think 13:49 < bridge> but u can do that 13:49 < bridge> i'd also not write the sign stuff xD 13:50 < bridge> C is not simple if u know its a minefield 13:50 < bridge> im never too sure about anything 13:50 < bridge> so that's why we have -wno-exceptions in ddnet xdd 13:50 < bridge> whereas i rust i am 13:50 < bridge> wdym by exceptions? automatically propagated errors? errors not appearing the type signature? 13:50 < bridge> When use is_odd and is_even crate? 13:50 < bridge> xdd 13:50 < bridge> C *does* have its problems and they are not tiny. But alternatives seem worse to me. 13:50 < bridge> honestly, you can write rust code that is pretty similar to c, u just have to accept using unsafe 13:51 < bridge> Also Ada has safety features etc without overcomplicating everything. 13:51 < bridge> unsafe still has strong guarantee s 13:51 < bridge> Btw what happened to carbon? 13:51 < bridge> pointers alone can easily destroy most of these (if you really want to).. not saying it is good 😄 13:51 < bridge> but of u dont know what u doing it can be a stronger minefield 13:51 < bridge> I hate both aspects. If you HAVE to have an exception system in your language it shouldn't have automatic propagation and you should be forced to enumerate all possible errors from every function 13:52 < bridge> it seems to me that rust isn't "overcomplicating" C, to me it's what has to happen inside my brain in order to write C, but it's not chhecked there 13:52 < bridge> does ada have protection against dangling pointers? afaik no 13:52 < bridge> Exceptions lead to "Unhandled Exception"s. Always 13:52 < bridge> yes but in unsafe rust code u need to uphold to more stuff than in C, you need to make sure safe code cant do ub 13:52 < bridge> just announced so far. creator told us to use rust if we want a usable language right now 13:53 < bridge> so java's checked exceptions are actually a step up from C++'s unchecked ones? I tend to agree 13:53 < bridge> So I can sell simplicity for longer compile times? What would that worth it? 13:53 < bridge> my point is really. if u just wrap everything in unsafe, u can write code similar to c.. with some differences ofc. but it feels similary low level 13:53 < bridge> So I can sell simplicity for longer compile times? What would that worth? 13:53 < bridge> Have you tried zig? It's not the worst 13:53 < bridge> I don't think you'll get longer compile times if you write a better-C dialect of rust 13:53 < bridge> the long compile times come from using the non-C features 13:54 < bridge> what problem of C would that solve? 13:54 < bridge> I've also enjoyed D, but haven't used for any significant time 13:54 < bridge> Borrow checker might help 13:55 < bridge> haven't actually tried it, but its syntex felt annoying (not a too serious problem tho) 13:55 < bridge> the problem that no one seems to be able to write safe, nontrivial C programs 13:55 < bridge> inb4 "I can" 😉 13:55 < bridge> @gotroyb i generally agree that compile times are a problem of rust. 13:55 < bridge> 13:55 < bridge> But on the other side. since u have a really great ecosystem it's easy to add high quality libraries to your project, it works cross platform. that alone saves lot of time often 13:55 < bridge> I can 😉 13:55 < bridge> x 13:55 < bridge> in my current rust project i have not a single build script.. yet everything works 13:55 < bridge> I can do just a printf("Hello world\n); & consider it safe 13:56 < bridge> I can do just a printf("Hello world\n"); & consider it safe 13:56 < bridge> Nontrivial 13:56 < bridge> ah 13:56 < bridge> just think harder lul 13:56 < bridge> let's add network interaction so we have a threat model? 13:57 < bridge> or do you have an example in mind? 13:57 < bridge> It's actually an unfalsifiable statement. If I wrote one it would be an exception rather than the rule 13:57 < bridge> why unfalsifiable? 13:57 < bridge> Well, C programs don't just magically work just because I write them, I think that the effort spent making them complete is worth it instead of overcomplicating things by adding a ton of other names etc. 13:58 < bridge> but C programs seem to magically have security vulnerabilities 🙂 13:58 < bridge> Well your initial statement would be disproven since you said no one. But you'd quickly update it to "not many people" and everyone will clap and I'll have wasted a couple dozen hours of my life 13:58 < bridge> @learath2 tbh my biggest problem with exceptions is not using them together with RAII. 13:58 < bridge> 13:58 < bridge> that often leads to weird bugs, even if u handle exceptions. 13:58 < bridge> 13:59 < bridge> Java imo is a good example 13:59 < bridge> c++ at least in this case is actually better 13:59 < bridge> (and ofc it's hard to do it right, generally) 14:00 < bridge> The way raii and exceptions interact is also quite hard for a new learner. Overall very meh feature 14:00 < bridge> you also have that in rust, "panics" 14:00 < bridge> One guy that worked on a Rust-written GNU-coreutils implementation said that GNU-coreutils has had just a few vulerenabilities in so many years and that they are not rewritting them in Rust for security reasons. 14:01 < bridge> I think even glibc recently had an exploitable bug 14:01 < bridge> The argument is always that some of those vulnerabilities couldn't have happened with rust 14:01 < bridge> Rust also has had many vulerenabilities itself? not necessary memory-related 14:02 < bridge> The argument against that one is that Rust doesn't claim to eliminate all errors. It eliminates a couple classes of errors 14:02 < bridge> IME the bugs that rust reports are usually things that wouldn't even be classified as bugs in C 14:03 < bridge> i'd say rust tries to force you to make a better design over your program. 14:03 < bridge> 14:03 < bridge> it e.g. doesn't prevent dead locks, but with a clear hierarchy you could evade most of these problems 14:03 < bridge> 14:03 < bridge> Memory safety is given in safe rust. that eliminates many problems. 14:03 < bridge> 14:03 < bridge> If you use Arc only with the said hierarchy you also should fall into traps like memory leaks 14:03 < bridge> overall rust at least helps you. it doesnt enforce everything that is needed to say it's the 100% safe alternative, but that's probably also not its goal 14:03 < bridge> see e.g.: https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html 14:03 < bridge> two links that appear from the ddg search for "rust cve" 14:04 < bridge> i'd say rust tries to force you to make a better design over your program. 14:04 < bridge> 14:04 < bridge> it e.g. doesn't prevent dead locks, but with a clear hierarchy you could evade most of these problems 14:04 < bridge> 14:04 < bridge> Memory safety is given in safe rust. that eliminates many problems. 14:04 < bridge> 14:04 < bridge> If you use Arc only with the said hierarchy you also should not fall into traps like memory leaks 14:04 < bridge> both of these would probably be considered "working just fine" in C/C++ 14:04 < bridge> Personally, I'm not ready to sell C's simplicity for Rust's safety. I might be if I got fed up with C unsafety. But doesn't seem very likely to me now. 14:04 < bridge> give examples 14:04 < bridge> C isn't simple. it only looks simple before you know all the UB stuff 14:05 < bridge> i don't want to lie. alone the fact that rust has RAII and c not. already makes so much stuff simpler 14:05 < bridge> i dont see what u mean with simplcity 14:05 < bridge> in c u code everything, even stuff that i'd call intuitive 14:05 < bridge> destructors are actually a thing that C really lacks 14:05 < bridge> it'd be really nice if you could just `defer free(a);` in C 14:06 < bridge> like in go 14:06 < bridge> I think there's a gcc extension for this 14:06 < bridge> C is absolutely trivial compared to Rust. The UB stuff is unexpected but C just doesn't have the depth to compare to Rusts complexity 14:06 < bridge> You can't have a box pin dyn send sync 14:06 < bridge> it's not simple to program in, and it doesn't have a simple model for your mind 14:06 < bridge> libtw2 also doesn't have that 14:07 < bridge> glib, however, has self-built vtables 14:07 < bridge> which I'd consider less simple than compiler support 14:07 < bridge> I prob remember some CVE's like you sent. I remember something about directory recursive deletion but maybe we'd just forget it for the current conversation, not a big deal even if rust had no CVEs 14:08 < bridge> the directory deletion thing would be considered "no bug" in C/C++ 14:08 < bridge> the C++ std says that concurrent access to the filesystem is UB 14:08 < bridge> completely insane 14:08 < bridge> I mean, is it really? It's less simple when programming but it's actually far more intuitive. Vtables are a very simple thing hidden behind lots of magic 14:09 < bridge> yes. just like having functions is more simple than having to invent your own calling conventions in x86 asm, e.g. 14:09 < bridge> It builds generally with a simple way upon what it has. So using C you get access to what C has with a "direct way". 14:10 < bridge> or stack variables are easier than manual stack management, structs are easier than only having access to primitive types 14:10 < bridge> C's idea of strings is also very bad, and not very performant 14:11 < bridge> for example, C gives you access to the filesystem (with libc let's say) but doesn't actually care what it does on higher level. 14:11 < bridge> Actually idk how I let this one sneak by, just because you don't program like that doesn't mean no one does. You'll absolutely see a pin box dyn send sync hashmap box box pin 14:12 < bridge> not sure what you mean by this. rust gives you access to the file system in the same way 14:12 < bridge> I've been able to avoid it (in non-work related settings) 🤷‍♀️ 14:12 < bridge> hmm, maybe not 14:12 < bridge> the mastersrv 14:13 < bridge> Also this I disagree with. You could say that the abstract machine has very little to do with the modern machines but it is an absolutely trivial machine 14:14 < bridge> I disagree. the rules around integer overflow, type promotion, pointer validity rules, all disagree with the simple model 14:14 < bridge> I mean that it's relation to the OS/filesystem is simple and clear, but the programmer has to take care of correctness. I'm not ready to accept much complexity so that I don't fall into incorrect behaviours. 14:14 < bridge> note that C's standard library actually buffers your files by default 14:15 < bridge> so you're not even close to the OS there 14:15 < bridge> I was thinking about systems calls rather than library calls. 14:15 < bridge> system calls have little to do with C 14:16 < bridge> you can do system calls from all sorts of languages, including C, rust, … 14:16 < bridge> I did say libc but i was thinking about making available the `open(2)` function e.g. 14:16 < bridge> which is then implemented as `openat` 14:16 < bridge> All languages have those available, C's wrappers are just very thin usually 14:16 < bridge> doesn't sound very transparent 14:17 < bridge> you can absolutely make these syscalls from rust, too. I participated in a rust stdlib rewrite using the syscalls directly 14:17 < bridge> was pretty fun 🙂 14:18 < bridge> Using `open(2)`'s model is enough for many cases. Knowing all the details isn't something very practical. 14:18 < bridge> Using them from C seems more enjoyable. 14:19 < bridge> We just seem to disagree about the level of abstraction. I like my wrappers thin. Rust people like them thick and featureful 14:19 < bridge> C is a bit preferred here, not because it's a good language, but because it was chosen (maybe implicitly) to be the model for POSIX interactions 14:19 < bridge> rust's `File` is less of an abstraction than C's `FILE *` 14:20 < bridge> but it actually works well on windows and linux ^^ 14:20 < bridge> I prefer C over Rust, it's not that Rust is useless compared to C (Rust solves *many* problems C has) but I don't like Rust's solution to those problems. 14:22 < bridge> I think `open(2)` existed already because of historical reasons?, so even if under the hood things changed, `open(2)` is still useful. 14:22 < bridge> `open(2)` still exists 14:22 < bridge> But even if it isn't, `openat(2)` is available. 14:23 < bridge> the syscall `open` still exists 14:23 < bridge> it's just not called by the glibc function `open` anymore 14:23 < bridge> I would be very very very surprised if it's not about the same level given they provide similar features 14:24 < bridge> The only way I can imagine it being a lower level abstraction is cheating like msvcrt 14:24 < bridge> C's `FILE *` has buffering 14:24 < bridge> rust's `File` is just a file descriptor 14:25 < bridge> If what `open(2)`'s manual fit's the programmer needs, then what it does in detail is not important imo. 14:25 < bridge> (rust's `File` is literally 4 byte in size on linux) 14:25 < bridge> it's not just a thin wrapper over the `open` syscall then, though 14:25 < bridge> it's about as thin as the `File::open` function in rust 14:26 < bridge> As far as the standard is concerned what is buffering even? 14:26 < bridge> idk, you're the standard person 😄 14:26 < bridge> but it even has functions for adjusting the buffer 14:26 < bridge> in the standard 14:27 < bridge> FILE could be whatever the implementor wants. Msvcrt uses that to implement it through a fake fileno table 14:27 < bridge> fact is, `FILE *` is buffered in all libcs that I know 14:27 < bridge> do you know any where it's not? 14:27 < bridge> musl, glibc, msvcrt all buffer AFAIK 14:27 < bridge> wtf r u guys all even doin with filesystems xddd 14:27 < bridge> 14:27 < bridge> i need open file, write file 14:27 < bridge> maybe some helper functions like list directory 14:27 < bridge> r u like coding the next sql database xdd 14:28 < bridge> list directory is not available in C 14:28 < bridge> tru 14:28 < bridge> times before c++17 were hard 14:29 < bridge> > Besides the system-specific information necessary to access the device (e.g., a POSIX file descriptor), each FILE object directly or indirectly holds the following: 14:29 < bridge> > 14:29 < bridge> > 1. (C95) Character width: unset, narrow, or wide. 14:29 < bridge> > 2. (C95) Parse state for conversions between multibyte and wide characters (an object of type mbstate_t) 14:29 < bridge> > 3. Buffering state: unbuffered, line-buffered, fully buffered. 14:29 < bridge> > 4. The buffer, which may be replaced by an external, user-provided buffer. 14:29 < bridge> > 5. I/O mode: input, output, or update (both input and output). 14:29 < bridge> > 6. Binary/text mode indicator. 14:29 < bridge> > 7. End-of-file status indicator. 14:29 < bridge> > 8. Error status indicator. 14:29 < bridge> > 9. File position indicator, accessible as an object of type fpos_t, which, for wide streams, includes parse state. 14:29 < bridge> > 10. (C11) Reentrant lock used to prevent data races when multiple threads read, write, position, or query the position of a stream. 14:29 < bridge> https://en.cppreference.com/w/c/io/FILE 14:29 < bridge> Where does rust shove these? I have a feeling we are not comparing equivalent abstractions 14:29 < bridge> rust's file has none of 1-10 14:29 < bridge> you can wrap a file in a `BufReader` 14:30 < bridge> i could imagine that, if you code smth where low level filesystem access is important (even in rust) you might just use system related operations anyway (win32 on windows etc.) 14:30 < bridge> (you probably should, if you're not just reading the complete file) 14:30 < bridge> no need in rust, because it's just a thin wrapper here 14:30 < bridge> yeah but like permission stuff and so on 14:31 < bridge> or does all this exist as wrapper? 14:31 < bridge> Ok, so these are not the same abstractions. C doesn't have a similar thin wrapper for files 14:31 < bridge> it doesn't do 1,2. 3,4: buffering can be done by wrapping it in a `BufReader`, 5,6,7,8,9 is not done in rust, 10 is guaranteed by rust's guarantees 14:31 < bridge> correct 14:32 < bridge> so rust has a thinner abstraction around files than C does 14:32 < bridge> You mean than C libc does. 14:32 < bridge> man alone not having unicode support must suck in c 14:32 < bridge> u HAVE to use win32 api 14:32 < bridge> xd 14:33 < bridge> I mean C. you might be talking about POSIX, linux C or libraries 14:33 < bridge> I mean C. you might be talking about POSIX, C on linux or libraries 14:33 < bridge> It's a little disingenuous when no one would use those 14:33 < bridge> no one uses `FILE *`? 14:34 < bridge> No `File` you almost always want a bufreader or bufwriter 14:34 < bridge> yes, but that's simpler, no? 14:34 < bridge> you don't put all the abstractions into one big file struct 14:34 < bridge> It exists but almost everyone will be using the fatter abstraction 14:34 < bridge> even with `BufReader`, it's still thinner than C's stuff 14:35 < bridge> Through having a fatter abstraction for strings iirc 14:35 < bridge> in what way? 14:35 < bridge> you mean having one at all? 14:35 < bridge> fater abstraction = more code? 14:35 < bridge> 14:35 < bridge> or fater abstraction = less performance? 14:36 < bridge> i kinda have the feeling this isnt clear in this conversation 14:36 < bridge> I think we agreed on the fact that C and rust code is in the same league for speed 14:36 < bridge> C strings are nothing but a bunch of bytes. That's why we need to keep track of the wchar stuff 14:36 < bridge> no, C strings are nul-terminated char arrays 14:36 < bridge> rust strings can be faster, null terminator was a bad decision 14:36 < bridge> ok then 14:36 < bridge> fat as in more code for the user to write? 14:36 < bridge> or fat as in the standard is more fat? 14:36 < bridge> `char *` can refer to a pointer to a `char` or to such a C string 14:37 < bridge> `char *` can refer to a pointer to a `char` or to such a C string, or to a pointer to a `char` array, even 14:37 < bridge> Since when are null terminated char arrays are not a bunch of bytes? 14:37 < bridge> it just doesn't say 14:37 < bridge> because they carry an additional guarantee 14:37 < bridge> Ok, done for the day 14:37 < bridge> pack it up we done 14:38 < bridge> All details are not important all of the time. Also C standards have long history so they can't just appear perfect, so I don't mean "just the standarised C" as C. 14:39 < bridge> lmao, don't be sad over programming languages. if you like c so much use it. it's your life and your time and if u like it so much do it 14:39 < bridge> Thanks for sharing your opinions and knowledge with me, have nice days. Cheers 🙂 14:39 < bridge> ye its just a discussion 14:39 < bridge> end of the day each uses the lang they want 14:40 < bridge> no, don't use python 😬 14:40 < bridge> but people writing critical software hopefully don't use C 14:40 < bridge> but people writing critical software hopefully don't start their new projects in C 14:40 < bridge> they use ada 14:41 < bridge> I don't care about your opinion of C, nor do I care about @heinrich5991's opinion on C. I'm just annoyed at the disingenuous bad faith discussion techniques employed 14:41 < bridge> <_voxeldoesart> programmer tone tags 14:41 < bridge> at the end of the day, i don't want to sit in a plane that panics, nor runs on UB 14:41 < bridge> 14:41 < bridge> so just proof the software or smth 14:42 < bridge> I'm sorry. maybe we can come together some other time 14:42 < bridge> i think u call disingenuous any argument not in ur favour tho 14:42 < bridge> UB as in go to your destination. Go to Heaven! 14:42 < bridge> OpenBSD say they are serious about security and they use C, I'm just letting you know. 14:42 < bridge> ppl use /s for sarcasm btw 14:42 < bridge> They don't know shit 14:42 < bridge> it wasn't sarcasm 14:43 < bridge> it was flamebait 14:43 < bridge> sarcasm is often used for that 14:43 < bridge> anyway 14:43 < bridge> <_voxeldoesart> yeah but tonetags suck and most are infantilizing 14:43 < bridge> but he was serious af about it 14:44 < bridge> Yes 14:44 < bridge> my take is, ill take rust complexity that maintains same speed as C but with improved safety 14:44 < bridge> and i enjoy it 14:45 < bridge> i don't have an opinion about it, because i don't use it as a daily driver. 14:45 < bridge> 14:45 < bridge> But i know concepts i use, and that i like that c is missing. 14:46 < bridge> but C simplicity is often just at face value, digging deeper it becomws complex because you need to be aware and careful of lot of stuff, ur cognitivie load comes later, when u need to fix those bugs, or when ur thinking how to do X safely 14:46 < bridge> in rust the cognitive load comes at compile time, at ur initial write 14:46 < bridge> You actually need to know how make things right? 14:46 < bridge> It's like talking about how calculus is a thin abstraction over zermelo-fraenkel set theory. Just because thin layers exist along the way 14:46 < bridge> altho u can avoid the load initially by using simpler stuff but less fast 14:46 < bridge> which is how u protoptype 14:47 < bridge> in fact sometimes u just accept it, because it would bloat software a lot 14:47 < bridge> there is a difference between knowimg how to make things and how to make things correctly and safe 14:47 < bridge> You actually need to know how make things, right? 14:47 < bridge> well remove the "sometimes" 14:47 < bridge> always 14:47 < bridge> in the end c is high level compared to asm xD 14:48 < bridge> <_voxeldoesart> i wonder what rust feature will benefit the ddnet code if it ever replaced the server code 14:48 < bridge> <_voxeldoesart> like, i imagine rust has some unique function that c doesnt 14:48 < bridge> it wont make ddnet faster 14:48 < bridge> it may avoid segfaults 14:48 < bridge> altho a rewrite maybe improves perf by encountering optimization oportunities 14:48 < bridge>