Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet
Between 2019-09-13 00:00:00Z and 2019-09-14 00:00:00Z
0.7:
Hey, I have two questions:
1. Why does my rainbow get faster with increasing server uptime (higher tick value)?
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
@fokkonaut is going to work on giving us a 0.7 DDNet server, he already ported DDNet server to 0.7 for his own mod so only needs to cut away a few features.
I will make a map converter to 0.7 today so that we will have all maps available immediately.
Remaining task is to take current DDNet client and apply only the network and skin related changes to have a 0.7 compatible client with the same look as current DDNet client.
@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
15:23
The accompanying talk at 35c3 is also pretty nice
15:24
(not that I really agree with the sentiment, drivers still benefit from being written in C as can be seen from the graphs)
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
@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
Watch Science & Technology channels streaming live on Twitch. Sign up or login to join the community and follow your favorite Science & Technology streamers!
yea, and then you don't end up with buffer overflows at points where you didn't expect them
19:24
isn't it a huge improvement that the typical security vulnerability goes down from "arbitrary code execution" to "denial of service through service downtime"?
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
19:29
Good practices always beats language crutches imho
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
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
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
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
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
20:01
but it's my personal opinion that the c standard very much affected the way people built their instruction setd
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
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.
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
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.
& indicates taking the reference and is also used for the reference type
21:02
! 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
21:03
: says that a is of type b, I don't know any other meaning off the top of my head