logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 1 / 4
Evil_Bob
yeah exactly
retard
it is yet another sort of "easy abstraction" that lets programmers get away with not understanding what a computer does
stateless
not everyone falls into that category
I don't bother to free memory for one-shot type of programs
if I knew any language other than C, I would use it for small hacks
:P
Evil_Bob
retard: well it depends on the implementation. The Go GC implementation is pretty good. Alot of C programs dont implement hand-coded memory allocation well either
retard
anytime it is used for anything significant it regularly fu*ks up completely unrelated processes
which is great fun
stateless
retard, I wouldn't use it for anything significant
and I don't use it for that matter
don't worry on linux malloc can never fail
:P
retard
thing is people don't even consider failure modes involving garbage collection as actual failure modes
stateless
I always feel great when I write a program in C that doesn't require dynamic memory allocation
retard
it's "working as intended"
stateless
or when I rewrite a bit of code in some larger codebase and get rid of memory allocations
because in my mind the fewer of those, the better
with GC in place you are screwed in the codebase is sufficiently large
s/in the/if the/
Evil_Bob
i use Go mostly at work, i like it alot for the types of programs i write there (internal http status, database import/export stuff mostly)
*http stuff
retard
but i have seen it topple completely unrelated processes time and time again
it is fine for one-shot scripts etc
but people shove that crap into daemons
stateless
one cool debugging tip for C
#define free() at the top, seem if it crashes, if not, you are doing use after free :P
retard
One Weird Tip that C programmers don't want you to know!
stateless
well #define free(x) or whatever :P
retard, yeah daemons should be very conservative
I would prefer if a daemon was being honest up front and allocated everything that it needs without requiring further memory allocations at runtime
so you put 1024 worker threads, ok
Evil_Bob
i write daemons in go, its fine
stateless
start them
:P
doesn't matter much for threads, but the per client state for each of those threads could have been allocated up front
retard
it's fine, it's perfect, then some completely unrelated time-critical thing starts sh*tting itself on the reg because your dumb GC kicks in
stateless
or even a clictx[MAX_CLIS];
Evil_Bob, go writes daemons in you
:P
Evil_Bob
retard: the garbage collector in 1.5 has low latency, even for gigabytes of data (which most people never come to), look at the benchmarks man
retard
i'm sure it is magical and sh*ts unicorns 24/7
Evil_Bob
from a practical point of view its just infeasable to write everything in C
retard: yeah it isnt and its the new hipster language i suppose, look at all the Go devs using a Mac :P
but its a great language nonetheless imho
stateless
Evil_Bob, the problem is when it doesn't work
doing any kind of performance analysis on a system that uses GC is more difficult
so for critical stuff, I would never use GC
Evil_Bob
yeah i agree with that
stateless
also linux is really bad at fragmenting physical memory
it is very easy to fragment physical memory from a misbehaving userspace program
if anything for example relies on huge pages to deliver the required performane, you can easily dos it
Evil_Bob
i dont write critical stuff though, it needs to be correct though and somewhat fast
stateless
there are mechanisms to do physical memory compaction and the like but it can take orders of magnitude more time on a sufficiently fragmented physical memory
Evil_Bob, yes then it doesn't matter
critical stuff in mind includes basic daemons
like crond or syslogd
:P
in my mind*
or DBs
Evil_Bob
i could write it in C, which would take more time and im sure i'll have more bugs in my own memory allocation logic
once you use SQL etc performance will be relatively sh*t aswell
retard
i like my computers to actually behave deterministically
stateless
retard, I hope you turned off overcommit :)
don't have these problems on bsd, so that's good
:P
malloc(3122222222); sorry failed
not that the majority of critical software out there deals well with out of memory conditions but aw well
moral of the story: don't open POSIX in pdf form in your favourite pdf viewer if you have swap enabled
Evil_Bob
lol
stateless
actually, don't open posix.pdf and search sth in it
:P
retard
the problem is when your fast and un-critical stuff runs on the same machine as other actually critical sh*t
stateless
retard, login classes
:P
Evil_Bob
retard: i would not do that
stateless
done
:P
retard
that stuff can be correct and beautiful and perfect in every way
and your sh*t will topple it
every day of the week
stateless
I give you 16MB of memory, 8 file descriptors and 32kB of stack
enjoy
Evil_Bob
retard: my code is never correct and perfect though so your assumptions are false
i dont pretend to be able to write perfect code, i just try to do the best i can
stateless
I got to clean the bathroom
be back
retard
Evil_Bob: i'm talking about the actual critical time-sensitive stuff
your video transcoder or database or whatever
stateless
ntpd!!
jitter: 0.044ms
:(
retard
that is too close to JIT
you just triggered me
stateless
haha
retard
rapist
stateless
retard, the linux solution to that is to pin it to cores
or whatever random sh*t like that
retard
i've done the dance
Evil_Bob
retard: i agree, we're probably on the same page, im bad at debating :)
« prev 1 2 3 4 5 6 7 8 9 next »