4 ms·

The comparison is completely fair; I don't think he's making the general statement that Go is faster than Java. He can legitimately make the claim that the over

The comparison is completely fair; I don't think he's making the general statement that Go is faster than Java. He can legitimately make the claim that the overhead of a slice of ints is far smaller than an array of ints in Java. You can add methods to an int in Go without any overhead by simply defining your own type that is backed by an int and then adding functions to that type. It still costs same. Java performance for real-world, long-running, well written applications is greatly enhanced by an excellent JIT that improved performance over time. Go can be faster for looping over a list of integers while Java can win at branch prediction in complex code paths.

seanmcdirmid 12y ago
> He can legitimately make the claim that the overhead of a slice of ints is far smaller than an array of ints in Java. No he can't. He was comparing a generic list in java of ints with a non-generic list of ints in Go, when in reality, you could reverse the comparison between languages and make the same conclusion.
- stcredzero 12y ago
  You don't need <generic-equivalent-boxing> in Go to get the power of slices, and use library search/sort. Are you saying there's an equivalently powerful set of facilities in Java that doesn't use generics?
  - seanmcdirmid 12y ago
    Yes, they are called...slices. There is no library implementation in Java, but it is completely implementable (I did the whole thing for Scala way back). Say: class Slice { int[] Original; int Begin; int End; int Get(int index) { if (index > End - Begin) throw new ... return Original[Begin + index]; } } Perhaps Go slices are native and they can eliminate one extra bounds check? Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. It is ugly without generics though, and...beyond defining slices, Go has most of the same usability problems as Java (all operations on slices have to be duplicated!). C#-style generics fix these problem, of course...meaning you can have your slice of cake and eat it also.
    - stcredzero 12y ago
      Yes, they are called...slices. There is no library implementation in Java, but it is completely implementable... Perhaps Go slices are native and they can eliminate one extra bounds check? Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. You definitely lost the conversation context, or this is some kind of debating maneuver? The point is that the memory overhead for the degree of functionality offered by slices in Go is quite small by design. Yes, you can implement it in Java, but various kinds of overhead (not just memory, btw) in Go are small by design. Then comparative implementation details are discussed to provide context for programmers who may not concentrate on language implementation. You're also kind of barking up the wrong tree. Go is not really meant to replace Java. It's really meant to "replace" C, or more accurately bridge a gap a bit higher-level than C and lower level than "High Level Languages," particularly where concurrency is of key importance. In the contexts where it seems to try and replace Java or C++, it's really that a locus of language implementation tradeoffs wasn't immediately identified and languages with slightly too many features were used to fill the gap. C#-style generics fix these problem, of course...meaning you can have your slice of cake and eat it also. No one is arguing that C# style generics don't fix this, or that certain things are less pretty without them, or that other languages can or don't do certain things more elegantly. In particular, yes, I know C# is very underrated. Camp Smalltalk attendees knew about the cool things about the Common Language Runtime about a year and a half before the public. (One camper declared that it basically meant "Smalltalk had won.") We hear you and believe you and you are right. Validated? Now please stop repeating yourself. That's simply not the key "point" which was made by the post and is not being understood in these threads. That point is not being made nor even being addressed by you. Take it from an old Smalltalker: doing cool stuff yields 100X more benefit than comparing languages and tooting your own horn. Goes even more for objecting to others tooting theirs. EDIT: When I say "no one would say that," I really mean, "no one reasonable would say that." As you and I well know, this precludes many programmers while they are in a holy language-war discussion.

seanmcdirmid 12y ago

> He can legitimately make the claim that the overhead of a slice of ints is far smaller than an array of ints in Java. No he can't. He was comparing a generic list in java of ints with a non-generic list of ints in Go, when in reality, you could reverse the comparison between languages and make the same conclusion.

stcredzero 12y ago
You don't need <generic-equivalent-boxing> in Go to get the power of slices, and use library search/sort. Are you saying there's an equivalently powerful set of facilities in Java that doesn't use generics?
- seanmcdirmid 12y ago
  Yes, they are called...slices. There is no library implementation in Java, but it is completely implementable (I did the whole thing for Scala way back). Say: class Slice { int[] Original; int Begin; int End; int Get(int index) { if (index > End - Begin) throw new ... return Original[Begin + index]; } } Perhaps Go slices are native and they can eliminate one extra bounds check? Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. It is ugly without generics though, and...beyond defining slices, Go has most of the same usability problems as Java (all operations on slices have to be duplicated!). C#-style generics fix these problem, of course...meaning you can have your slice of cake and eat it also.
  - stcredzero 12y ago
    Yes, they are called...slices. There is no library implementation in Java, but it is completely implementable... Perhaps Go slices are native and they can eliminate one extra bounds check? Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. Or that you don't have to implement a custom slice class for N primitive/value types (though Java doesn't support value types yet)? Since the code is easily templated, you could just use SugarJ or some other macro system for Java. You definitely lost the conversation context, or this is some kind of debating maneuver? The point is that the memory overhead for the degree of functionality offered by slices in Go is quite small by design. Yes, you can implement it in Java, but various kinds of overhead (not just memory, btw) in Go are small by design. Then comparative implementation details are discussed to provide context for programmers who may not concentrate on language implementation. You're also kind of barking up the wrong tree. Go is not really meant to replace Java. It's really meant to "replace" C, or more accurately bridge a gap a bit higher-level than C and lower level than "High Level Languages," particularly where concurrency is of key importance. In the contexts where it seems to try and replace Java or C++, it's really that a locus of language implementation tradeoffs wasn't immediately identified and languages with slightly too many features were used to fill the gap. C#-style generics fix these problem, of course...meaning you can have your slice of cake and eat it also. No one is arguing that C# style generics don't fix this, or that certain things are less pretty without them, or that other languages can or don't do certain things more elegantly. In particular, yes, I know C# is very underrated. Camp Smalltalk attendees knew about the cool things about the Common Language Runtime about a year and a half before the public. (One camper declared that it basically meant "Smalltalk had won.") We hear you and believe you and you are right. Validated? Now please stop repeating yourself. That's simply not the key "point" which was made by the post and is not being understood in these threads. That point is not being made nor even being addressed by you. Take it from an old Smalltalker: doing cool stuff yields 100X more benefit than comparing languages and tooting your own horn. Goes even more for objecting to others tooting theirs. EDIT: When I say "no one would say that," I really mean, "no one reasonable would say that." As you and I well know, this precludes many programmers while they are in a holy language-war discussion.