re: Go Outta Here VIEW POST

FULL DISCUSSION
 

Most of these complaints you have can be summed up with "im not used to it so its bad"

OK, everybody calls it module, we’d call it package, because we are special. OK.

Ever heard of Java? Or Kotlin?

import "fmt"? You gotta be kidding me; it is completely redundant in a compiled language.

Again, bikeshedding at its best. Whatever IDE you use will automatically resolve them anyway and sometimes you do need to disambiguate between packageA.foo and packageB.foo, no magic complier can do that for you.

The above makes me cry. In the second decade of XXI century we enforce the developer to distinguish between int32 and int64 in compiled “statically typed” language. Really?

It would be a pretty advanced compiler that can magically know how big the integer you need. In dynamic languages it depends, they handle it in different ways. Either way in Go it makes you pick so that you have a choice in respect to performance.

What could go wrong with a plain old good equal sign? We’d lose the pride for Go being statically typed if it would not remind us about that by redundant syntax quirks?

x := "foo" creates and assigns a variable

x = "bar" reassigns the value of x. If x doesn't exist it doesn't compile. Which is a good thing as you probably made a mistake.

There is a clear reason for this distinction, if you looked past your own biases just a bit.

Re maps, your example is disingeneous, which is a real surprise. You can access (and create) maps as you'd "expect", but your example is safer (so more verbose)

package main

import (
    "fmt"
)

func main() {
    ages := map[string]int{
        "Chris": 34,
        "Dave":  38,
    }

    fmt.Println(ages["Chris"])
}

The above works just fine. Also note how I didn't have to bother setting the size of the 'int', contrary to your claims.

Functions can return multiple values (what’s wrong with returning arrays btw?)

Because arrays can only be of one type. So you couldnt return an int and a string for instance.

But please stop call Go safe, easy to read-and-write and statically typed. Thank you.

Your rant is horribly short-sighted and whiny and clearly shows a lack of actual study into the language. I'll carry on calling it the above.

Before you launch some kind of character attack on me being not a real programmer, i've spent half a decade writing in Scala so I know all about wizzpop functional programming thanks.

Anyway its Christmas day so back to the gin! Merry Christmas

 

Ever heard of Java? Or Kotlin?

Ever heard of what is the difference between a collection of classes and a collection of functions?

Whatever IDE you use will automatically resolve them anyway and sometimes you do need to disambiguate between packageA.foo and packageB.foo, no magic complier can do that for you.

I do not use any IDE and you seem to just do not understand the statement. packageA.foo does not require import "packageA" to be resolved.

x := "foo" creates and assigns a variable
x = "bar" reassigns the value of x. If x doesn't exist it doesn't compile. Which is a good thing as you probably made a mistake.

Eh? If x = "bar" is called when x does not exist, it should create and assign, otherwise it should reassign. That simple.

your example is disingeneous

It’s not mine, I took it from the official guide.

Because arrays can only be of one type.

OK, that one I missed. Indeed, returning several unrelated values is fine, but wrapping them into the array is not. OK.

Before you launch some kind of character attack on me [...]

This bullshit I wouldn’t even comment. I never launched any kind of character attack on anybody, although I constantly receive ad hominem arguments back here.

 

Because arrays can only be of one type. So you couldn’t return an int and a string for instance.

type ReturnValue [2]interface{}

 

You keep bringing up interface as if it's some kind of amazing criticism of Go but as others have said

It's discouraged to be used. Only use it if the type system isn't expressive enough for what you're doing.

Every statically typed language I know of has an equivalent of it. For instance Scala has Any

What interface does is lose type safety and makes the function less clear as to what you should pass in. It loses the benefit of static typing. Which in other comments you seem to say isn't great anyway? If you don't like type safety and enjoy all functions taking any type like this, stick with your dynamic languages

The above is the answer to the wrong statement “you couldn’t return an int and a string for instance.” I am pretty sure it’s exactly what return foo, bar, baz does under the hood. That said, I was correct saying arrays are a perfect fit instead of redundant multiple returns.

stick with your dynamic languages

I do not need advises on what am I to stick to. I am just pointing out to the design flaws of an extremely overvalued inconsistent language.

code of conduct - report abuse