18 votes

Topic deleted by author

4 comments

  1. Akir
    (edited )
    Link
    This article is basically a long investigation into the extremely general reason why I never bothered to invest in learning Go. Go has always felt to me like it's another rehash of C. And I know...

    This article is basically a long investigation into the extremely general reason why I never bothered to invest in learning Go. Go has always felt to me like it's another rehash of C. And I know that there are a lot of people who appreciate that - there are many C/C++ programmers out there, and to them Go must be a breath of fresh air. But I personally thought that "The C way" is not always the best.

    I know not everyone will agree with me, but with an extremely broad perspective, it doesn't really matter much what programming language you are using for most projects. Most newer languages have extremely simelar Pascal-C-Java-Python-JS-like syntaxes. What matters instead is the patterns and systems that the languages encourage you to think in. And I think that's one of the reasons why Python has had such a long period of success and wide adoption; you can write Python just about any way you want to - It's pretty trivial for C coders to move on to write C-like Python, but the excellent Python community is always there to tell you to write Pythonic code, which is going to be more maintainable and less error-prone.

    For a slightly better example of what I'm trying to say, we should probably look at Rust. The main advantage of Rust versus other programming languages is that it enforces certain patterns. The obvious example is how it avoids active garbage collection by how it forces you to handle your memory every time you deal with variables. Even better is how it normalizes the Result type for processes which may fail; Every time you use a function that returns a Result, you instantly know that this is where problems may come up. Both of these are patterns you can port to other languages, but Rust makes them firm decisions that are exceedingly difficult to stray from. Sure there are other niceties to the language, but this is the core benefit to the language on a conceptual level. A programmer who starts off writing C will have to learn the decades of collected experience of programmers who came before them, while a programmer who starts with Rust has this all baked into their initial learning experience and intuitively understands a greater subset of programming best practices.

    (Edited for annoying grammar mistake)

    15 votes
  2. [2]
    skybrian
    Link
    I didn't find this article particularly compelling. In particular I thought the Go decision to make strings 8-bit clean and UTF-8 only by (strong) convention to be an interesting and...

    I didn't find this article particularly compelling. In particular I thought the Go decision to make strings 8-bit clean and UTF-8 only by (strong) convention to be an interesting and underappreciated design choice, since it matches what files contain and what networks transmit.

    It would be easy to define an alternate string type that means "this string has been checked for UTF-8 validity" but in practice nobody does because, in those cases where validity matters, you are probably also doing some other parsing, too, and the output isn't just a string.

    The kind of critique I would find compelling would be one that shows that the author understands deeply why Go is designed the way it is, while also showing why an alternative is better.

    6 votes
    1. [2]
      Comment deleted by author
      Link Parent
      1. skybrian
        Link Parent
        It's not obvious this is about right or wrong, but rather a difference in philosophy. Unix allows non-Unicode in paths and Go's standard library has useful functions for handling them. But if you...

        It's not obvious this is about right or wrong, but rather a difference in philosophy.

        Unix allows non-Unicode in paths and Go's standard library has useful functions for handling them. But if you aren't aware of the issue, you can easily write a program that doesn't take this into account, and then you may have a bug if that case ever comes up.

        Some people want API's that comprehensively model all corner cases and make you handle them, even if you didn't read the documentation or don't care if your code handles those corner cases.

        This is sort of like the debate between static and dynamic types, but a bit finer grained.

        3 votes
  3. Liru
    Link
    My most popular project on Github is currently a program I slapped together in Go a long time ago. The sync/atomic issue mentioned at the end of the article is THE issue that made me stop...

    My most popular project on Github is currently a program I slapped together in Go a long time ago. The sync/atomic issue mentioned at the end of the article is THE issue that made me stop considering Go for anything other than trivial things. Lack of decent error handling, a terrible builtin json library, constant interface{} to poorly substitute for generics, the package management issues that made Node.js look well-thought-out by comparison, struct field tags, and generators provided by the core team that set off linters provided by the core team with no good way to silence them kind of piled on before that, but the atomic issue is the one that made me avoid it. The author is right, all the little things add up.

    Note that a bunch of these may have been fixed since I last used it, but honestly, I haven't checked because it was frustrating working in it and debugging it. It's a shame, pprof and the race detector are pretty cool.

    4 votes