301–310 of 508 posts
Earlier quoted context omitted.
This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not inte…
If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. What you see on the internet is the union of everyone's complaints and frustrations. Each individual sees only some of those, maybe even none depending on the type of work they're doing. And the ones that are generally happy don't tend to post big rants, so the overall impression of an outsider can be pret…
That's bullshit. When I worked in the Ruby on Rails space, I saw critisms quite often... for example of the "one size fits all" way-too-large-surface-area library design (see: ActiveSupport) or the "fat model" design trend at the time... I even PRODUCED some of these criticisms myself. Heck, the bug that made me leave the space took a month to track down and had to do with nondeterminate behavior when merging a Hash with a HashWithIndifferentAccess (this was not my code, I would have not written it the way it was written, but it was a bug I was assigned to of someone else's code) because the Ruby language did not see these as two distinct "types" and simply went ahead as if they were both regular Hashes, which caused HWIA keys to get overwritten unexpectedly/nondeterministically... that was the last straw at the time.
And when I worked in .NET/ASP prior to that, I saw (and witnessed) MANY criticisms of the language and API such as how easy it was to produce difficult-to-test spaghetti code.
And while all this was happening I was also working on frontend code in JS and needless to say there have been A LOT of JS criticisms over the years and I've seen most of them.
So yeah, maybe try again with less BS. The biggest criticism I can produce of Elixir (and more generally the BEAM VM) is that too few people understand its advantages and too many people actively misinform others about it. (OK, one more criticism, but it is a more general criticism of functional immutable languages: A handful of algorithms perform suboptimally in a language that does not even permit mutation, relative to a language that does.)
Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…
> Go promised me that I wouldn't have to deal with such weird specific knowledge of its semantics. Where, specifically, did Go promise you that? I know of no languages where you don't, sooner or later, have to have weird specific knowledge of the semantics.
I think it's perfectly fair to say that this behavior is not in line with Go's philosophy.
Earlier quoted context omitted.
This is funny because after almost 4 years of working with Elixir and watching Go from arms’ length, I literally see NONE of the criticisms regularly leveled at Go. This is not an exaggeration. In fact, Elixir has few criticisms at all to begin with, and it’s driven very large sites already at this point. (Yeah, it can’t compile easily distributable self contained binaries. It’s not (yet) designed for that.) Not inte…
If you were using Go for those four years, you'd also see very little of the criticisms regularly leveled at Go. What you see on the internet is the union of everyone's complaints and frustrations. Each individual sees only some of those, maybe even none depending on the type of work they're doing. And the ones that are generally happy don't tend to post big rants, so the overall impression of an outsider can be pret…
Earlier quoted context omitted.
"Go programs are much less safe than programs written in Rust or Java for that reason." This is plain wrong. ( Rust included )
Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none…
The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.
> It constantly takes power away from its users, reserving it for itself. > It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. > It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is.
“Our users are stupid, prefer subtly wrong to a more complex but correct abstraction” is core to Go, and appears everywhere.
Go needs good criticisms like this. I will never understand why this language is so popular.
It's due to the same reason Rust is: it's backed by a large popular company investing in the language and being loud about it, which leads to a rapidly growing mindshare and ecosystem around it, which is essential for adoption. This is not meant as a criticism toward go or rust: the history shows several cases where this happened before irregardless of the technical merits. A language still needs to become popular, i…
I think the bigger thing that corporate support gets you, though, is a better library (more complete, more debugged, and more polished). That is an essential ingredient for language popularity. Up through Java, it was enough.
But these days, I think that there's one more ingredient needed: Solve some problem that isn't well-solved in other existing popular languages. Go has pretty good answers on multiple threads and network services. Rust has the borrow checker. Those are useful enough pieces to gain traction for those languages.
Earlier quoted context omitted.
that's true, but realize that golang is largely shepherded forward by a company with a legacy of C++ (maybe lesser C/java) heritage. you aren't getting legacy C++ programmers on board with "optional" types: they'll riot and pull the purity card (this doesn't look like "my C++"). google is probably grateful these people are no longer returning -1, -2 etc. for errors from their functions. consider things like the golan…
C++ has been adding things like optional types; std::optional was released in C++17, there's talk of maybe pattern matching coming soon...
The whole system has to be designed around it to get the benefit of it. Java programmers will be checking for null until the last line of Java is written.
Earlier quoted context omitted.
No, the name is definitely mutable. Consider: x = 1 capture = lambda: x x = 'foo' print capture() If python were just shadowing, this would print 1. But it prints foo.
That's an issue of scoping, not capturing. The x in the lambda isn't scoped to the lambda, it's scoped to the surrounding environment. So the x closes not over the lambda but the outer scope. So it's as expected given shadowing. Edit: Since I'm getting throttled: No, I'm saying that scoping rules are different in python and rust. In Rust (and cpp) there's the concept of scopes/closures as a first class feature. This…
[0]: https://en.wikipedia.org/wiki/Variable_shadowing#Python
Earlier quoted context omitted.
Being unaware of an exception thrown by a function when calling it in Java will cause compilers to bark at you - while doing the same in go will work until it doesn't. I think this is even more insidious with changes in third party code over time though - did the package your gigantic product uses to validate that a phone number is in European time just add an error return value to a function that previously had none…
It doesn't make Go much less safer than Java. Go is a safe language. Working long enough with Java I saw all the problems with exceptions and NPE and can tell you that those problems are less prominent with Go.