4 ms·

> If you're such a poor programmer, No need for personal attacks. > then just find a different language. What a warm an welcoming community the Go community

• swift 10y ago
  Gotta tell ya, criticizing Go for lacking generics, which Go supporters argue are unnecessary, while simultaneously arguing that C++ doesn't have reflection because it "doesn't need it" is ironic in the extreme.
  • deleted 10y ago
    [deleted]
  • _ph_ 10y ago
    Very few Go supporters would say that generics are unnecessary, especially not the development team. But they are not required at any price and so far no good solution for implementing them has been found. So they are delayed until that day. While I miss them certainly, I strongly prefer them being absent to a bad and complex/confusing implementation.
    • candiodari 10y ago
      But the problems go further. The go type system is littered with exceptions. Why ? Because append, make, maps, channels in for loops, channels in while loops, ... all have their own specific entries in the type system. Go has generics ... but only for the core team. Go has polymorphism (there are polymorphic functions, all of which BEHAVE differently in the type system), there are return type polymorphic functions (functions that behave differently depending on whether you assign their result to one or two variables). One look at github will tell you exactly what the go way of handling errors does in practice : ignoring errors. Golang code is like C code: it makes it sooo easy to just ignore errors. Second thing: errors are so hard to localize, as they're not tagged with location or stack trace. So I often find myself looking for string errors, while in Java/C# in 99% of cases I know exactly where shit happened. In Go I know in 20% of cases or so. Speed. Go manages to be slower than Java, except in startup. For a compiled language, that's an accomplishment. Besides the reactions to Go seem rather typical: it's simple and very, very limiting. Operations people are beside themselves. Predictable (although the ignoring of errors, channels and difficult to localize errors plus a number of mistakes in the standard library detract from that more than a little bit). Programmers don't like it.
      • _ph_ 10y ago
        As I said, generics are missing, and the core team is working at them. But I really appreciate that they do not implement something like the Java generics. If your code produces errors, you can of course add location information like stack traces, there is an API for that. I have not benchmarked Go against Java explicitly, but I do benchmark against C and it compares very nicely in performance to C code, so for most tasks it should be as fast or faster than Java code. Go gives you more flexibility about memory layout (true value types), which keeps GC times down. I am a programmer, with 20 years of Java on my belt and I quite love Go.
        • candiodari 10y ago
          > I have not benchmarked Go against Java explicitly, but I do benchmark against C and it compares very nicely in performance to C code, On average, Go code is about 50% as fast as C code in calculations and algorithms, usually, and has more lines of code for equivalent functionality without cheating. Do your benchmarks tell you something different ? Java is about 10% slower than C. 30% or so if you "don't cheat" (meaning write a direct translation of C code into java, e.g. using char[] instead of string) There's also that C encourages you to write faster code, at least it does for me. Java, Go, and every other language I know, encourage me to do string mangling by making lots of temporary strings. C doesn't really allow for that, instead making me think about doing in-place string editing, which is far, far faster than using copies. Of course, get the tiniest little detail wrong and it'll blow up, but there's no beating it in speed.
          • _ph_ 10y ago
            Yes, in my daily experience, Go is roughly on par with C code. There are a few constructs that the Go compiler does not optimize yet (jump tables), but other than that they are pretty close.
      • ithkuil 10y ago
        I found the https://github.com/juju/errors https://github.com/juju/errors library to be a very practical way to include tracing info in the error values. I wish the core error library behaved like that, and that the core language made it less verbose. This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community. Other languages changed a lot over the years, getting better but frustrating people because of breaking changes. I believe this promise of stability paved the way for much of Go's success, despite many shortcomings
• mappu 10y ago
  >C++ doesn't have reflection How would you describe RTTI?
  • Someone 10y ago
    Type information isn't reflection. In C++, given a pointer, you can only discover that it points to a Foo if you know that Foos exist. If you don't, you'll never be able to find the name of the type, whether it has a member named "Bar", what the type of that member is, whether it can be set, whether Foo has a method named "Baz", what its argument types are, etc. Even if you do know Foo is a type, the programmer has to do most of that stuff. For example, one cannot write a function that prints all fields of an object passed to it without specifying its concrete type. Add a field, and you have to adjust that function. The only thing you can reliably do is determine whether Foo implements a given interface (= abstract base class) but again, that's only if you know that interface exists. You cannot determine the name of a superclass or the depth of an object's class hierarchy, for instance.
  • aikah 10y ago
    Can you create adhoc types from nothing with RTTI ? because in Go you can, at runtime. Is it what a statically typed language which community claims generics are unnecessary should prioritize as a feature ? runtime magics ? really ?
    • stcredzero 10y ago
      So your argument goes no deeper than, "(Say stuff that might sound bad on the surface) Really?" Can you be more substantive than appeals to prejudice? (For a change)
      • vapourismo 10y ago
        What is your argument?
• stcredzero 10y ago
  What a warm an welcoming community the Go community is /s I have to say, I've had the "warm an welcoming /s" from the Go community myself. I'll give you a hint: You can also get the same from Smalltalk if you complain that a method can't have more than 256 temporary variables, and that this means Smalltalk isn't a real language. (How that demonstrates cluelessness is left as an exercise.) Annoying Dunning-Kruger crap that would only be clever and well informed if posted as a deliberate troll -- I leave that to you for what sort of welcome one should expect. I'll also note that you are "copping out" by responding to exactly zero of my arguments and deflecting attention instead. Probably because you can't. Reflection is a cop-out, especially in a language that has a simplistic type system. Says who? This could just as well apply to Smalltalk. If you're pedantic about it, you could even say Smalltalk-80 is a strongly typed compiled language. Reflection is just another tool that has trade-offs and potential problems like any number of programming language tools. And if you said it was a language design "smell" you'd be right. But to a dedicated practitioner, no programming language is free of those.
  • vapourismo 10y ago
    So, Go with a more expressive type system is a worse Go?