> (Note that path/filepath violates Go naming conventions - “don't stutter” - as it includes “path” twice).
That guideline is for package/content name, not package directory names. https://blog.golang.org/package-names
I Want Off Mr. Golang's Wild Ride
11–20 of 508 posts
Re: I Want Off Mr. Golang's Wild Ride
#12Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…
There's some stuff in there about it not handling valid edge cases on Linux particularly well, either, though.
Re: I Want Off Mr. Golang's Wild Ride
#13I felt the same way after writing a large (100kloc) project in Go, this is back when go was 1.0 or so as well. It started off well enough, but eventually started to fail in helping me create the software I needed to make.
i cannot comment on v1.0 but i too work on larger project and it is tiresome to write so much code, many repetitions and the same stuff in general. but i think it is not the language that is the problem. plainly, it's just the sheer size of the project. sure, DRY and generics would help out but i guess only to you as a dev, to save some time, not to the project itself. when i jumped into the go world and have learnt that code generators are VERY popular. I hated the idea and it was a big no no. but in time I came to like it and now i am a big fan. i like to use protocol buffers and generate code from them so that i have a nice schema as single source of truth that is well documented and strongly typed. with lyft's protoc-genstar, it is very easy to write your own code generator.
Re: I Want Off Mr. Golang's Wild Ride
#14If somehow we had a way of checking Golang's source and submit our desired changes...
Re: I Want Off Mr. Golang's Wild Ride
#15> which makes a lot of problems impossible to model accurately Impossible? > (instead, you have to fall back to reflection, which is extremely unsafe, and the API is very error-prone), Extremely unsafe? > when you make something simple, you move complexity elsewhere. Does it? Or did you, in reality, not really make it simpler? > Go says “don't worry about encodings! things are probably utf-8” Does it? https://blog.go…
It's the fairest point, modeling some issues is a pain in go, particularly dynamic data types (think ActivityStreams).
Re: I Want Off Mr. Golang's Wild Ride
#16What a ridiculous and narrow thing to get so upset about.
It's not ridiculous. Functions should not be returning garbage values when an error occurs.
This is the worst part of javascript and certainly it's not pleasant to uncover this in Go.
Re: I Want Off Mr. Golang's Wild Ride
#17Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…
What is it then if not a con?
I mean, C# not running well on unix systems was immediate show stopper for a lot of projects but we can't call this a "con"?
Re: I Want Off Mr. Golang's Wild Ride
#18A lot of people seem to be missing an overarching point, which is the benefits of a language having Sum types, so that edge cases can be represented clearly, and in a way where the consumer of the api can't fail to know they exist, and can't fail to handle them. Anyone thinking of making a new language today, should really get some familiarity with Option and Result types. They make so many things not only safer, but also nicer to use.
Re: I Want Off Mr. Golang's Wild Ride
#19It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness
I don't know how this comment appears to come as a new thought after them using Go in production. I don't use it at all for work but that is literally my understanding of the point of Go; granular "correctness" as a trade off for the productivity it provides if you're doing things that are just on the "good path"
Re: I Want Off Mr. Golang's Wild Ride
#20> which makes a lot of problems impossible to model accurately Impossible? > (instead, you have to fall back to reflection, which is extremely unsafe, and the API is very error-prone), Extremely unsafe? > when you make something simple, you move complexity elsewhere. Does it? Or did you, in reality, not really make it simpler? > Go says “don't worry about encodings! things are probably utf-8” Does it? https://blog.go…
It's the fairest point, modeling some issues is a pain in go, particularly dynamic data types (think ActivityStreams).
Debating whether certain domains are more difficult/painful in Go than other languages is valid. Saying they are impossible is extreme.