|
|
|
|
|
|
by cjk
1264 days ago
|
|
|
I've written a heaping pile of Go code over the last few years. I consider myself a fan, but not a fanatic. I tend to believe that Go's failings aren't any worse than the failings of most other languages, and for me, the drop-dead-simple cross-compiling and batteries-included standard library is well worth its warts. That said, I found myself vehemently agreeing with the author re: how hostile Go is to FFI/etc. IMO, a network boundary is indeed the sanest way for most other things to communicate with Go code. Re: Go on Windows: anecdotally, things seem a lot better than even a couple years ago, but there's still room for improvement for sure. It's baffling that the semantics of e.g. os.Rename() are so different between POSIX-y platforms and Windows when they don't have to be (Windows supports POSIX-style renaming semantics if you ask nicely). I ended up having to reimplement os.Rename() on Windows in terms of SetFileInformationByHandle() with the FILE_RENAME_POSIX_SEMANTICS and FILE_RENAME_REPLACE_IF_EXISTS flags set to get the behavior I was looking for. Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now, and there are plenty of strategies for dealing with it. For example, if I want to pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface with getter methods for its fields, but no setters or anything that can cause side effects. Sure, it's a bit more involved than tagging something with the `const` keyword in e.g. C++, but it's plenty effective. |
|
|
Yes.
Do not minimise this.
For very large complex systems immutable state is very helpful.
> pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface
Making the point.
Horses for courses, but this is picking the course for this nag.