Programming thread

[General Tug Boat]

First time poster in this thread, now any of the other programming buffs out there have any type of resources I can utilize to learn 8502 assembly while we are under this quarantine bullshit. I am about a year into control systems in college and I just can't really find any useful type of guides on this subject. I have a couple of different controllers I have tinkered with to do some basic shit, but kinda wanna see if anyone has any resources for this type of thing. I have a good enough knowledge in C now that I am comfortable to moving to moving onto assembly.

 

[FuckedUp]

First time poster in this thread, now any of the other programming buffs out there have any type of resources I can utilize to learn 8502 assembly while we are under this quarantine bullshit. I am about a year into control systems in college and I just can't really find any useful type of guides on this subject. I have a couple of different controllers I have tinkered with to do some basic shit, but kinda wanna see if anyone has any resources for this type of thing. I have a good enough knowledge in C now that I am comfortable to moving to moving onto assembly.

I think the 6502 is basically identical.

Have you tried MIC-1? I've done both assembly and microcode programming for it for school assignments. First assembly language I learned for school was MIPS, and it's also good. Hell, x86 assembly isn't as horrifically complex as it's made out to be.

 

[General Tug Boat]

I think the 6502 is basically identical.

Have you tried MIC-1? I've done both assembly and microcode programming for it for school assignments. First assembly language I learned for school was MIPS, and it's also good. Hell, x86 assembly isn't as horrifically complex as it's made out to be.

Opps sorry I fucked up I meant 6502, I've explored x86 atm just kinda perplexes me because of the range of instruction set. Though the tutorials I've found on the x86 start to lose me fairly quickly. I haven't quite heard of MIC-1 or MIPS. I'll give that a gander actually. Seems from the tutorial I've skimmed through it is a comprehensive language.

 

[010101]

A good way to learn how to code in assembly is to take a C compiler, write basic programs and compile them to assembly. You'll see how the compiler constructs some basic shit at different optimisation levels instead of trying to figure it out yourself.

 

[Ex Cummunicated Sasser HD]

A good way to learn how to code in assembly is to take a C compiler, write basic programs and compile them to assembly. You'll see how the compiler constructs some basic shit at different optimisation levels instead of trying to figure it out yourself.

This is really good advice for anyone trying to do old assembler... Shit, even start with C or C+++, then see what your compiler output is...

 

[MrBlueSocks]

Modern C++ experts please:
I am a fairly experienced C++ coder, but for various reasons have never needed or been able to move from C++ 03 standard.
We've only just started using C++ 11 in places. But as a 03 guy lookingto write in 17, what do I need to know?

My question isn't "What are the differences between the standards", I could get that from all over the net e.g.

AnthonyCalandra/modern-cpp-features

A cheatsheet of modern C++ language and library features. - AnthonyCalandra/modern-cpp-features

github.com

AnthonyCalandra/modern-cpp-features

A cheatsheet of modern C++ language and library features. - AnthonyCalandra/modern-cpp-features

github.com

AnthonyCalandra/modern-cpp-features

A cheatsheet of modern C++ language and library features. - AnthonyCalandra/modern-cpp-features

github.com

But rather: How should I mentally transistion to the later versions in order to use them correctly? It's too easy to just use language features, but not to any real benefit. I've seen enough crappy code in my time where someone brought up on one language has enough intelligence to work in another, but writes ugly incorrect code, not understanding the native idioms etc.

Any websites, or books anyone could recommend?
Or have I got this wrong? The essence of C++ hasn't changed, and it's safe to use new features at random without worrying about idiomatic correctness.

To be honest, I think I'm more worried about other people I work with producing nightmare code . But it'd be nice to be a paragon of good practice.

Also , I am a bit of a grumpy old fuck about all the extra stuff they've added. Sure it's cool (I guess, nerd) , but what has it really improved? Do all the extra 100 language feature lead to cleaner, less buggy, easy to maintain code? Some obviously do, but I've never seen the desperate need for Lambda functions.

Googling my own answer. I notice Meyers has an Effective Modern C++ . His STL books were gospel years ago. Is he still the go to for this problem?

 

[Lambda]

Opps sorry I fucked up I meant 6502, I've explored x86 atm just kinda perplexes me because of the range of instruction set. Though the tutorials I've found on the x86 start to lose me fairly quickly. I haven't quite heard of MIC-1 or MIPS. I'll give that a gander actually. Seems from the tutorial I've skimmed through it is a comprehensive language.

You could also write a VM for the chip and an assembler with the goal of getting a working program running on it with identical outputs on both. Assembly just comes down to thinking about things a certain way and knowing instructions and how to manage registers and memory. There's a lot more that you can learn on top of that, but that low level mindset can be learned by just having a good understanding of how the chip operates.

 

[Strange Looking Dog]

Modern C++ experts please:
I am a fairly experienced C++ coder, but for various reasons have never needed or been able to move from C++ 03 standard.
We've only just started using C++ 11 in places. But as a 03 guy lookingto write in 17, what do I need to know?

Constexpr is really nice, it lets you write much cleaner templating code in some areas.

constexpr size_t CompiletimeFibonacci(size_t count) {
    if (count < 1) {
        return 0;
    } else if (count < 2) {
        return 1;
    } else {
        size_t prev = 1, cur = 1;
        for (size_t i = 2; i < count; i++) {
            auto val = cur + prev;
            prev = cur, cur = val; // Note that commas now have a strong ordering garuntee
        }
        return cur;
    }
}

int main() {
    int myInts[CompiletimeFibonacci(12)]; // No need for macros here
}

Lambdas are also great, they're a little weird to deal with because they have no named type, but so long as they don't capture any local variables they are convertible to function pointers.
R-value refs are also a thing now, they look like && and are used to represent "decaying" objects, like the results of expressions. They can also help with type deduction in templated functions.

template<typename T, typename TFunc>
T LoopOnThing(size_t count, TFunc&& func, T&& initial) { // Pass as r-value ref
    T value{std::move(initial)}; // Move initialize our value, this allows for resource reuse
    for (size_t i = 0; i < count; i++) {
        value = func(value, i); // Invoke our function object in a loop
    }
    return value;
}

int main() {
    std::string startingText{"My int sequence; "};
    size_t count = 5;
    int myInts[count] {
        1, 2, 3, 5, 6
    };
    std::string result = LoopOnThing(count,
        // A lambda taking an string and a size_t, and returning a string.
        // It captures everything by reference.
        [&](const std::string& str, size_t i)->std::string{
            std::string newStr{str + std::to_string(myInts[i])}; // Inefficient, I'm aware
            if (i < count-1)
                newStr += ", "; // Conditionally add comma, based on captured value of count
            return newStr;
        },
        std::move(startingText)
    );
    
    std::cout << result << std::endl;
}

Auto typing is also a thing, I'd recommend doing it where ever possible, but remember that refs are implicitly typed as values by auto variables, so use auto& if you want to capture a ref.

// We can rewrite our loop method to use auto type deduction, though it's still best that we specify the type it operates on.
template<typename T>
T LoopOnThing(size_t count, auto&& func, T&& initial) { // No need to specify function type
    T value{std::move(initial)};

    for (size_t i = 0; i < count; i++) {
        value = func(value, i);
    }

    return value;
}

// Putting it all together
template<size_t count>
auto RecurseLoop(auto&& value, auto&& func) {
    if constexpr (count < 1) { // If statements can now evaluate at compile time
        return value; // This means the return type of func can vary throughout RecurseLoop
    } else {
        return RecurseLoop<count - 1>(func(value, count - 1), std::move(func));
    }
}

int main() {
    auto result = RecurseLoop<4>(2ull, // Specifying the seed type is unnecessary but wise to do.
        [](auto val, auto){
            return val * val;
        }
    );
    std::cout << result << std::endl;

    return 0;
}

I've already used up too much screen space with this nonsense, but there's a lot more that's been added, like tuples and type traits. Generally C++ templating is a lot more powerful than it used to be, and it's easy to get carried away. The best way to learn is to try it out yourself, I'd recommend just fucking around with the new templating features and seeing what you can make.
Templating is great for automating things, so think of some kind of boilerplate you find yourself rewriting all the time and see if you can convert it to a template function. As they say, c++ is just c with vectors, but it's kind of true. That said, vectors and other template constructs are kind of a big deal, being that they can make your code more concise and more readable though they can also make your error messages markedly less readable

 

[MrBlueSocks]

Constexpr is really nice, it lets you write much cleaner templating code in some areas.

constexpr size_t CompiletimeFibonacci(size_t count) {
    if (count < 1) {
        return 0;
    } else if (count < 2) {
        return 1;
    } else {
        size_t prev = 1, cur = 1;
        for (size_t i = 2; i < count; i++) {
            auto val = cur + prev;
            prev = cur, cur = val; // Note that commas now have a strong ordering garuntee
        }
        return cur;
    }
}

int main() {
    int myInts[CompiletimeFibonacci(12)]; // No need for macros here
}

Lambdas are also great, they're a little weird to deal with because they have no named type, but so long as they don't capture any local variables they are convertible to function pointers.
R-value refs are also a thing now, they look like && and are used to represent "decaying" objects, like the results of expressions. They can also help with type deduction in templated functions.

template<typename T, typename TFunc>
T LoopOnThing(size_t count, TFunc&& func, T&& initial) { // Pass as r-value ref
    T value{std::move(initial)}; // Move initialize our value, this allows for resource reuse
    for (size_t i = 0; i < count; i++) {
        value = func(value, i); // Invoke our function object in a loop
    }
    return value;
}

int main() {
    std::string startingText{"My int sequence; "};
    size_t count = 5;
    int myInts[count] {
        1, 2, 3, 5, 6
    };
    std::string result = LoopOnThing(count,
        // A lambda taking an string and a size_t, and returning a string.
        // It captures everything by reference.
        [&](const std::string& str, size_t i)->std::string{
            std::string newStr{str + std::to_string(myInts[i])}; // Inefficient, I'm aware
            if (i < count-1)
                newStr += ", "; // Conditionally add comma, based on captured value of count
            return newStr;
        },
        std::move(startingText)
    );
  
    std::cout << result << std::endl;
}

Auto typing is also a thing, I'd recommend doing it where ever possible, but remember that refs are implicitly typed as values by auto variables, so use auto& if you want to capture a ref.

// We can rewrite our loop method to use auto type deduction, though it's still best that we specify the type it operates on.
template<typename T>
T LoopOnThing(size_t count, auto&& func, T&& initial) { // No need to specify function type
    T value{std::move(initial)};

    for (size_t i = 0; i < count; i++) {
        value = func(value, i);
    }

    return value;
}

// Putting it all together
template<size_t count>
auto RecurseLoop(auto&& value, auto&& func) {
    if constexpr (count < 1) { // If statements can now evaluate at compile time
        return value; // This means the return type of func can vary throughout RecurseLoop
    } else {
        return RecurseLoop<count - 1>(func(value, count - 1), std::move(func));
    }
}

int main() {
    auto result = RecurseLoop<4>(2ull, // Specifying the seed type is unnecessary but wise to do.
        [](auto val, auto){
            return val * val;
        }
    );
    std::cout << result << std::endl;

    return 0;
}

I've already used up too much screen space with this nonsense, but there's a lot more that's been added, like tuples and type traits. Generally C++ templating is a lot more powerful than it used to be, and it's easy to get carried away. The best way to learn is to try it out yourself, I'd recommend just fucking around with the new templating features and seeing what you can make.
Templating is great for automating things, so think of some kind of boilerplate you find yourself rewriting all the time and see if you can convert it to a template function. As they say, c++ is just c with vectors, but it's kind of true. That said, vectors and other template constructs are kind of a big deal, being that they can make your code more concise and more readable though they can also make your error messages markedly less readable

Cheers,

I've ordered myself Effective Modern C++ by Meyers and A Tour of C++ (Second Edition) by uncle Bjarne .
Also had a look at the worlds longest wiki article .

I can kind of see the point of most of the additions, I've no doubt that people far cleverer and knowledgeable than I spent a lot of time thinking this through. Auto type variables are useful, esp for iterators etc. They make code less brittle to changes in e.g. container choice. (But I think brittle can be quite good, if it's compile time failure. ) Templates always had a few weird limitations that I guess I got used to, but new programmers always hit. It looks like this has been an area of focus.
I think I'll read these books and work my way into it.
As I said in my first post, I'm not concerned about using these concepts, I want to make sure I'm using them in the right way.
Especially as these additions have given C++ that Java-like feeling of too many different ways to achieve the same thing.
I need to start thinking natively in the new techniques, rather than e.g. mentally calling Lambdas "Stupid invisible magic anonymous function objects" . I know they are useful, I've been told so. Just not feeling it yet .

Also found an e book download of the Meyers book, which I downloaded. Not sure if my machine has the Corona now. Seems legit.
ETA:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

Also looks very useful, if large. Depending how long I'm locked down I may get through all these.

 

[Chad Nasty]

Constexpr is really nice, it lets you write much cleaner templating code in some areas.

constexpr size_t CompiletimeFibonacci(size_t count) {
    if (count < 1) {
        return 0;
    } else if (count < 2) {
        return 1;
    } else {
        size_t prev = 1, cur = 1;
        for (size_t i = 2; i < count; i++) {
            auto val = cur + prev;
            prev = cur, cur = val; // Note that commas now have a strong ordering garuntee
        }
        return cur;
    }
}

int main() {
    int myInts[CompiletimeFibonacci(12)]; // No need for macros here
}

Lambdas are also great, they're a little weird to deal with because they have no named type, but so long as they don't capture any local variables they are convertible to function pointers.
R-value refs are also a thing now, they look like && and are used to represent "decaying" objects, like the results of expressions. They can also help with type deduction in templated functions.

template<typename T, typename TFunc>
T LoopOnThing(size_t count, TFunc&& func, T&& initial) { // Pass as r-value ref
    T value{std::move(initial)}; // Move initialize our value, this allows for resource reuse
    for (size_t i = 0; i < count; i++) {
        value = func(value, i); // Invoke our function object in a loop
    }
    return value;
}

int main() {
    std::string startingText{"My int sequence; "};
    size_t count = 5;
    int myInts[count] {
        1, 2, 3, 5, 6
    };
    std::string result = LoopOnThing(count,
        // A lambda taking an string and a size_t, and returning a string.
        // It captures everything by reference.
        [&](const std::string& str, size_t i)->std::string{
            std::string newStr{str + std::to_string(myInts[i])}; // Inefficient, I'm aware
            if (i < count-1)
                newStr += ", "; // Conditionally add comma, based on captured value of count
            return newStr;
        },
        std::move(startingText)
    );
   
    std::cout << result << std::endl;
}

Auto typing is also a thing, I'd recommend doing it where ever possible, but remember that refs are implicitly typed as values by auto variables, so use auto& if you want to capture a ref.

// We can rewrite our loop method to use auto type deduction, though it's still best that we specify the type it operates on.
template<typename T>
T LoopOnThing(size_t count, auto&& func, T&& initial) { // No need to specify function type
    T value{std::move(initial)};

    for (size_t i = 0; i < count; i++) {
        value = func(value, i);
    }

    return value;
}

// Putting it all together
template<size_t count>
auto RecurseLoop(auto&& value, auto&& func) {
    if constexpr (count < 1) { // If statements can now evaluate at compile time
        return value; // This means the return type of func can vary throughout RecurseLoop
    } else {
        return RecurseLoop<count - 1>(func(value, count - 1), std::move(func));
    }
}

int main() {
    auto result = RecurseLoop<4>(2ull, // Specifying the seed type is unnecessary but wise to do.
        [](auto val, auto){
            return val * val;
        }
    );
    std::cout << result << std::endl;

    return 0;
}

I've already used up too much screen space with this nonsense, but there's a lot more that's been added, like tuples and type traits. Generally C++ templating is a lot more powerful than it used to be, and it's easy to get carried away. The best way to learn is to try it out yourself, I'd recommend just fucking around with the new templating features and seeing what you can make.
Templating is great for automating things, so think of some kind of boilerplate you find yourself rewriting all the time and see if you can convert it to a template function. As they say, c++ is just c with vectors, but it's kind of true. That said, vectors and other template constructs are kind of a big deal, being that they can make your code more concise and more readable though they can also make your error messages markedly less readable

This is cool, I've started learning Go and its kinda cool to see some of the similarities.

With that in mind, I want to share a vid by Rob Pike. I thought it did a great job talking about concurrent programming and parallelism

Rob Pike - 'Concurrency Is Not Parallelism'

Rob (@rob_pike) is a software pioneer. His influence is everywhere: Unix, Plan 9 OS, The Unix Programming Environment book, UTF-8, and most recently the Go p...

www.youtube.com

 

[Shoggoth]

Rob Pike is a very intelligent man who designed a language for people he thinks are trained monkeys who write code by rolling their face on their keyboard. CSP is nice but I'd really rather write in any other language than Go.

 

[Chad Nasty]

Rob Pike is a very intelligent man who designed a language for people he thinks are trained monkeys who write code by rolling their face on their keyboard. CSP is nice but I'd really rather write in any other language than Go.

If he does feel that way he does a good job hiding it and wastes time talking about why he made it the way he did. I came from C# and at first I didn't see the point until the use of unix like piping and communication through channels. The simplicity is a thing I really appreciate from Golang

dotGo 2015 - Rob Pike - Simplicity is Complicated

Go is often described as a simple language. It is not, it just seems that way. Rob explains how Go's simplicity hides a great deal of complexity, and that bo...

www.youtube.com

 

[Shoggoth]

If he does feel that way he does a good job hiding it and wastes time talking about why he made it the way he did. I came from C# and at first I didn't see the point until the use of unix like piping and communication through channels. The simplicity is a thing I really appreciate from Golang

dotGo 2015 - Rob Pike - Simplicity is Complicated

Go is often described as a simple language. It is not, it just seems that way. Rob explains how Go's simplicity hides a great deal of complexity, and that bo...

www.youtube.com

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

see:

From Parallel to Concurrent

At Google I was involved in the design and implementation of two significant languages. The first, Sawzall, was extremely parallel. The second, Go, is fundamentally concurrent. I will explain the reas

channel9.msdn.com

Go at Google: Language Design in the Service of Software Engineering

You're taking the conversation a bit back to where we shat on unix pipes here. The idea of processes communicating with pipes? Good shit. Unix pipes? pretty crap.
You can implement CSP in any language (for example Clojure did it, look up core.async).
Where performance counts you'll use C, C++ or Rust, where stability and scalability are concerned I'd prefer the JVM. For expressiveness I'd pick ML languages or even Java over Go.
So what is its utility? Writing shitty wrappers and orchestrators? If so, I don't see why people are shilling it like it's the best thing since tummy rubs.

It's just "that ok language you use to get going fast and ditch later when your application gets serious" niche that python used to occupy.

 

[Vecr]

I'll admit that Go is quite good when you run it on the Google cloud, but it kind of glosses over any difference in platforms, but can't do it perfectly, so it causes some very weird issues when not run in a controlled environment.

 

[Chad Nasty]

see:

From Parallel to Concurrent

At Google I was involved in the design and implementation of two significant languages. The first, Sawzall, was extremely parallel. The second, Go, is fundamentally concurrent. I will explain the reas

channel9.msdn.com

Go at Google: Language Design in the Service of Software Engineering

You're taking the conversation a bit back to where we shat on unix pipes here. The idea of processes communicating with pipes? Good shit. Unix pipes? pretty crap.
You can implement CSP in any language (for example Clojure did it, look up core.async).
Where performance counts you'll use C, C++ or Rust, where stability and scalability are concerned I'd prefer the JVM. For expressiveness I'd pick ML languages or even Java over Go.
So what is its utility? Writing shitty wrappers and orchestrators? If so, I don't see why people are shilling it like it's the best thing since tummy rubs.

It's just "that ok language you use to get going fast and ditch later when your application gets serious" niche that python used to occupy.

The point made in the msdn video seems like a departure from what he expressed in the video I posted. Go is simple and I like that. I like how channels are less expensive than threading and also I like how easy it is to handle race conditions. I like that (right now at least) it handles a lot of the memory management, and has a real keen garbage collector. There are definitely things I don't like about it especially coming at it as a C# developer. The simplicity of it is something I like, but also something that I hate that if I have to implement complex data structures. The best I could do is an embedded struct, and the data aggregation wouldn't be fun. Also, I don't like how it handles inheritance (interfaces, but go also tries to discourage inheritance). Another thing I found kind of cool is how easy scoping is. Oh, error handling is something I'm still weighing. I also don't like the setup.

There are other things, I just don't have the motivation to explain them in a way that doesn't make me sound like a sped.

I've seen a bunch of bench marks and a lot of people agree and disagree on whether go is useful. But that being said, its still very much in its infancy.

EDIT: I forgot to include on being a language to get a project off the ground quick: I can agree with the sentiment, but the past like 7 years I always equated the sentiment with JS ever since silicone valley bois creamed themselves to the MEAN stack

 

[He Who Points And Laughs]

Saw this on Twitter the other day and thought it was brilliant. Someone was looking for a way to covert a bunch of Java to Python. The best response was akin to this :

Post Java code on Stack Overflow.
Claim that Python can never be as elegant nor logical as Java.
Collected code from the flame war.

Apply to your needs.

 

[Shoggoth]

The point made in the msdn video seems like a departure from what he expressed in the video I posted. Go is simple and I like that. I like how channels are less expensive than threading and also I like how easy it is to handle race conditions. I like that (right now at least) it handles a lot of the memory management, and has a real keen garbage collector. There are definitely things I don't like about it especially coming at it as a C# developer. The simplicity of it is something I like, but also something that I hate that if I have to implement complex data structures. The best I could do is an embedded struct, and the data aggregation wouldn't be fun. Also, I don't like how it handles inheritance (interfaces, but go also tries to discourage inheritance). Another thing I found kind of cool is how easy scoping is. Oh, error handling is something I'm still weighing. I also don't like the setup.

There are other things, I just don't have the motivation to explain them in a way that doesn't make me sound like a sped.

I've seen a bunch of bench marks and a lot of people agree and disagree on whether go is useful. But that being said, its still very much in its infancy.

EDIT: I forgot to include on being a language to get a project off the ground quick: I can agree with the sentiment, but the past like 7 years I always equated the sentiment with JS ever since silicone valley bois creamed themselves to the MEAN stack

Well you mention a few interesting things here

• Sounding like a sped: we're all anons on the internet, sounding like a sped is a privilege, so don't mind if I go ahead and do
• go is simple: I agree that go looks simple but as a Rich Hickey fanboy I'll say it's easy, not simple. And It's damn easy, with tooling which makes your life even easier. But the second you have to peek under the hood you find the language is more of a disgusting veneer over C. The no generics argument is tired, but a language loses its elegance when you can't write generic algorithms. The best you have is code generation which is done badly and lisps solved 70 years ago.
• channels and threading: I think you might have had a typo or conflation there so I won't nitpick and try to answer the point I think you were making: I dislike goroutines. They're just submitting your work to a thread pool, big fucking deal. Oh, channels are amazing. Right, if you've never used them in high-performance anything. Channels are just synchronized queues. I.e. locking everywhere. Yes, the inversion of control is nice, allowing you to write sequential code instead of using callbacks, even though it's compiled to callbacks. Yes, the parking semantics are nice, but again you have that in other languages (mainly clojure). Those are really just tasks handled by a state machine in a thread pool. Nothing to be excited about. The stupidest thing about goroutines is they return nothing! So the only way to know it's finished is by passing channels. If they returned channels you could way more easily write code to synchronize different tasks.
• data structures, C#: have you tried F#? you might like it.
• Inheritance: lolno. Go disallows OwOP. Struct embedding is literally just struct concatenation in memory.
• scoping: please elaborate? I don't see what's special there.
• errors: I hate it.

As much as I like to poop on Go there's one thing I'll give it full credit for and it'll be cool to see similar things done in other languages: Its compiler. There's absolutely no reason why you couldn't use all the tricks and niceties in its compiler for any statically compiled language. Ironically, it'd take one of Go's strongest points from it, its fast build times. If you're into reading about Go and watching videos, I recommend watching Rob's talk on the golang assembler and reading the README inside the compiler's source dir.

 

[Chad Nasty]

Well you mention a few interesting things here

• Sounding like a sped: we're all anons on the internet, sounding like a sped is a privilege, so don't mind if I go ahead and do
• go is simple: I agree that go looks simple but as a Rich Hickey fanboy I'll say it's easy, not simple. And It's damn easy, with tooling which makes your life even easier. But the second you have to peek under the hood you find the language is more of a disgusting veneer over C. The no generics argument is tired, but a language loses its elegance when you can't write generic algorithms. The best you have is code generation which is done badly and lisps solved 70 years ago.
• channels and threading: I think you might have had a typo or conflation there so I won't nitpick and try to answer the point I think you were making: I dislike goroutines. They're just submitting your work to a thread pool, big fucking deal. Oh, channels are amazing. Right, if you've never used them in high-performance anything. Channels are just synchronized queues. I.e. locking everywhere. Yes, the inversion of control is nice, allowing you to write sequential code instead of using callbacks, even though it's compiled to callbacks. Yes, the parking semantics are nice, but again you have that in other languages (mainly clojure). Those are really just tasks handled by a state machine in a thread pool. Nothing to be excited about. The stupidest thing about goroutines is they return nothing! So the only way to know it's finished is by passing channels. If they returned channels you could way more easily write code to synchronize different tasks.
• data structures, C#: have you tried F#? you might like it.
• Inheritance: lolno. Go disallows OwOP. Struct embedding is literally just struct concatenation in memory.
• scoping: please elaborate? I don't see what's special there.
• errors: I hate it.

As much as I like to poop on Go there's one thing I'll give it full credit for and it'll be cool to see similar things done in other languages: Its compiler. There's absolutely no reason why you couldn't use all the tricks and niceties in its compiler for any statically compiled language. Ironically, it'd take one of Go's strongest points from it, its fast build times. If you're into reading about Go and watching videos, I recommend watching Rob's talk on the golang assembler and reading the README inside the compiler's source dir.

I appreciate the info.
When I was talking about threading/channels I meant in regards to how C# threads or does async awaits. I've heard about F#, but I haven't tried it. I had a friend doing AI for a company using F#.
I've kinda gravitated toward golang since I was looking for projects that could move my resume out of only being only a Microsoft tech stack and I kept seeing people pump up go (cough cough Ryan Dahl).
As far as knowing if goroutines are done, why wouldn't you be able to utilize the waitgroups functionality in go for this?
As far as scoping goes, go really only scopes variables on a package level or in the function. This to me is a lot simpler than things like block scoping in C#.
I called it inheritance because it was the closest word I could think when implementing interfaces and the fact that one type can be of multiple types. I've never come across things like embedded structs. But this is what I mean (https://play.golang.org/p/D5gWeboYem1)
And the error handling doesn't seem too robust, but a lot of functions automatically return an error by default. I believe this was by design to try facilitate a better way to pinpoint where an error is being thrown.

 

[Shoggoth]

I appreciate the info.
When I was talking about threading/channels I meant in regards to how C# threads or does async awaits. I've heard about F#, but I haven't tried it. I had a friend doing AI for a company using F#.
I've kinda gravitated toward golang since I was looking for projects that could move my resume out of only being only a Microsoft tech stack and I kept seeing people pump up go (cough cough Ryan Dahl).
As far as knowing if goroutines are done, why wouldn't you be able to utilize the waitgroups functionality in go for this?
As far as scoping goes, go really only scopes variables on a package level or in the function. This to me is a lot simpler than things like block scoping in C#.
I called it inheritance because it was the closest word I could think when implementing interfaces and the fact that one type can be of multiple types. I've never come across things like embedded structs. But this is what I mean (https://play.golang.org/p/D5gWeboYem1)
And the error handling doesn't seem too robust, but a lot of functions automatically return an error by default. I believe this was by design to try facilitate a better way to pinpoint where an error is being thrown.

Marvin can probably speak more on async/awaits but it's one of the problems of doing async in typed languages, since the async type-ness contaminates all the other types it touches, so from type T you suddenly need to work with Async<T>, which is where fancy-pants things like monads come in.
I understand wanting to touch up your resume, although you can run C# and F# nowadays on Mono. Go isn't a bad choice in this regard, I just personally dislike it. It probably will help you by exposing you to more opportunities, so it's not bad for that, I just think most companies opting to work with it are making a mistake because it's trendy.
Waitgroups are part of what makes goroutines annoying. Instead of the goroutine itself signalling via a variable it already returned that the job is done, you need to go to another variable then wait for it. It's as bad as using goto because you're doing one thing in one point of your program and waiting for it in a whole other place. Terrible software design.
Imagine the case where every async process returns a channel, you could wait on all processed by just:

<- merge(map(op, inputs))

But golang had to reinvent goto, and you got fucked with another argument to your function. And besides, you can't map over sequences in golang so the entire example collapses.
RE: scoping. as far as I know go has block scoping as well.
RE: one struct of multiple types. I think they made a mistake by allowing usage of the type keyword for both interface and concrete types because interfaces and types are completely different. I don't think interfaces have any runtime meaning. They just help the programmer and the compiler. So it's one one type, which in your example satisfies one interface.
This is what embedded structs look like in go:

type Bitmap struct{
    data [4][4]bool
}

type Renderer struct{
    Bitmap
    on uint8
    off uint8
}

I don't know about C#, but stacktraces are completely an OK way of knowing where your error comes from.

 

[Chad Nasty]

Marvin can probably speak more on async/awaits but it's one of the problems of doing async in typed languages, since the async type-ness contaminates all the other types it touches, so from type T you suddenly need to work with Async<T>, which is where fancy-pants things like monads come in.
I understand wanting to touch up your resume, although you can run C# and F# nowadays on Mono. Go isn't a bad choice in this regard, I just personally dislike it. It probably will help you by exposing you to more opportunities, so it's not bad for that, I just think most companies opting to work with it are making a mistake because it's trendy.
Waitgroups are part of what makes goroutines annoying. Instead of the goroutine itself signalling via a variable it already returned that the job is done, you need to go to another variable then wait for it. It's as bad as using goto because you're doing one thing in one point of your program and waiting for it in a whole other place. Terrible software design.
Imagine the case where every async process returns a channel, you could wait on all processed by just:

<- merge(map(op, inputs))

But golang had to reinvent goto, and you got fucked with another argument to your function. And besides, you can't map over sequences in golang so the entire example collapses.
RE: scoping. as far as I know go has block scoping as well.
RE: one struct of multiple types. I think they made a mistake by allowing usage of the type keyword for both interface and concrete types because interfaces and types are completely different. I don't think interfaces have any runtime meaning. They just help the programmer and the compiler. So it's one one type, which in your example satisfies one interface.
This is what embedded structs look like in go:

type Bitmap struct{
    data [4][4]bool
}

type Renderer struct{
    Bitmap
    on uint8
    off uint8
}

I don't know about C#, but stacktraces are completely an OK way of knowing where your error comes from.

Thanks for taking the time to write stuff out. I appreciate when people who know a lot put me in a situation that makes me ask myself "Why did I choose to use this?", so thanks. To be honest, using it as a resume builder was part of it, but the big part is that I'm in a situation where I can devote all my time to a project and learn and build without worry about the dosh, I wanted to try a different approach and learn how to develop using C-like modules instead of the OOP I was used to in C#. I'm curious, if you were able to devote time to a project whatever it is, what would it be?