More Go Chum In The WTF Ocean



  • Disqus, and admittedly decently big online service, is going Go! Since you all hate on Go, I thought I'd chum the waters with this,stand back and watch the ensuing bitchfest.

    <grabs popcorn>



  • But Disqus already sucks



  • "we are a small team."

    To the right, there's a grid of 43 people.

    That's a really unusual idea of small. My idea of small is < 10.



  • @dhromed said:

    To the right, there's a grid of 43 people.

    I count 42 and some waffles.





  • @Salamander said:

    I count 42 and some waffles.
     

    Ok, if I look at the job titles, I count 13 techs, so that's more believable.



  • That page is incredibly broken for me. Lots of missing images and fucked up css.



  • @alphadogg said:

    http://blog.disqus.com/post/51155103801/trying-out-this-go-thing

    Disqus, and admittedly decently big online service, is going Go! Since you all hate on Go, I thought I'd chum the waters with this,stand back and watch the ensuing bitchfest.

    <grabs popcorn>

    Oh, so that's why Disqus has been acting all strange this week?



  • @mikeTheLiar said:

    That page is incredibly broken for me. Lots of missing images and fucked up css.
     

    Have you tried using a browser capable of CSS and images?



  • maybe they all have small penises. Doesn't seem like the thing you'd advertise, though.



  • @dhromed said:

    "we are a small team."

    To the right, there's a grid of 43 people.

    That's a really unusual idea of small. My idea of small is < 10.

    I am a small team.

    1 < 10



  • @alphadogg said:

    ...stand back and watch the ensuing bitchfest.

    Why would I care if a shitty service I don't use uses a shitty language I don't use? If anything, this will just hasten Disqus' bankruptcy, which is a good thing.



  •  The comments are a delight. "How did you handle dependencies?" "We forked all of them, then integrated the forks"



  • @fire2k said:

     The comments are a delight. "How did you handle dependencies?" "We forked all of them, then integrated the forks"

    As opposed to doing the same thing with precompiled dependencies that break whenever you try to support a new (OS, arch) pair?



  • @fire2k said:

     The comments are a delight. "How did you handle dependencies?" "We forked all of them, then integrated the forks"

    "How do you live with yourselves, after seeing the sense of betrayal and hatred in your children's eyes?"

    "It's surprisingly liberating to know you've lost the love of your children.. to have them say 'Why couldn't you just fake your death and run off with some floozy you met on OK Cupid, like a normal deadbeat dad?' And knowing that you will never again be able to pleasure your wife sexually frees you from the obligation of even trying.

    I could have just committed suicide, but programming in Go felt right. Like, I deserve this. This is what happens to men who are failures... to men who can no longer bring themselves to listen to another of their wives' cursorily-faked orgasms...

    I think I need a drink."



  • @Ben L. said:

    @fire2k said:

     The comments are a delight. "How did you handle dependencies?" "We forked all of them, then integrated the forks"

    As opposed to doing the same thing with precompiled dependencies that break whenever you try to support a new (OS, arch) pair?

    Or you could, I dunno, just include the actual dependencies you need in your repo, instead of forking them all.

    In other news I actually give a shit about, the forum appears to be dying.. it won't let me save tags and it errors out after every post I make (although the post eventually shows up..) Happening to anyone else?



  • @dhromed said:

    Have you tried using a browser capable of CSS and images?
    No, I'm using Netscape Navigator 3.1



  • @mikeTheLiar said:

    @dhromed said:
    Have you tried using a browser capable of CSS and images?
    No, I'm using Netscape Navigator 3.1

    Speaking of images, I like the little photo of the douchebag with the nasty beard and hipster glasses at the top. It really sells the whole confidence man angle.



  • @morbiuswilters said:

    Or you could, I dunno, just include the actual dependencies you need in your repo, instead of forking them all.

    "Fork" is just web 2.0 for "get the sources".



  • @MiffTheFox said:

    @morbiuswilters said:
    Or you could, I dunno, just include the actual dependencies you need in your repo, instead of forking them all.

    "Fork" is just web 2.0 for "get the sources".

    That is idiotic. I hate kids.



  • @morbiuswilters said:

    Why would I care if a shitty service I don't use uses a shitty language I don't use?

    You should care because with Go being so fast, they broke the request/response continuum:

    @Matt Robenolt said:

    The new realtime message is so fast, that it makes it all the way back through our services and back into your browser, before you actually finish making the request.

    This is a paradigm shift. I'm calling dibs on a new buzzword: Predictive Http © Ronald 2013



  • @Ronald said:

    @Matt Robenolt said:
    The new realtime message is so fast, that it makes it all the way back through our services and back into your browser, before you actually finish making the request.

    Of all the workplace shootings in the US, somehow these assholes escape?



  • @Ben L. said:

    @fire2k said:

     The comments are a delight. "How did you handle dependencies?" "We forked all of them, then integrated the forks"

    As opposed to doing the same thing with precompiled dependencies that break whenever you try to support a new (OS, arch) pair?

    This, dear boy, is what static linking is for.  You release unto the earth a 111 MB executable binary containing every single dependency your app needs.  Then all you need is the ability to run ELF binaries in the target architecture, and since every architecture just boils down to Intel x86 nowadays, you have a universal program!

     



  • @drurowin said:

    You release unto the earth a 111 MB executable binary containing every single dependency your app needs.

    You should probably include some schematics of an x86 processor in there, just to be safe. And maybe a digitized physics textbook in case people forget how to make transistors.



  • @drurowin said:

    since every architecture just boils down to Intel x86 nowadays, you have a universal program!

     

    That's what Intel believed when they opted out of that tiny, irrelevant mobile industry.



  • http://i.imgur.com/TXvU8eL.png

    I'm running a few Go programs in my house. One of them is cbfs, which is a fully functional distributed file server/abstract object store. I have three nodes, one Debian, one Fedora, and one WinXP.

    Of course, it needs to store data in a database, so I'm also running cbgb. How big are these programs, including all dependencies?

    ben@loads bin$ du --si --total cbfs cbgb
    7.6M	cbfs
    12M	cbgb
    20M	total

    I'm running a file sharing service that will continue working even if half of the computers in my house cease to exist. And it's easy enough for my parents to use. And it weighs 20 megabytes.



  • @Ben L. said:

    I'm running a file sharing service that will continue working even if half of the computers in my house cease to exist. And it's easy enough for my parents to use.

    Very convenient, that way they don't have to go down in their basement and knock on your door when they can't access the 2nd season of Falcon Crest they asked you to download last weekend.



  • @Ben L. said:

    Of course, it needs to store data in a database, so I'm also running cbgb. How big are these programs, including all dependencies?

    That's not huge, but the entire httpd executable on my machine is only 1.7m. And MySQL is 12m. And both do way more than what your little.. whatever the hell it is does.

    The real fun of static linking comes in when you want to run more than 1 or 2 applications. Right now I probably have about 200 binaries running on my machine. If those were written in Go and needed copies of every library statically linked.. well, that would several hundred megs of wasted memory.

    And that's just one of several reasons why static linking is stupid, which I've covered exhaustively before but you don't seem to want to listen or learn.



  • @morbiuswilters said:

    @Ben L. said:
    Of course, it needs to store data in a database, so I'm also running cbgb. How big are these programs, including all dependencies?

    That's not huge, but the entire httpd executable on my machine is only 1.7m. And MySQL is 12m. And both do way more than what your little.. whatever the hell it is does.

    ben@loads ~$ du --si /usr/lib64/mysql/
    15M	/usr/lib64/mysql/
    ben@loads ~$ du --si /usr/bin/mysql* --total
    40M	total
    ben@loads ~$ ldd /usr/bin/mysql
    	linux-vdso.so.1 =>  (0x00007fff727fe000)
    	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003626200000)
    	libz.so.1 => /lib64/libz.so.1 (0x0000003626e00000)
    	librt.so.1 => /lib64/librt.so.1 (0x0000003626a00000)
    	libssl.so.10 => /lib64/libssl.so.10 (0x000000363be00000)
    	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003635a00000)
    	libdl.so.2 => /lib64/libdl.so.2 (0x0000003626600000)
    	libncurses.so.5 => /lib64/libncurses.so.5 (0x000000363c600000)
    	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x000000363ce00000)
    	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003628600000)
    	libm.so.6 => /lib64/libm.so.6 (0x0000003625e00000)
    	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003627200000)
    	libc.so.6 => /lib64/libc.so.6 (0x0000003625a00000)
    	/lib64/ld-linux-x86-64.so.2 (0x0000003625600000)
    	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003632a00000)
    	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x000000362f600000)
    	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000362e200000)
    	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003631e00000)
    	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003632e00000)
    	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000362ea00000)
    	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003627e00000)
    	libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003627a00000)
    	libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003627600000)
    ben@loads ~$ ldd ~/go/bin/cbgb
    	not a dynamic executable
    


  • @Ben L. said:

    @morbiuswilters said:
    @Ben L. said:
    Of course, it needs to store data in a database, so I'm also running cbgb. How big are these programs, including all dependencies?

    That's not huge, but the entire httpd executable on my machine is only 1.7m. And MySQL is 12m. And both do way more than what your little.. whatever the hell it is does.

    ben@loads ~$ du --si /usr/lib64/mysql/
    15M	/usr/lib64/mysql/
    ben@loads ~$ du --si /usr/bin/mysql* --total
    40M	total
    ben@loads ~$ ldd /usr/bin/mysql
    	linux-vdso.so.1 =>  (0x00007fff727fe000)
    	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003626200000)
    	libz.so.1 => /lib64/libz.so.1 (0x0000003626e00000)
    	librt.so.1 => /lib64/librt.so.1 (0x0000003626a00000)
    	libssl.so.10 => /lib64/libssl.so.10 (0x000000363be00000)
    	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003635a00000)
    	libdl.so.2 => /lib64/libdl.so.2 (0x0000003626600000)
    	libncurses.so.5 => /lib64/libncurses.so.5 (0x000000363c600000)
    	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x000000363ce00000)
    	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003628600000)
    	libm.so.6 => /lib64/libm.so.6 (0x0000003625e00000)
    	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003627200000)
    	libc.so.6 => /lib64/libc.so.6 (0x0000003625a00000)
    	/lib64/ld-linux-x86-64.so.2 (0x0000003625600000)
    	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003632a00000)
    	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x000000362f600000)
    	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000362e200000)
    	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003631e00000)
    	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003632e00000)
    	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000362ea00000)
    	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003627e00000)
    	libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003627a00000)
    	libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003627600000)
    ben@loads ~$ ldd ~/go/bin/cbgb
    	not a dynamic executable
    

     

     Are you trying to pass off the C/C++-libraries and SSL as bagagge go doesn't have? That's dumb. I mean, really dumb.

    - All of these things are on your host-OS (and running) anyway, so you save nothing

    - I would feel a lot safer if go actually used an official library, instead of forks of repositories. That way there was I chance I could be warned of security vulnerabilities, since nobody updates read-only forks. Ever.

     



  • Re: your all morans

    Why does everyone think that implementing a spec is something that only high elf wizards with 152 points in charisma can do? It's not something you can get subtly wrong unless you try to write clever code.



  • @Ben L. said:

    Why does everyone think that implementing a spec is something that only high elf wizards with 152 points in charisma can do? It's not something you can get subtly wrong unless you try to write clever code.

    History says otherwise.



  • @Salamander said:

    @Ben L. said:

    Why does everyone think that implementing a spec is something that only high elf wizards with 152 points in charisma can do? It's not something you can get subtly wrong unless you try to write clever code.

    History says otherwise.

    Tell me, then: what subtle bugs are there in, say, the entire ECDSA package?


  • @Ben L. said:

    Tell me, then: what subtle bugs are there in, say, the entire ECDSA package?

    How about this: you prove that Go has a cryptographically secure random number generator.
    And no, calling something cryptographically secure does not make it so.



  • @Salamander said:

    @Ben L. said:
    Tell me, then: what subtle bugs are there in, say, the entire ECDSA package?

    How about this: you prove that Go has a cryptographically secure random number generator.
    And no, calling something cryptographically secure does not make it so.

    I am not sure what you're talking about.



  • function next_rand() {
    return 3; //Cryptographically secure
    }

    See the problem here?
    There is a difference between saying what something is, and what it actually is.



  • @Salamander said:

    function next_rand() {
    return 3; //Cryptographically secure
    }

    See the problem here?
    There is a difference between saying what something is, and what it actually is.

    So you're saying that OS APIs for randomness are incorrect when the language is one you don't know?


  • I'm saying I haven't seen it, so for all I know it could be generating random numbers by monitoring a cow's brain.



  • @Salamander said:

    I'm saying I haven't seen it, so for all I know it could be generating random numbers by monitoring a cow's brain.

    Since you're a paraplegic and incapable of clicking links, I'll help you out. This time.

    Reader is a global, shared instance of a cryptographically strong pseudo-random generator. On Unix-like systems, Reader reads from /dev/urandom. On Windows systems, Reader uses the CryptGenRandom API.



    [Please don't post 72pt font to make your point. -TheShadowMod]



  • @Ben L. said:

    Why does everyone think that implementing a spec is something that only high elf wizards with 152 points in charisma can do?

    Because experience.



  • @Ben L. said:

    Since you're a paraplegic and incapable of clicking links, I'll help you out. This time.

    Yes, that's what it says it does. Now prove that it does it.
    I'm normally not this skeptical, but given Go's track record of being fucking retarded I feel it's necessary.



  • @flabdablet said:

    @Ben L. said:
    Why does everyone think that implementing a spec is something that only high elf wizards with 152 points in charisma can do?

    Because experience.

    That's a nice example of:

    • clever code
    • using preexisting libraries
    • the opposite of what you're trying to prove
    You actually posted something resembling cryptography, though, so you get an A for effort.


  • @Ben L. said:

    That's a nice example of:

    • clever code
    • using preexisting libraries
    • the opposite of what you're trying to prove
    You actually posted something resembling cryptography, though, so you get an A for effort.

    How is it clever code? It's a call to the random number generator's update function, something likely exists in just about every RNG.
    Besides, what isn't immediately obvious in that article was the change was made by Debian, not the package maintainer.
    More commonly known as someone who wouldn't know cryptography if it bit them in the private key.



  • @Ben L. said:

    @morbiuswilters said:
    @Ben L. said:
    Of course, it needs to store data in a database, so I'm also running cbgb. How big are these programs, including all dependencies?

    That's not huge, but the entire httpd executable on my machine is only 1.7m. And MySQL is 12m. And both do way more than what your little.. whatever the hell it is does.

    ben@loads ~$ du --si /usr/lib64/mysql/
    15M	/usr/lib64/mysql/
    ben@loads ~$ du --si /usr/bin/mysql* --total
    40M	total
    ben@loads ~$ ldd /usr/bin/mysql
    	linux-vdso.so.1 =>  (0x00007fff727fe000)
    	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003626200000)
    	libz.so.1 => /lib64/libz.so.1 (0x0000003626e00000)
    	librt.so.1 => /lib64/librt.so.1 (0x0000003626a00000)
    	libssl.so.10 => /lib64/libssl.so.10 (0x000000363be00000)
    	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003635a00000)
    	libdl.so.2 => /lib64/libdl.so.2 (0x0000003626600000)
    	libncurses.so.5 => /lib64/libncurses.so.5 (0x000000363c600000)
    	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x000000363ce00000)
    	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003628600000)
    	libm.so.6 => /lib64/libm.so.6 (0x0000003625e00000)
    	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003627200000)
    	libc.so.6 => /lib64/libc.so.6 (0x0000003625a00000)
    	/lib64/ld-linux-x86-64.so.2 (0x0000003625600000)
    	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003632a00000)
    	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x000000362f600000)
    	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000362e200000)
    	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003631e00000)
    	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003632e00000)
    	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000362ea00000)
    	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003627e00000)
    	libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003627a00000)
    	libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003627600000)
    ben@loads ~$ ldd ~/go/bin/cbgb
    	not a dynamic executable
    

    Which exactly proves my point, you idiot. Instead of having all of that code in a single executable, MySQL can take advantage of dynamic linking and have a much smaller memory footprint. If MySQL was written in Go.. well, first it wouldn't fucking work, but second the executable would be 300mb.



  • @Ben L. said:

    It's not something you can get subtly wrong unless you try to write clever code.

    You are a fucking moron. People have fucked up implementing specs since the beginning of time. Even the big hitters like OpenSSL have had a history of fuck-ups. But OpenSSL is mature, it's had time to fix those mistakes (or at least most of them). Go is ridiculously immature. I would have no faith in some fucking Go library to get things right. I've done security auditing and this is the shit you fail a software product for.

    "How mature is your cryptographic library?" "Oh, it was written last year by a gaggle of unemployed morons, Google employees and a high school kid."

    "How do you patch vulnerabilities when one is found in a system library?" "Oh, it's okay, Go doesn't use system libraries--it implements its own! That's right, they re-in-fuck-vented the fucking wheel!! But it's okay, assuming anyone ever finds the bug, you can just download the source and recompile every binary on the system! WHEEE!!"

    "Alright, I'm not passing this. And since passing a security audit was a prereq of getting that $10 million contract with that major healthcare provider, your company is now shit-out-of-luck. And guess who they're gonna blame that on when they read my report? Enjoy finding a new job, asshole."



  • @Salamander said:

    @Ben L. said:
    Tell me, then: what subtle bugs are there in, say, the entire ECDSA package?

    How about this: you prove that Go has a cryptographically secure random number generator.
    And no, calling something cryptographically secure does not make it so.

    I love this argument. "Hey, go dig through this shitpile of source and prove there are bugs. Otherwise, you must admit it is flawless."

    Yeahno. Traipsing through other peoples' shitty code to find security holes is something you charge $2000 /hr to do. I'm not traipsing through a shitty codebase to find bugs for a project I don't even like.



  • @Ronald said:

    @drurowin said:
    since every architecture just boils down to Intel x86 nowadays, you have a universal program!

     

     

    That's what Intel believed when they opted out of that tiny, irrelevant mobile industry.

     

    My Motorola smartphone is Intel-based, and blows the doors off even a Tegra3.

     



  • @morbiuswilters said:

    Which exactly proves my point, you idiot. Instead of having all of that code in a single executable, MySQL can take advantage of dynamic linking and have a much smaller memory footprint. If MySQL was written in Go.. well, first it wouldn't fucking work, but second the executable would be 300mb.

     

    Dynamic linking is what's wrong with Linux.  Either you end up with a distro like Debian Stable, or you end up in a Linux version of DLL hell.  Static linking fixes that by building in your dependencies at compile time so that you don't have to shit around with having the right versions of libraries on your system.  And yes, you can statically link MySQL with no modification to the existing source, making it more useful on a wider range of platforms.

     


  • Winner of the 2016 Presidential Election

    @drurowin said:

    DLL hell.

    I think .NET handles this problem nicely with Strong Name Keys. There's a simple, human-readable, unique identifier for each distinct version of each distinct assembly, and the OS (rather than the program) can search the current user directory, GAC, and system library directories without any real worry of loading the wrong library.

    They really should have made the signing process mandatory and more automagical in Visual Studio though.



  • @drurowin said:

    Dynamic linking is what's wrong with Linux.  Either you end up with a distro like Debian Stable, or you end up in a Linux version of DLL hell.

    There's plenty wrong with Linux, but dynamic linking ain't it. If your system used static linking it would waste gobs of memory. Besides, on a modern Linux distro you aren't supposed to statically link anything.

    @drurowin said:

    Static linking fixes that by building in your dependencies at compile time so that you don't have to shit around with having the right versions of libraries on your system.

    At the cost of bloated binaries and tons of wasted memory.

    @drurowin said:

    And yes, you can statically link MySQL with no modification to the existing source, making it more useful on a wider range of platforms.

    Not reliably or correctly, you can't. There are tools that try to glom the shared libraries into a new, static executable, but they're pretty shitty. Expect random segfaults and difficult-to-debug errors. And say goodbye to ASLR (although if you're advocating static linking I can't imagine you'd know enough to use it.) Oh, and they're still PIC, so you don't even gain any advantage in performance.

    Besides, statically linking libc has been discouraged for a very long time. You want shit like NSS or locales to work? Don't use static linking. It's basically only reliable to produce a program that can be run on exactly the same system it was built on.

    And then, I will once again mention the nightmare of trying to keep all of these applications up-to-date. If you're dynamically linking against libc and a bug is fixed, you only have to update libc. If you are statically linking now you have dozens (or hundreds) of programs which need to be patch. Have fun sorting that one out, asshole. This is why static linking is dumb. I can't think of a mainstream OS which doesn't use dynamic linking because static linking is fucking wrong.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.