12 ms·

That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they tak

• coldtea 11y ago
  >I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?
  • andrewchambers 11y ago
    Go has the best and most consistent std library I have seen.
    • coldtea 11y ago
      It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc). And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.
      • krylon 11y ago
        Well, yes. But Java's standard library is also huge and full of deprecated stuff. I have not done a lot of Java programming, but when I did play around with Java, I found myself spending most of the time actually browsing through the standard library's documentation (which is, to be fair, really, really good) looking for stuff. Also, Java has a head start of nearly 15 years on Go, and the Java community is (or used to be, at least) pretty huge. Not that this invalidates your point.
        • gravypod 11y ago
          Add an extra 30 years to that. Java's designers didn't history of computer science and language development for the of sake "simplicity". (Generics, error handling, etc.)
    • TheDong 11y ago
      Consistent standard library? It's a crapshoot what will be an interface and what will be a struct, which is one of the fundamental features of the language. Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), and sometimes panics. If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions. The math library, as mentioned above, is pretty darn iffy. The existence of both 'path' and 'filepath' is possibly a mistake. The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed. Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on). Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.
      • apenguin 11y ago
        Sorry, but I can't find what you're referencing with the "as mentioned above" on math; could you clarify? My biggest problem with the math library was, IIRC, everything only takes float64s, which makes dealing with any of the other number types more difficult than it should be (I shouldn't need to cast an int to a float and back in order to get the max of two numbers).
      • chimeracoder 11y ago
        > Returned error values are sometimes errors.New (e.g. io.EOF) and sometimes random fmt.Errorf strings that couldn't possibly be handled (e.g. all of tls.go basically), sometimes actual structs (e.g. PathError), This is the advantage of having errors be interfaces rather than concrete values. Once you learn how to use it, it's a strength. The usage of structs that satisfy the interface (as in PathError) is clearly documented and completely predictable. If your concern is that a certain package could use a struct satisfying the interface and does not, well, one advantage of errors as interfaces is that you could propose this change without breaking the backwards compatibility guarantee. It's really important to keep in mind that errors are adopted from error values in C, which means that their idioms and usage is inspired by that rather than by exception handling. Many new Go programmers (including me, when I started) were more familiar with exception handling in higher-level languages than error handling in idiomatic C, so it does take some getting used to. > and sometimes panics. Do you have any examples of the standard library using panics to signal handle-able errors (not counting cases in which the panic is recovered at the top-level in the library and never visible to the caller)? > The math library, as mentioned above, is pretty darn iffy. The only complaint I have had about package "math" is that all operations are defined on float64s, which can be annoying, but is far better than any alternative. That's an annoyance, but it's certainly not an inconsistency in the library. Do you have any other examples of inconsistencies in the math package?
    • nevergo 11y ago
      Go has the poorest std lib I've ever seen.
      • andrewchambers 11y ago
        Compared with? My reference point is python,java,clojure,c,c++. Python is huge and useful but messy and inconsistent. Java is huge and doesn't compose well. Clojure is underdocmented and hardly batteries included. C and C++ can't do anything useful without a bunch of extra libraries. From what I can see, C# is like java in this regard. Go is a small incredibly useful and composable set of libraries that handles a vast amount of cases with a small amount of code.
        • okal 11y ago
          I had the same feeling about Clojure, but it mostly has to do with non-standard libs. It's forced me to rely on reading source code a lot more than I did in other languages, so I'm not entirely sure that's a mark against it. I'm curious why you think that about Python, though. Care to illustrate?
        • nevergo 11y ago
          Just poor, don't make me laugh.
  • curun1r 11y ago
    > Can you think of some aspect that was especially well thought-out? Go routines, channels and select. With very little else, it's possible to write some very useful code in a way that's concise, elegant and easy to reason about.
    • coldtea 11y ago
      Only compared to something like C or explicit old-skool Java like threading. A lot of modern languages have CSP built-in or as a lib (Java, Scala, Haskell, Clojure, C++, Ada, Erlang, heck even Rust). And Go is not quite expressive to address higher level, but common, constructs ( https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 ) in a conceise and elegant way. And if you access anything outside of channel provided stuff in Golang, you have to bring your own safety.
      • sounds 11y ago
        It looks like from the comments on your gist, there are ways to do it. Whether it's expressive enough is subjective but it's worth pointing out that there _are_ solutions.
      • curun1r 11y ago
        You seem very focused on what you can't do with it rather than focusing on what you can do with it. I've found, in practice, that you learn to adapt to not having that level of expressiveness and start thinking through problems the Go way. And I've come around to the viewpoint that expressiveness is also a liability of a language in addition to being a feature. Sharing code in a team becomes so much easier when using Go compared to other, more expressive, languages. And I've even come around to liking it for my personal projects too after returning to code I hadn't seen in months and immediately grokking it. Maybe it's just my advancing age (for a programmer), but I find myself gravitating towards the "It's not finished when there's nothing left to add, but when there's nothing left to remove" mentality when it comes to programming languages. I find that I'm only willing to tolerate new language features when they introduce benefits that go beyond expressiveness.
  • erik14th 11y ago
    I love the workspace structure and the package versions policy. Definitely my favorite among the languages I used.
• tmaly 11y ago
  I have been using Perl for a long time, it did not get everything right when it first rolled out its object system. Through incremental improvements and backward compatibility the language has become very stable. Go is just getting to 1.5, so I expect it to have some issues at the beginning.
  • threeseed 11y ago
    That $DOLLAR fix isn't just some "issue" at the beginning as though it was a design mistake or architectural oversight. It is flat out sloppy work. If you are creating a programming language that wants to maintain backwards compatibility surely every check in you make would be as close to perfect. No ?
  • danesparza 11y ago
    Agreed: Languages can evolve. Perl has been around since 1987. I would expect Go (first released in 2009) to have learned valuable lessons from earlier failures. This particular set of features doesn't appear to be very thoughtful.