5 ms·

The go section is great, it's such a derpy 1980s language: "Go's error type is simply an interface to a function returning a string. Go lacks pattern matching

• jchw 7y ago
  This is literally a list of reasons why Go is wildly successful. Go is a language that does exactly what it needs to and no more. If you want more, there are plenty of languages that have more syntax than users.
  • kev009 7y ago
    And bless go for pulling all those users in!
• dnautics 7y ago
  The defer interaction with named return values is going to give me nightmares. We have a senior dev whose software caused a memory leak in prod. One of our less senior devs (who has an engineering PhD in concurrent systems theory) immediately identified that the senior was trying to do clever optimizations for single threadedness that simply cannot work when concurrent... I wouldn't be surprised if his code is causing a goroutine leak. I am convinced that go is popular because it's comfortable to elder seniors and makes them think they can use their aging python/c/c++ skills in something flashy, new, concurrent, "supported by Google" and... Well at least it's genuinely safer. Disclaimer: I'm an aging dev myself.
  • jchw 7y ago
    I started writing Go at age 23, for what its worth. (That was a just a few years ago.) I like Go because its simple. Obviously, that is also its downfall. Overall, I would still hold it as one of the best languages for writing various kinds of software (servers, CLI tools, and some odds and ends.) It’s true that you can write bad Go by trying to do things that are not a good idea, but I’m not sure what you’d expect. The Go ecosystem is damning evidence of the ease of writing pretty good code in the language. Disclaimer: I work for Google (but I do not work on Go and I did not work for Google when I first began writing Go.)
    • dnautics 7y ago
      No doubt. I strongly believe go is a major advancement over c/c++ for routine work and an improvement over python. There are, however major footguns, I find it hard to read other people's, or even my own code (parsing nested if conditionals is no fun when you're debugging under duress), and CSP is really just.... Not the best concurrency paradigm.
      • otabdeveloper4 7y ago
        There's no such thing as "C/C++".
        • dnautics 7y ago
          Sorry c/c++ family. Explicit is better than implicit. Pardon me. C was my second real language after Pascal and c++ came immediately after that in a 6 month timespan, so for my underperforming and scelerotic brain (aside from an ld_preload shim I wrote two years ago haven't touched them since the aughts) they are "together" in my brain. Curly braces and all that.
      • solarkraft 7y ago
        I fully disagree. I find Go very nice to read.
  • kev009 7y ago
    I actually think go is being propped up by young people with mediocre experience/jobs that work on glue/ops tooling and thinking they are leet. Go is such a primitive language it feels like systems programming (C) without actually being useful for systems programming and is wildly outclassed for applications programming. The perfect self selector for Google's SRE army.
  • Timucin 7y ago
    One of the idioms of Golang is not being clever but being verbose and clear. Looks like your senior dev has completely missed that.
    • dnautics 7y ago
      By clever I mean clever reuse of system resources, e.g. This is not anything being more verbose would have helped.... Race conditions and deadlocks were introduced.
  • pcstl 7y ago
    I think that's plausible, even though Google's intentions with it were the opposite: I've had the opportunity to talk with a few people who were involved in Go's design and they explicitly said the idea was to get fresh-out-of-school programmers to be productive on web systems immediately.
  • xkcd-sucks 7y ago
    One nice thing about Go is it produces cross platform binaries without external dependencies, and the standard library supports Windows api stuff like system services and registry. Mono/C# is better, but the learning curve is pretty steep compared to Go with all the missing reference assemblies, diverse runtime versions, etc. Gopath sucks and sucks to configure but it's less complicated than .net. So you can ask a junior web dev to learn a new language in a week and write a native windows application, and they might actually deliver. Whether this is empowering or signals the death of Quality remains a hotly contested issue.
• dimgl 7y ago
  This page is actually really funny and talks about a lot of the quirks I have with the languages I've used extensively in the past (C#, JavaScript, Python, etc.) But when it comes to Go, I absolutely adore its simplicity. I find myself wanting to write more Go code and I sometimes even catch myself trying to find reasons to write implementations in Go. Anyways, that's just my two cents.
  • solarkraft 7y ago
    Add to that that it's damn fast. That's a pretty good reason to use Go for me.
• danielnixon 7y ago
  I like this one: https://news.ycombinator.com/item?id=13485953 https://news.ycombinator.com/item?id=13485953
• ernst_klim 7y ago
  While I don't like Go very much, but I find this one unjustified: > Similarly, the len function on strings returns the number of bytes in the string, which is not necessarily the number of characters. Should len do unicode normalization (NFC)? Than it's extremely complex. Or should it count code points? Then it's simply broken. Counting bytes is fine, I'll do explicit normalization if I need to. >can be conveniently concatenated with +, and can be used as map keys. Does Go do a normalization for a concatenated string as it should?
  • biztos 7y ago
    I believe it does: https://play.golang.org/p/oU9Q1GF6kr- https://play.golang.org/p/oU9Q1GF6kr-
• DuskStar 7y ago
  As a go lover who programs in it daily... That section was fantastic, and I agree (almost) wholeheartedly. And the select code [0] is kind of horrifying. I am going to disagree with this, though: > Go's native package system does not support specifying versions or commits in the dependency information. Instead, the go community recommends that each major release have its own separate repository; github.com/user/package/package-{v1,v2,v3}. As far as I'm aware, you don't create a new repo for a new major version - just a new branch, or a subdirectory. This comment [1] from Russ Cox describes it pretty well IMO. (Though it appears that the page hasn't been updated since 2017, and Go Modules is more recent than that) 0: https://github.com/golang/go/blob/master/src/runtime/select.go https://github.com/golang/go/blob/master/src/runtime/select.... 1: http://disq.us/p/1qcpqao http://disq.us/p/1qcpqao
• majewsky 7y ago
  Many of the criticisms listed are fair (even though quite nitpicky at times), but there are a few that I don't want to let stand unrebutted: > Because strings are just slices of bytes, there is no simple way to index or slice a string if it contains non-ASCII characters. Indexing into a UTF-8-encoded string is expensive -- O(n) instead of O(1) -- so it's good that it also looks expensive. > Despite the above, Go has two competing types for representing text, string and []byte. As has any other serious language. Byte arrays and strings are just not the same thing. My only real gripe with Go's treatment of strings is that converting from []byte to string is a simple cannot-fail cast. That should be an operation that checks for valid encoding, and returns an error otherwise, like Rust's str::from_utf8. > Deleting the nth element from a slice sure doesn't look like deletion: [code snippet] This is a fair criticism, but IMO way overblown. I cannot remember the last time I had to delete individual elements from slices. Most of the time I'm doing map() or filter(), or rather, the equivalent spelled-out for loops since Go does not have generics. > If you import a library or declare a variable, but do not use it, your program will not compile even if everything else is valid. And that's great. I don't want old libraries bloating my program needlessly. It's sometimes a bit annoying to have to write _ = foo into unfinished functions because otherwise it will not compile due to "error: foo is never used", but I like my compilers strict. Also to this point: You can set up your editor to run your code through goimports automatically, which will completely do all the adding, removing and ordering of imports for you, as well as format your code according to the standard style. More languages need this. > If multiple channels are available to receive from or send to, the select statement picks a case at random, meaning that to prioritize one channel over another you have to write: [lengthy code snippet] Having to prioritize channels manually is a bit of a code smell in my opinion. I would need a real-world example to judge, but it smells like the real problem is how you slice up your work into goroutines. > Two implementations of random numbers, math/rand and crypto/rand. Again, this is completely standard for any serious language. For mathematical simulations, you don't care about cryptographic properties of your RNG and want the extra speed that a simpler RNG like a Mersenne twister gives you. > The errors package is twenty lines long, because Go's error type is simply an interface to a function returning a string. You forgot the criticism here. > Go's native package system does not support X All of these are wrong. Go has added a proper native package system in 1.11. > The contributors don't listen to the community. One of the two examples shows that the contributors do listen. > Almost nothing in this list can be fixed, because of the Go 1 compatibility promise. Until Go 2.0, that is, but that may never happen. That's the problem with crystal balls.