3 ms·

>It's not the kind of library that Go wants as its standard library. It's a perfectly sensible sort of library. It just isn't what is desired in the standard li

by scythe 7y ago

>It's not the kind of library that Go wants as its standard library. It's a perfectly sensible sort of library. It just isn't what is desired in the standard library. "What is desirable in the standard library" is a very exclusive list. This sounds like a reasonable argument if your language is, say, Julia, or something like Lua, where in the first case you probably don't write code that needs to do a lot of work at the OS/network/hardware level, i.e. systems programming, and in the second case, the language has a good built in FFI that lets you drop down into C or a similar language to do systems programming. Python, Clojure and Ruby fit more-or-less into the second case. C simply forces you to do all of the work yourself. But Go's FFI (cgo) is a constant source of consternation, and while Go's authors admit it might not be suitable for "the largest" codebases, the hostility of Go to good FFI makes it more uncomfortable to use in practice. The official viewpoint is something to the effect of "most people shouldn't need cgo". The result has been a proliferation of libraries that attempt to do systems programming in Go, which includes in particular the "monotime" debacle highlighted by the author. Remember: this blog post highlighted this weirdness in a real library used to solve a real problem. The idea that Go isn't meant to be used for that is belied by the fact that many, many people do try to use Go for that. So yes, if Go had a more "difficult" file library, it would be less consistent with the "simplicity" idea used to advertise the language, but it might be more consistent with the way that Go is used in practice.

mntmoss 7y ago
Yes, and the FFI friction maps to my main concern with Go as it stands: it's a bit like Python in that it wants to be extended rather than embedded. That always creates a "hollowing out" of its core over time as users exceed the capacities of its standard library and try to push it into new environments. In contrast, Lua, for example, has a parasitic quality to it: make the host more powerful and then you can easily give Lua similar powers. However, the other half of that is that in a lot of cases, the libraries are chosen, not the language. And then why would you choose the janky "worse is better" libraries? Well, there is a reason: at some level all your code is still a prototype or draft and the "real thing" is yet to come. And then Go looks rather successful on that front in that its primitivism works at the outset and ships a lot of software, which in turn creates the demand for the heavier "big-boy" solutions. That's a thing I often don't see addressed in this kind of rant.

by scythe 7y ago

mntmoss 7y ago

Yes, and the FFI friction maps to my main concern with Go as it stands: it's a bit like Python in that it wants to be extended rather than embedded. That always creates a "hollowing out" of its core over time as users exceed the capacities of its standard library and try to push it into new environments. In contrast, Lua, for example, has a parasitic quality to it: make the host more powerful and then you can easily give Lua similar powers. However, the other half of that is that in a lot of cases, the libraries are chosen, not the language. And then why would you choose the janky "worse is better" libraries? Well, there is a reason: at some level all your code is still a prototype or draft and the "real thing" is yet to come. And then Go looks rather successful on that front in that its primitivism works at the outset and ships a lot of software, which in turn creates the demand for the heavier "big-boy" solutions. That's a thing I often don't see addressed in this kind of rant.