06:48 <+bridge> [ddnet] <fokkonaut> 0.7:
06:48 <+bridge> [ddnet] <fokkonaut> Hey, I have two questions:
06:48 <+bridge> [ddnet] <fokkonaut> 1. Why does my rainbow get faster with increasing server uptime (higher tick value)?
06:48 <+bridge> [ddnet] <fokkonaut> 2. If I shoot in /pause, so i can spec another player, and then resume the gun shoot will come. Why? It shouldnt save the input, but it somehow does
16:19 <+bridge> [ddnet] <heinrich5991> @fokkonaut where can I find your ddnet 0.7?
16:20 <+bridge> [ddnet] <fokkonaut> Currently you cant. Its in my private repo combined with my mod. I will make a pure DDNet when I get home.
17:21 <+bridge> [ddnet] <Learath2> @heinrich5991 that ixy-languages thing is so interesting, I was sure some black magic would be needed for such high performance applications, yet the C is very clean and readable. I guess sometimes elegant code can also be performant
17:23 <+bridge> [ddnet] <Learath2> The accompanying talk at 35c3 is also pretty nice
17:24 <+bridge> [ddnet] <Learath2> (not that I really agree with the sentiment, drivers still benefit from being written in C as can be seen from the graphs)
17:24 <+bridge> [ddnet] <heinrich5991> rust seems to be also fine
17:25 <+bridge> [ddnet] <heinrich5991> + you get the benefit that you're less likely to be exploited
19:24 <+bridge> [ddnet] <Learath2> Sadly rust is plagued by lifetimes and all low level code having to rely on "unsafe" stuff
19:24 <+bridge> [ddnet] <deen> Still better than everything relying on unsafe like most other languages (other than Haskell and friends)
19:28 <+bridge> [ddnet] <Learath2> For something like a kernel having to have unsafe everywhere just becomes inconvenient at some point
19:29 <+bridge> [ddnet] <Ryozuki> C best
19:29 <+bridge> [ddnet] <Learath2> Definitely not, C is too unwieldy for most things
19:29 <+bridge> [ddnet] <Ryozuki> :cammostripes:
19:29 <+bridge> [ddnet] <Ryozuki> @Learath2 i see u joined the js team
19:29 <+bridge> [ddnet] <Learath2> There is a place for most languages, I don't see the niche rust fills
19:29 <+bridge> [ddnet] <Ryozuki> :justatest:
19:30 <+bridge> [ddnet] <Learath2> 😛
19:30 <+bridge> [ddnet] <Ryozuki> im 2 lazy to learn rust
19:30 <+bridge> [ddnet] <Ryozuki> it uses kinda some diferent syntax which im lazy to learn
19:30 <+bridge> [ddnet] <Ryozuki> https://www.rust-lang.org/learn/get-started
19:30 <+bridge> [ddnet] <Learath2> I spent a bit of time learning, it's syntax (or maybe semantics) are just too different from most languages
19:31 <+bridge> [ddnet] <Ryozuki> look they have a pretty website
19:31 <+bridge> [ddnet] <Ryozuki> so they can catch
19:31 <+bridge> [ddnet] <Ryozuki> programmers
19:31 <+bridge> [ddnet] <Ryozuki> relying on superficial stuff 😎
19:31 <+bridge> [ddnet] <Learath2> Rust has a pretty strong community behind it and is well developed, it's just unwieldy in the niche it claims to fill
19:31 <+bridge> [ddnet] <Ryozuki> what niche is it
19:32 <+bridge> [ddnet] <Ryozuki> systems lang?
19:32 <+bridge> [ddnet] <Learath2> It's just not a good "systems language"
19:33 <+bridge> [ddnet] <Ryozuki> lately i taken a like a lot for C i dont know why
19:33 <+bridge> [ddnet] <Ryozuki> but i cant stop
19:33 <+bridge> [ddnet] <Ryozuki> i look at c++ and im like uhhh
19:33 <+bridge> [ddnet] <Ryozuki> i know i explain myself so good :justatest:
19:34 <+bridge> [ddnet] <Learath2> If I'm prototyping I'd rather use python or nim, if I'm writing a web app I'd rather use js, if I'm writing a backend I'd rather use php, if I'm writing a game I'd rather use C++, if I'm doing embedded I'd rather use C
19:34 <+bridge> [ddnet] <Ryozuki> i see so you would use php at some point
19:34 <+bridge> [ddnet] <Learath2> It just doesn't fit in anywhere in the list of things I'm currently doing 😛
19:34 <+bridge> [ddnet] <Ryozuki> making a game in C is not that hard
19:35 <+bridge> [ddnet] <Learath2> I adopted php because of it's very C-like syntax and nice frameworks
19:35 <+bridge> [ddnet] <Ryozuki> do you think php has future?
19:35 <+bridge> [ddnet] <Ryozuki> js looks rly strong right now tbh
19:35 <+bridge> [ddnet] <Ryozuki> even for backend
19:35 <+bridge> [ddnet] <Ryozuki> nodejs
19:35 <+bridge> [ddnet] <Learath2> https://github.com/exezin/exengine This is what siO has been working on for quite a while
19:35 <+bridge> [ddnet] <Ryozuki> i know
19:35 <+bridge> [ddnet] <Ryozuki> im making something in c too
19:36 <+bridge> [ddnet] <Learath2> @Ryozuki I see php dying off soon enough, nodejs is getting really strong for small projects , python already has great marketshare for larger codebases, scala has great marketshare for reliable code
19:37 <+bridge> [ddnet] <Ryozuki> what about java
19:37 <+bridge> [ddnet] <Ryozuki> i often go to twitch streams in the science section, most are using c#
19:37 <+bridge> [ddnet] <Ryozuki> btw
19:37 <+bridge> [ddnet] <Ryozuki> xd
19:37 <+bridge> [ddnet] <Ryozuki> fcking unity, its ugly af
19:37 <+bridge> [ddnet] <Ryozuki> https://www.twitch.tv/directory/game/Science%20%26%20Technology
19:38 <+bridge> [ddnet] <Learath2> java is mostly a dying breed from what I gather
19:38 <+bridge> [ddnet] <Learath2> Scala runs on the jvm and it's much easier to work with for backend applications
19:38 <+bridge> [ddnet] <Ryozuki> have u heard about kotlin
19:38 <+bridge> [ddnet] <Ryozuki> https://kotlinlang.org/
19:39 <+bridge> [ddnet] <Learath2> even learned a bit about it trying to help a friend debug
19:40 <+bridge> [ddnet] <Learath2> interesting language, but I find the syntax a little meh, tbh languages really shouldn't mess around with syntax anymore
19:40 <+bridge> [ddnet] <Learath2> The C-Like and Python-like syntaxes work great, adding a syntax barrier to your language just slows down adoption
19:40 <+bridge> [ddnet] <Ryozuki> ye
19:41 <+bridge> [ddnet] <Ryozuki> its the main reason i dont learn some langs
19:41 <+bridge> [ddnet] <Ryozuki> haskell has some rly weird stuff
19:42 <+bridge> [ddnet] <Learath2> > [7:35 PM] Ryozuki: im making something in c too
19:42 <+bridge> [ddnet] <Learath2> C is nice, but it's lack of objects really shows in game engine type of projects
19:43 <+bridge> [ddnet] <Learath2> `s#objects#classes/polymorphism`
19:45 <+bridge> [ddnet] <Ryozuki> you can work around it
19:45 <+bridge> [ddnet] <Ryozuki> its kind of fun
19:48 <+bridge> [ddnet] <Learath2> ofc, you can even have vtable-like structs using some function pointers and macro black-magic
19:48 <+bridge> [ddnet] <Learath2> it just looks a little ugly 😛
20:04 <+bridge> [ddnet] <archimede67> lol
20:04 <+bridge> [ddnet] <archimede67> js is future
20:04 <+bridge> [ddnet] <archimede67> no php
21:16 <+bridge> [ddnet] <FluffiexD> py is future ans u su
21:21 <+bridge> [ddnet] <heinrich5991> @Learath2 the thing is, even in a kernel, unsafe isn't everywhere
21:22 <+Learath2> it's still in enough places that your hands would get tired of typing unsafed
21:22 <+Learath2> and you'd start seeing the word unsafe in your dreams
21:23 <@heinrich5991> yea, and then you don't end up with buffer overflows at points where you didn't expect them
21:24 <@heinrich5991> isn't it a huge improvement that the typical security vulnerability goes down from "arbitrary code execution" to "denial of service through service downtime"?
21:29 <+Learath2> Well I and apparently many others given rusts relatively very slow adoption as a systems language, prefer not writing mission critical code in an unfamiliar language and write a metric shit ton of code that won't even benefit from the safety of said language
21:29 <+Learath2> Good practices always beats language crutches imho
21:29 <@heinrich5991> statistics say something different
21:30 <+Learath2> I can't fathom a study that's unbiased
21:30 <@heinrich5991> or you say that most popular projects don't follow good practices
21:30 <@heinrich5991> say you have a popular fuzzer and run it against open source projects e.g.?
21:31 <+Learath2> for regular applications I'm sure rust will have significantly less vulnerabilities
21:32 <+Learath2> My point is, at what cost? If writing a program now takes me 50 hours instead of 10, is it really worth it?
21:32 <@heinrich5991> if you go from remote code execution to DoS in a library used by lots of programs, yes, definitely
21:33 <+Learath2> Which library do you have in mind?
21:33 <@heinrich5991> libpng
21:33 <@heinrich5991> e.g.
21:33 <@heinrich5991> openssl
21:34 <+Learath2> openssl has such a huge footprint that even if it was written in SPARK it'd have bugs
21:34 <@heinrich5991> yes. it'll have bugs if it's written in rust
21:35 <@heinrich5991> but likely not stack overflow, etc.
21:35 <@heinrich5991> logic bugs, definitely
21:35 <+Learath2> for libraries of that size, it's just too late
21:35 <+Learath2> they'll never get rewritten in rust or any other language
21:36 <+bridge> [ddnet] <heinrich5991> librsvg got rewritten and retained its interface
21:36 <@heinrich5991> its developer wrote about the porting experience
21:37 <+Learath2> librsvg isn't half the size of openssl :D
21:37 <+bridge> [ddnet] <heinrich5991> and it got rewritten by a single developer I think (not sure)
21:38 <@heinrich5991> anyway, I'm not saying you should bother people to rewrite their libraries
21:38 <+Learath2> This is beyond the point anyway, yes rust will definitely improve vulnerabilities
21:38 <+Learath2> But it just doesn't fill any niche
21:38 <@heinrich5991> the one of high performance stuff that touches untrustworthy data
21:38 <+Learath2> It tries to be a better C, nothing will ever replace C because entire architectures are designed on supporting C
21:39 <+Learath2> Your toaster will most likely never run rust
21:39 <@heinrich5991> nah, mostly because it's the platform language of the unixes I think
21:39 <@heinrich5991> and my toaster has no problems running rust
21:39 <+Learath2> But my point is that it'll never
21:40 <@heinrich5991> wanna take a long-term bet?
21:40 <+Learath2> Sure
21:40 <@heinrich5991> I bet in 20 years, there'll be iot appliances using rust code
21:40 <@deen> I bet there are IOT appliances running Rust today :D
21:40 <+Learath2> You could just go ahead and make one and I'd lose that bet lol
21:40 <@heinrich5991> aside from my direct influence
21:41 <+Learath2> Rust will never be the dominant language in the embedded world is one I'm willing to take
21:41 <@heinrich5991> what about C will not be the dominant language in the embedded world?
21:42 <@heinrich5991> because you said " nothing will ever replace C because entire architectures are designed on supporting C"
21:42 <+Learath2> It seems like you are emotionally invested in rust's success :P
21:43 <+bridge> [ddnet] <heinrich5991> analysing the psychology of one's conversation partner has always led to great discussions…
21:43 <@heinrich5991> try to construct the obvious answer that I could give to completely derail this conversation
21:43 <@heinrich5991> okay, even that was too far, probably "try to…". sorry
21:45 <+Learath2> My argument just relies on how businesses work, they don't have an ideological or emotional attachment to anything
21:46 <@heinrich5991> that argument isn't so simple
21:46 <@heinrich5991> for now, that argument looks to me like I could disprove the existence of the free software movement with it
21:47 <+Learath2> There are hundreds of thousands of lines on code making sure that nearly every piece of hardware capable of running code is capable of emulating the c abstract machine
21:48 <@heinrich5991> what do you mean by that?
21:48 <+Learath2> The return on investment on writing code in another language is fairly small, just the sunk cost fallacy would stop businesses from investing in a rewrite
21:48 <@heinrich5991> C/Rust is not an either or
21:49 <+Learath2> heinrich5991: there is an implementation of libc that works on most anything and there are things that the c abstract machine requires that wouldn't always be optimal
21:50 <@heinrich5991> e.g.?
21:50 <@heinrich5991> maybe null-terminated strings, those are a bit annoying
21:50 <@heinrich5991> I don't quite get what you mean with the "c abstract machine". isn't that mostly C without the libc?
21:50 <@heinrich5991> i.e. pointers, functions, etc.
21:52 <+Learath2> e.g. while the c abstract machine doesn't really require a stack, it's the easiest way to implement C, every processor on the market has instructions that work on some form of stack
21:52 <@heinrich5991> hm. isn't that what most programming languages require?
21:53 <@heinrich5991> i.e. I could claim that the easiest way to implement the rust semantics is to use a stack and that all hardware apparently has been designed for rust?
21:54 <+Learath2> rust is relatively young, nothing has been designed for rust
21:54 <@heinrich5991> yes. I was just trying to show that your argument doesn't hold
21:55 <@heinrich5991> the argument has (as far as I can tell, and only so far) been reduced to "there's hardware that appeared after c emerged"
22:00 <+Learath2> I obviously haven't worked in the 90s and can't really tell you whether it's actually the reason nearly a 100% of the cpu's out there (eventhough they have vastly different internal architectures) support a set of very similar instructions
22:01 <+Learath2> but it's my personal opinion that the c standard very much affected the way people built their instruction setd
22:01 <+Learath2> sets*
22:01 <@heinrich5991> but in what way?
22:02 <+Learath2> I gave you one example which you conveniently brushed away by making an absurd claim
22:02 <@heinrich5991> the example is the stack?
22:02 <@heinrich5991> I don't think that C affected that
22:03 <+Learath2> It's not always convenient to have a stack, most cpus don't even have dedicated stacks anymore
22:04 <@heinrich5991> I don't understand. in order to keep track of where you what your callstack is (I find that to be a pretty universal concept among programming languages), you need a stack
22:04 <@heinrich5991> at least I don't know the alternatives
22:04 <+Learath2> It's very trivial to take a look at C code and it's compiled version to see that C maps to assembly very cleanly in most any cpu
22:05 <@heinrich5991> there are quite some exceptions to this claim
22:05 <@heinrich5991> e.g. vectored instructions
22:05 <@heinrich5991> trivial strlen code
22:05 <@heinrich5991> division by a constant
22:06 <+Learath2> There are languages that don't even have the concept of function calls
22:06 <@heinrich5991> let me make this claim I'm pretty sure of: C neither innovated with the concept of function calls nor did it popularize it
22:09 <+Learath2> Sadly, my historical knowledge of the subject is pretty incomplete so I can't continue with this line as anything I say you can dismiss with a similar argument.
22:10 <@heinrich5991> do you believe that the idea of function calls has anything to do with C?
22:11 <@heinrich5991> e.g. pascal, appeared before C, had no problems with having function calls
22:11 <@heinrich5991> with a stack
22:11 <+Learath2> No, ofc not
22:11 <@heinrich5991> well then let's continue and dismiss this piece of information neither of us believes in
22:14 <+Learath2> Say processor manufacturers don't give two shits about the C standard, doesn't really matter to my original argument
22:15 <+Learath2> (which I don't believe tbh, no one would ever produce an architecture that can't possibly emulate the abstract machine)
22:15 <@heinrich5991> maybe because there's not much special about most programming languages in that field, and if you'd not support them you'd have pretty much fucked up your CPU
22:16 <+Learath2> I still maintain that reimplementing things in rust (or anyother language for that matter) just does not make any business sense
22:16 <@heinrich5991> okay. then let's implement new things in rust instead
22:16 <@heinrich5991> I agree that asking to reimplement stuff is a bit high of an ask
22:17 <+Learath2> Which brings me to my second point, rust by ditching the familiar syntax and introducing an (imho) ridiculous amount of thinking overhead hindered it's adoption a lot.
22:18 <@heinrich5991> is there things that it needlessly complicated (i.e. beyond the borrow checker and its thread safety, which are its value proposition)?
22:18 <@heinrich5991> *are there
22:20 <+Learath2> e.g. match statements are a completely alienating concept to most
22:21 <@heinrich5991> hm. okay
22:21 <+Learath2> e.g. string formatting is also needlessly changed
22:21 <+Learath2> I'm not saying that string formatting is bad in rust
22:21 <+Learath2> What I mean is that it's different for what appears to be being differents sake
22:22 <+Learath2> Which is definitely not good for adoption
22:22 <@heinrich5991> I can see how these differences can make a difference for programmers coming from C
22:22 <@heinrich5991> note that they're not really different for different's sake, like e.g. C++ also introduced things like match but in a much uglier form
22:23 <@heinrich5991> (i.e. you have to provide lambdas for each case instead of it being baked into the language)
22:23 <+Learath2> It's equally unfamilar to a js/java programmer who is used to just using + or C-like formatstrings , or python user who is used to % or .format()
22:23 <@heinrich5991> it's like python's .format
22:23 <@heinrich5991> println!("Hello, integer {}!", 123)
22:24 <@heinrich5991> println!("Hello, {}!", name); where name is a string
22:24 <@heinrich5991> you can do + like in js/java if you really want (it's supported) but just don't
22:24 <@heinrich5991> printf-style formatting is not available
22:24 <+Learath2> "but just don't" is what's wrong with this
22:25 <@heinrich5991> it's available
22:25 <@heinrich5991> that's just my personal opinion that you shouldn't do it
22:25 <+Learath2> There are also if/else statements and you can use them just like in other languages
22:25 <@heinrich5991> because it leads to some software maintainability problems
22:25 <+Learath2> but no one would
22:25 <@heinrich5991> but .format-style formatting is availabe and is used
22:26 <@heinrich5991> where's the problem with that?
22:26 <@heinrich5991> you can't expect two of your examples to be the most used version for string formatting
22:27 <+Learath2> I can and most do expect things to work atleast at some level similarly to a language they've worked with before
22:27 <@heinrich5991> they do work (except for printf-style)
22:27 <@heinrich5991> where's your exact problem right now, I don't quite get it
22:28 <@heinrich5991> is it that printf-style isn't available?
22:28 <@heinrich5991> or that .format-style is the most dominant one?
22:28 <@heinrich5991> these are the two issues that I saw
22:28 <@heinrich5991> is it something else?
22:29 <+Learath2> It was just an example, seriously I have no problem with a language being different
22:29 <@heinrich5991> so the issue was that "printf-style formatting is not available"?
22:29 <@heinrich5991> (that's fine, I'm just having a hard time figuring out what you mean)
22:30 <+Learath2> That was the issue for me when I was learning rust, but it's one that's easy to overcome
22:31 <@heinrich5991> okay. then I at least get the problem
22:32 <+Learath2> These things build up over time, if too many things are different, people just don't bother learning
22:32 <+Learath2> Especially when these syntax issues have nothing to do with the main promise of the language
22:33 <+Learath2> Look at haskell, while it has a different syntax, it's syntax is very intuitive for it's usecase
22:36 <@heinrich5991> hm. I'd guess I had to learn all three separately, C, Haskell and Rust
22:37 <@heinrich5991> none of it was intuitive at first
22:37 <@heinrich5991> you should have seen my first C or C++ programs
22:37 <+Learath2> C was very intuitive for me the second I started learning properly from a book
22:37 <+Learath2> Which is a very horrible pitfall for C
22:37 <+Learath2> Because C is anything but intuitive or convenient to use
22:41 <+Learath2> Give it a week and there won't be any C program that you can't read (albeit not quickly)
22:41 <+Learath2> I gave rust a month and yet still some symbols just confuse me, I need the documentation open for reading most anything
22:42 <+bridge> [ddnet] <heinrich5991> C wasn't that quick for me I think
22:42 <+Learath2> Which definitely could be saying that I'm just incompatible with rust or plain retarded. It's anectodal at best
22:42 <+bridge> [ddnet] <heinrich5991> but I agree that C is simpler in terms of language semantics
22:43 <+bridge> [ddnet] <heinrich5991> in the way that go is a simple game or so 😛
22:43 <@heinrich5991> (because it has simple rules)
22:49 <+Learath2> If I asked you what does '&' do in rust, what would your answer be?
22:50 <+Learath2> or '!'
22:51 <+Learath2> I guess the only other one that comes to my mind right now is ':'
23:01 <@heinrich5991> & indicates taking the reference and is also used for the reference type
23:02 <@heinrich5991> ! as a return type means that the function does not return normally. println! and similar warn you that the preceding identifier is a macro. logical negation also exists
23:03 <@heinrich5991> : says that a is of type b, I don't know any other meaning off the top of my head
23:03 <@heinrich5991> & as bitwise and and && as logical and also exist
23:04 <+Learath2> : is also used to initialize things in a struct
23:04 <@heinrich5991> oh true
23:04 <+Learath2> Everytime I see one of these symbols, I have to think carefully what they mean in this context
23:05 <@heinrich5991> C has fewer operators. but e.g. * also has such double meanings, right?
23:05 <+Learath2> In C (and most other languages I've used) there is only one thing to consider is the symbol an unary operator or a binary one
23:06 <@heinrich5991> and also whether it is in a type context or not, I guess?
23:06 <+Learath2> In C declaration follows use, you can still think about * as the unary operator
23:07 <@heinrich5991> in rust, declaration mostly follows instantiation, I'd guess?
23:08 <+Learath2> again, not really a very important thing, but it still adds to the overhead of reading rust code
23:13 <+Learath2> None of these would matter, if borrows, the main promise of the language didn't take so much out of you
23:15 <+Learath2> I constantly have to think about who owns what
23:15 <+bridge> [ddnet] <heinrich5991> I mean for non-long-lived objects in C, you also have to do that
23:15 <+bridge> [ddnet] <heinrich5991> and you even have to do that more consciously, because you don't have the compiler to help you