4 ms·

Huh what? Care to elaborate?

by eliben 12y ago

valarauca1 12y ago
I'll take a swing. These aren't 'destroy computer science' worthy, but they are a MASSIVE step back in the development of languages. :.:.: Go lacks a lot of basic functionality a lot of other languages take for granted. I.E.: In Rust you can type fn id<T> ( item:T) -> T { return item; } And you assign the type to the function. This is possible in Go by double casting the type. Which is really messy, and what java did in 2004 for generic functions (and was ultimately useless). :.:.: Lets say you want to iterate over a array in say java. for(byte a: bytes[] { x += a; } This also doesn't exist in Go. Yet does in python, java, and several others thanks to iterators. :.:.: Lets say I'm adding vectors and dark magic has told me to use '-' for the dot product. In most languages (Rust, C, C++, Haskell) this is completely possible, as - is just a function. __subtract__() in rust. You can't in Go. :.:.: Now lets talk about pointers. When you want to signify data doesn't exist in Go you pass a null pointer (nil, 0x0). This is wrong on almost every single level. Your not only creating a back door, but your by passing your entire type system. The only thing that stops this from being common practice is that Go has such good message handling, but it still exists! Why?! :.:.: Immutable variables, data structures, etc. are a thing of beauty. In Rust and Haskell all values are immutable by default, but most languages (C, C++, Java) let you delcare variables, data structures, etc. as immutable.... Go doesn't. :.:.: Go has no support for turning off compiler safety features. Much like Rust offers the unsafe{ ... } tag for isolating code that may do strange things, go doesn't. :.:.: TL;DR Go doesn't do anything new. Actually it takes a step back.
- NateDad 12y ago
  Not sure why you think you can't iterate over an array in go: for _, a := bytes { x += a } No there's no generics. I rarely need generics. Usually I need a specific, and waste time making a genetic. No there's no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Yes, that makes go bad for Matt and science code. That's ok, go is not for every application. Go has unsafe and reflection, it is just discouraged strongly. Yes, nil exists. Big deal. You know how often I've seen nil pine exceptions in a year of writing go full time? Once. Because go has multiple returns and you never look at the pointer before checking the error. No there's no immutable data structures.... And I've never missed them. You can approximate them with interfaces with only getter methods, but it's rarely worth the effort.
  - valarauca1 12y ago
    >Usually I need a specific, and waste time making a genetic Often times in large code bases you'll have short mathematical expressions used in multiple places. fn error<T:num>(real:<T>, test:<T>)-> <T> { return ((real-test)/real)*100; } Now instead of typing the same thing over and over and over again I call a function (literally what they're designed for), and it works for floats, doubles, AND ints. >no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Overloading is normally done a per-data type basis to avoid exactly what you state. But yes, it is a big mathematical/scientific point. It can really simplify your life working with some data structures. >Yes, nil exists. Big deal. No that's the problem. Its existence is a bug. And has no use existing, as you said yourself its rare, you never see it, you hardly use it... So why even include it?! >[...] immutable Immutability is more of a programmer hack, not a language hack. Rust and Haskell make me ask myself 'will I actually change this value' when declaring a new variable. And addes an extra mental step and self check of your own code when programming.
    - Laremere 12y ago
      Re nil: He said he rarely sees code fail because of nil dereferences, not that he rarely sees it. "if err != nil {" is probably the most commonly written line of Go code by a large margin. Nil fits well with the language's zero defaultness of values. It may not be theoretically sound, but in practice it fits within Go very well and rarely causes the problems it tends to in other languages with null.
      - NateDad 12y ago
        Yep. A zero value is very handy. Not having it would make a lot of code needlessly complex just to avoid the boogeyman of nil/null.
        codygman 12y ago
        Null boogeyman? It's inventor doesn't seem to think so: http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...
- pcwalton 12y ago
  Just to nitpick, it's not `__subtract__` in Rust, it's `Sub::sub`.
- Laremere 12y ago
  I don't think your criticisms of Go are all wrong, but I do think they miss the point of Go. Go is designed to be a "best hits" sort of language. It doesn't try to do anything fancy or new (though several of its features are taken from lesser known languages) it simply tries to do what currently popular languages do, but much better. It will fail many CS theory benchmarks, but it does so in the aim of being productive now. To say Go doesn't do anything new is wrong however. The language specification doesn't include new material, sure, but the language tools are incredibly engineered. Go get just works (but don't use it for long term dependency management, that's not what it's designed for.) The documentation is stellar, and it's really easy to make good documentation. The compile times are lightning fast. Go fmt is by far my favorite feature; All Go code looks the same, and it even saves time trying to format code to look nice. As for your specific complains: :.:.: No, Go doesn't have generics, but for most cases that's ok. The saying goes when you have a hammer, everything looks like a nail. However Go does give you a screwdriver (interfaces), and it turns out a lot of things work well as screws. Generics aren't easy, they complicate the language (which goes against one of their language goals), and increase compile time or run time (which go against other goals.) They haven't said generics will never be in the language, just that they haven't found a solution they like and that it won't be in the language any time soon. :.:.: You can iterate in Go. Otherwise for loops are a tried and true method. :.:.: This complicates some code, but makes the language a lot simpler. Yes it's a trade off, and the language author's choices may differ from your preferences. :.:.: Yuck, nil pointers, I agree. However sometimes an ugly feature makes the whole language look a lot better. Nil usage aligns very well with the design of the rest of the language. Gross? Yes. The wrong design decision for Go? Definitely not. :.:.: Immutable values complicate the type system and require that those features occupy some brain power. They may be nice in other languages, they have no place in Go. :.:.: Go has unsafe operations.

Huh what? Care to elaborate?

by eliben 12y ago

Huh what? Care to elaborate?

I'll take a swing. These aren't 'destroy computer science' worthy, but they are a MASSIVE step back in the development of languages. :.:.: Go lacks a lot of basic functionality a lot of other languages take for granted. I.E.: In Rust you can type fn id<T> ( item:T) -> T { return item; } And you assign the type to the function. This is possible in Go by double casting the type. Which is really messy, and what java did in 2004 for generic functions (and was ultimately useless). :.:.: Lets say you want to iterate over a array in say java. for(byte a: bytes[] { x += a; } This also doesn't exist in Go. Yet does in python, java, and several others thanks to iterators. :.:.: Lets say I'm adding vectors and dark magic has told me to use '-' for the dot product. In most languages (Rust, C, C++, Haskell) this is completely possible, as - is just a function. __subtract__() in rust. You can't in Go. :.:.: Now lets talk about pointers. When you want to signify data doesn't exist in Go you pass a null pointer (nil, 0x0). This is wrong on almost every single level. Your not only creating a back door, but your by passing your entire type system. The only thing that stops this from being common practice is that Go has such good message handling, but it still exists! Why?! :.:.: Immutable variables, data structures, etc. are a thing of beauty. In Rust and Haskell all values are immutable by default, but most languages (C, C++, Java) let you delcare variables, data structures, etc. as immutable.... Go doesn't. :.:.: Go has no support for turning off compiler safety features. Much like Rust offers the unsafe{ ... } tag for isolating code that may do strange things, go doesn't. :.:.: TL;DR Go doesn't do anything new. Actually it takes a step back.

NateDad 12y ago
Not sure why you think you can't iterate over an array in go: for _, a := bytes { x += a } No there's no generics. I rarely need generics. Usually I need a specific, and waste time making a genetic. No there's no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Yes, that makes go bad for Matt and science code. That's ok, go is not for every application. Go has unsafe and reflection, it is just discouraged strongly. Yes, nil exists. Big deal. You know how often I've seen nil pine exceptions in a year of writing go full time? Once. Because go has multiple returns and you never look at the pointer before checking the error. No there's no immutable data structures.... And I've never missed them. You can approximate them with interfaces with only getter methods, but it's rarely worth the effort.
- valarauca1 12y ago
  >Usually I need a specific, and waste time making a genetic Often times in large code bases you'll have short mathematical expressions used in multiple places. fn error<T:num>(real:<T>, test:<T>)-> <T> { return ((real-test)/real)*100; } Now instead of typing the same thing over and over and over again I call a function (literally what they're designed for), and it works for floats, doubles, AND ints. >no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Overloading is normally done a per-data type basis to avoid exactly what you state. But yes, it is a big mathematical/scientific point. It can really simplify your life working with some data structures. >Yes, nil exists. Big deal. No that's the problem. Its existence is a bug. And has no use existing, as you said yourself its rare, you never see it, you hardly use it... So why even include it?! >[...] immutable Immutability is more of a programmer hack, not a language hack. Rust and Haskell make me ask myself 'will I actually change this value' when declaring a new variable. And addes an extra mental step and self check of your own code when programming.
  - Laremere 12y ago
    Re nil: He said he rarely sees code fail because of nil dereferences, not that he rarely sees it. "if err != nil {" is probably the most commonly written line of Go code by a large margin. Nil fits well with the language's zero defaultness of values. It may not be theoretically sound, but in practice it fits within Go very well and rarely causes the problems it tends to in other languages with null.
    - NateDad 12y ago
      Yep. A zero value is very handy. Not having it would make a lot of code needlessly complex just to avoid the boogeyman of nil/null.
      - codygman 12y ago
        Null boogeyman? It's inventor doesn't seem to think so: http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...
pcwalton 12y ago
Just to nitpick, it's not `__subtract__` in Rust, it's `Sub::sub`.
Laremere 12y ago
I don't think your criticisms of Go are all wrong, but I do think they miss the point of Go. Go is designed to be a "best hits" sort of language. It doesn't try to do anything fancy or new (though several of its features are taken from lesser known languages) it simply tries to do what currently popular languages do, but much better. It will fail many CS theory benchmarks, but it does so in the aim of being productive now. To say Go doesn't do anything new is wrong however. The language specification doesn't include new material, sure, but the language tools are incredibly engineered. Go get just works (but don't use it for long term dependency management, that's not what it's designed for.) The documentation is stellar, and it's really easy to make good documentation. The compile times are lightning fast. Go fmt is by far my favorite feature; All Go code looks the same, and it even saves time trying to format code to look nice. As for your specific complains: :.:.: No, Go doesn't have generics, but for most cases that's ok. The saying goes when you have a hammer, everything looks like a nail. However Go does give you a screwdriver (interfaces), and it turns out a lot of things work well as screws. Generics aren't easy, they complicate the language (which goes against one of their language goals), and increase compile time or run time (which go against other goals.) They haven't said generics will never be in the language, just that they haven't found a solution they like and that it won't be in the language any time soon. :.:.: You can iterate in Go. Otherwise for loops are a tried and true method. :.:.: This complicates some code, but makes the language a lot simpler. Yes it's a trade off, and the language author's choices may differ from your preferences. :.:.: Yuck, nil pointers, I agree. However sometimes an ugly feature makes the whole language look a lot better. Nil usage aligns very well with the design of the rest of the language. Gross? Yes. The wrong design decision for Go? Definitely not. :.:.: Immutable values complicate the type system and require that those features occupy some brain power. They may be nice in other languages, they have no place in Go. :.:.: Go has unsafe operations.