Why Go? Use Racket

I feel like the author hasn't used go much. You almost never work with arrays directly, you use slices, which CAN be efficiently passed around.

EDIT: Upon re-reading I think the author was making a point about the consistency of go, and how different types have different behavior with regards to pass-by-reference/copy. There's actually a pretty simple rule for it:

If the variable is a primitive, or defined by the user, it is passed by copy (ints, strings, structs, etc...). Everything else (compositional types like slices and maps, and others like channels) are passed by reference.

The outlier are raw arrays, but again you don't ever actually use those, so you can just ignore them.

For someone coming from a Scala background, I feel this statement is absurd.

One thing we are all forgetting here is that anyone can prove language X is better than Y. But it's always wise to choose the best tool for the job (X is better than Z in doing what exactly?).

Languages and frameworks are a personal preference. You choose them based on their philosophises and if their philosophies resonate with yours.

After a certain point, language choices will no longer matter. Your end goal, should be to get to this point, instead of fighting over them. Just my 2 cents.

And unlike most other languages, it's out of box support for Windows is perfect.

Go's type system is not complex at all. What is complex about it? There is a limited set of types, and they can have methods. You can define your own types. What's so complex about that?

> programmers need to know all the details about the implementation of standard types, before they can use them correctly.

You should not have problem with knowing the details of the language or the third party libraries you are using if you want to be a proficient engineer builds stable, secure and easily-maintainable systems.

Each thread reads from the channel to its left and writes the processed input into the channel to its right.

Except that the programs he posted are flowing the other way(start with rightmost, read final value from leftmost). The implementation of the author's wording needs a slight change.

Go implementation:

    package main

    import "fmt"

    func setup_channels(left chan int, num int) chan int {
        for i := 0; i < num; i++ {
            right := make(chan int)
            go func(left, right chan int) { right <- 1 + <-left }(left, right)
            left = right
        }
        return left
    }

    func main() {
        leftmost := make(chan int)
        rightmost := setup_channels(leftmost, 100000)
        leftmost <- 1
        fmt.Println(<-rightmost)
    }

    #lang racket

    (define (setup-channels left idx num)
    (if (>= idx num)
        left
        (let [(right (make-channel))]
        (thread (λ ()
                    (channel-put right (+ 1 (channel-get left)))))
        (setup-channels right (add1 idx) num))))

    (let* [(leftmost (make-channel))
        (rightmost (setup-channels leftmost 0 100000))]
    (channel-put leftmost 1)
    (channel-get rightmost))

I feel like a non-linux user categorizing Debian, Ubuntu, Mint, Red Hat, and so on altogether as 'Linux'; While he's not incorrect, there are subtle difference that he's not seeing. It feels rather frustrating. I'm using Racket(when I want to experiment in functional language) because that's what I'm used to, but it would be great to hear X and Y are different in ... than X is better than Y because...

And Racket's type system (being an expandable, routinely expanded language) is much, much larger.

Is the same true for Racket threads? Or are they closer to "lightweight" green threads in other languages. I'm genuinely curious. If they are really as lightweight as goroutines, that should be publicized more heavily. If they're not, then it's disingenuous to claim that Racket's CSP story is equivalent to Go's.

I don't quite follow this "problem" - it sounds like a complaint about the lack of generics. I haven't been programming in Go for long, but I found the reflection system pretty easy to use and it basically allows you to do this.

Sure, it's not EXACTLY the same, but in what case do I actually need a float or integer instead of an interface method that acts on them in the way I expect?

Is there a great reason to use racket instead of go?

Racket has a richer set of concurrency/parallelism structures (threads, futures, places, engines) than Go provides (goroutines). This is both a source of power, and a source of cognitive overhead.

Probably only Oberon-7 strives to be simpler, from the current set of modern languages.