So I tried Go the other day


  • Considered Harmful

    @stillwater I tried Go once, it was awful. Thank god I'm back.


  • Notification Spam Recipient

    "I went back to C++ after trying out Go and I didn't realize how good C++ was. Thank God I'm WIndows.h not found"



  • @Tsaukpaetra Does C++ ever work on Windows? I've tried so many times and it always starts with instructions that say install build tools for C++ and after a couple hours am having hard liquor. Everything in between is a blur of frustration


  • Notification Spam Recipient

    @stillwater said in So I tried Go the other day:

    @Tsaukpaetra Does C++ ever work on Windows? I've tried so many times and it always starts with instructions that say install build tools for C++ and after a couple hours am having hard liquor. Everything in between is a blur of frustration

    Well, so far I haven't actually gotten my simple Go project to do more than write "Hello World!" to the screen, though in theory it could hold Game not-an-objects. Maybe if the office is all packed up tomorrow and I'm completely not busy, I'll resume...


  • BINNED

    @stillwater Not to sound too much like @pie_flavor but:

    1. Install Visual Studio
    2. Click build.

    Could take a bit longer if as step 1.5 you try to understand the horrendous settings dialog first.



  • @stillwater said in So I tried Go the other day:

    @Tsaukpaetra Does C++ ever work on Windows? I've tried so many times and it always starts with instructions that say install build tools for C++ and after a couple hours am having hard liquor. Everything in between is a blur of frustration

    Cross platform libraries are a pain, because C++ hasn't come up with a standard for packaging libraries, because there are too many different standards at play (and a million libs with their own ❄ build steps). And since different compilers are incompatible, you can't just distribute binaries either.

    So if you need to use other people's libraries in your project, you have to create a Frankenstein build that incorporates the build systems of all your dependencies, and finally get your bit of the system to compile and link against them.

    If you are working on something with few or no dependencies, it's pretty easy though. As described above, install vs, create a solution, write code, click build and run.



  • @anonymous234 said in So I tried Go the other day:

    I hate the "global variables are bad" meme. Global variables store global state. Global state is a thing that most programs, by necessity, have.

    Fun fact: when I started working on NodeBB one of the first commits I made was to use the sessions handling code provided by express. I didn't really know what I was doing, so I saved the active UID as a global 👍

    That made for some fun times until I realised global really meant global.



  • @Kian I tried installing CUDA and keras on Windows. I've installed more binaries and libraries and dependencies than you were will unless you also get yourself involved in painful shit



  • @stillwater I'm not sure whether you are agreeing or disagreeing with me here.



  • @Kian I agree with you. I was just pointing out I've done the worst case of what you said in your post. I needed to install a deep learnin framework on windows and it required lot of c++ shenanigans it took me two whole fucking days to get it right. On the other hand, ubuntu took just about a day.

    Just typing this out gave me depression. Nobody should have to install CUDA for deep learning on Windows!


  • Discourse touched me in a no-no place

    @Kian said in So I tried Go the other day:

    Cross platform libraries are a pain, because C++ hasn't come up with a standard for packaging libraries, because there are too many different standards at play (and a million libs with their own ❄ build steps). And since different compilers are incompatible, you can't just distribute binaries either.

    That's a problem particularly on Windows; other platforms tend to specify the ABI (and provide a basic system service core) to the point where redistributing binary libraries is nearly trivial. It's still a bit messier than it ought to be because of the way C++ tangles pieces of the language/standard-library definition all over the place, but that's actually manageable once you know what's going on. (Mixing things up between C++14 and C++17 will give seriously inscrutable errors, especially in gcc, though clang is — unusually — pretty confusing here too.)


  • BINNED

    @dkf On the other hand, on Windows you can just ship the CRT DLLs alongside your application and it works fine. On Linux, if the target system’s libc is older than the one you’ve built against, you’re in for a world of hurt.


  • Discourse touched me in a no-no place

    @topspin said in So I tried Go the other day:

    On Linux, if the target system’s libc is older than the one you’ve built against, you’re in for a world of hurt.

    It's not usually a problem. Libc receives very few incompatible changes by comparison with most things (assuming you're not so foolish as to be poking around in the system-specific syscalls, which are less stable). Compare with the C++ compiler/header/standard library combination, which must be matched or you end up with things breaking in ways that make no sense at all. :sadface:

    BTDT…


  • BINNED

    @dkf said in So I tried Go the other day:

    It's not usually a problem. Libc receives very few incompatible changes by comparison with most things

    Doesn't matter. Backwards compatibility doesn't help you when the system you're trying to run on is too old, only the other way around.

    foobar: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by foobar)
    foobar: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.7' not found (required by foobar)
    foobar: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by foobar)
    

    And packaging your own libc.so just fucks everything up.


  • Notification Spam Recipient

    @topspin said in So I tried Go the other day:

    @dkf said in So I tried Go the other day:

    It's not usually a problem. Libc receives very few incompatible changes by comparison with most things

    Doesn't matter. Backwards compatibility doesn't help you when the system you're trying to run on is too old, only the other way around.

    foobar: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by foobar)
    foobar: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.7' not found (required by foobar)
    foobar: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by foobar)
    

    And packaging your own libc.so just fucks everything up.

    Solution: Package the whole OS, kernel and all, into a single thing!


  • BINNED

    @Tsaukpaetra That is a “solution” maybe, but surely a shitty one. What if every application did this?
    Or maybe they do, that’s why a calculator app is 3GB these days. Might as well bundle Node while I’m at it.


Log in to reply