3 ms·

Look, I'm a big fan of go; I like the language, I (mostly) like the community, and I've seen some excellent stuff built in it. ...but, this 'dont use anything

Look, I'm a big fan of go; I like the language, I (mostly) like the community, and I've seen some excellent stuff built in it. ...but, this 'dont use anything but the standard library' movement that keeps popping up here and on reddit is just ridiculous. It's just fall out from people who can't be bothered figuring out how to use 3rd party dependencies. No matter how amazing and excellent your language development team is, the man power of work in the wider ecosystem is significantly larger, and avoiding the work done by others to 'hand roll' your own solution is not the answer. Yes; learning frameworks is tedious. Yes... sometimes someone elses 'style' of code might not match yours... ...but, you have to ask yourself: are you writing code as an intellectual exercise, or trying to build something? Because, if you're trying to build something, and you want to write every little piece of it yourself; you'll never build it. This is the same (daft) argument as people suggesting they build their own game engines. Building websites isn't trivial; and there are parts you need to do it aren't in the standard library, and never will be (eg. redis, memcache, elasticsearch, aws, grpc, the list is endless). I appreciate the simplicity of just 'standard library only' to get started, realistically, is it meaningful to talk about? I doubt you'll ever write a service that is 'standard library' only.

deleted 10y ago
[deleted]
grey-area 10y ago
I mostly agree. Things you'll need in a more sophisticated app which are not in the stdlib and would be tedious to reinvent each time: named params, auth, csrf, nested templates, minified and fingerprinted css/js, grpc as you mention, wysiwyg editing, stats, oauth etc. Many projects will only need a few of these, some will need all, and almost all non-trivial code needs third party libraries of some kind. Using go just for services and writing your ui in js just means you're shifting those problems into js libraries, and now you have 350,000 problems, including left-pad. I agree this hostility to a 'framework' (a.k.a. a bunch of libraries) while containing some truth, has become a damaging religion. Library authors in Go tend to stress they are not writing a framework to appease the anti-framework gods, and new users are told to just use the stdlib without the caveat that larger projects will require more structure and pkgs from elsewhere. The main reasons new users and in particular beginners look for a framework to get started with are quite simple - it provides guidance as to best practices, provides reassurance when they face unfamiliar problems, and gives them a community to ask questions in if they get stuck. None of these are unhealthy reasons. I do understand and sympathise with the hostility in some quarters to frameworks as monolithic bags of code which everyone imports and uses when they don't have to, but feel this hostility is being cargo-culted on places like reddit rather than understood as an admonition not to unthinkingly import lots of code.
twotwotwo 10y ago
The "using only the Go Standard Library" was added to the title when it was posted to HN. The post builds an example app with the stdlib, but I don't see advocacy against using other code in it. I think python.org leaves writing a Django introduction to the Django people; this seems like that. The Go community does have a tendency to avoid building or looking for all-inclusive frameworks, but, e.g., gokit.io, gorillatoolkit.org, and various third-party database tools (sqlx, gorm) are still popular.
_ph_ 10y ago
This article is meant as an entry-level tutorial. And for that I quite appreciate how it shows the basic mechanics of the standard library. Of course, for a production application, you would introduce other libraries and frameworks as needed, but for teaching, it quite helps if not too many layers are added. You should add an external library to a project only after you clearly understood, which problem it solves and how :).
PaulRobinson 10y ago
So, first of all, for the examples you cite - reds, memcache, elastic search, aws, etc. - I have never, ever seen a member of the Go community say "don't use a library". The Go community is anti-framework, not anti-library. And what's the problem with frameworks? Well, remember up until now most Go shops (including my own), are micro-service orientated. You want small, lightweight, high-performance services. Why would you want or need a large monolithic bag of tricks in there? If you need complex routing, are you sure it's a micro-service? If you can't keep track of the datastore and need an ORM, are you sure it's a micro-service? Also, it's a discipline, not a requirement. In the same way other languages have their idioms (I'm a Ruby dev of 10+ years experience too - those idioms are baked in _hard_ for me), Go's idioms are around structure, performance, and what is reasonable to write at a larger level. Should you use libraries in Go? Yes. Should you use frameworks? Nobody is stopping you, but are you sure Go is the right place for you and your monolithic application? Also, I don't see a problem with the official Go website having a tutorial in Go using the standard library. Why would they not?
- crdoconnor 10y ago
  There's multiple good reasons for using a framework. 1) It enforces appropriate design patterns for the task at hand. 2) It produces code structures that are standardized rather than idiomatic. 3) It provides a superstructure that allows the integration of a variety of different plugins without having to write a lot of boilerplate. I've no doubt this applies to go as equally as it applies to any other language. That said, bad frameworks (which is most of them) are often worse than none at all.
  - PaulRobinson 10y ago
    I don't think you read my comment, or at least if you did, you didn't understand the point I was making. Micro-services are the appropriate design pattern that means frameworks are redundant in a micro-service architecture. Code structures do not need to be standardised in a service you can read the entire source code to in 20 minutes and replace in a few days if you need to. Micro-services do not want or need the integration of a variety of plugins, and little to no boilerplate is required.
dualogy 10y ago
> ...but, this 'dont use anything but the standard library' movement that keeps popping up here and on reddit is just ridiculous. It's just fall out from people who can't be bothered figuring out how to use 3rd party dependencies. Unlikely, I myself slowly came to arrive at this philosophy after 15 years in programming. Nothing lasts forever except bit-rot! Look if I want to look back at my youth in old age, that'll mean looking at, running, playing with old code. Do I want my time spent discovering and documenting obscure bugs in rare contexts/situations of other people's code, or my own? Guess which. Has a 3rd-party framework/lib been fine-tuned and painfully optimized for many months for my actual use-case, or their authors'/audience's? Guess which. Is the stuff these actually offer any actual rocket science, or just pretty basic easily grokked stuff except 80% of it I don't even need and that 10% I really do and nobody covers turns out to be nigh on impossible to integrate with their very peculiarly own idiomatic ways of describing things which I wouldn't ever have any trouble parsing through had they used my own peculiarities? Guess. Now don't get me wrong, am I going to reinvent CUDA, OpenGL, .NET/JVM or other crucial infrastructure layers, of course not. But most helper libraries and bootstrapping frameworks are at best fluff for a MVP, then get that timebomb the hell out of your codebase built-to-last-the-ages. Do it for your golden years. (I make an exception for 3rd-party Haskell code as of now. First, you usually just need functions together with the insights that drove their design and workings, not as copy-paste but to adopt-adapt and thus most efficiently learn from. Secondly, the core language is just 6 primitives or so, everything else in Haskell is technically syntactic sugar and language extensions, so writing "pure" Haskell would probably be as nightmarish as coding in Lisp s-expressions (then again, I sure know some delight in this). Thirdly, with equational reasoning and referential integrity guaranteed for every piece of Haskell code that compiles, the fragility is a lot less and mostly comes from IO interactions with the outside/real world, which I'm ultimately going to recoup control over myself anyway. Further, most Haskellers are as of now way more seasoned and I can only learn from their work. Even furthermore, even much/most of the built-ins are written for learners or clarity, not efficiency/robustness/all-edge-cases-correctness/etc and will need custom replacements with time, on a case-to-case basis. Lastly, it'll be a breeze (in comparison) to just keep various versions of older compiler versions around, it's all quite self-contained for the most part, Stack excels at this but one could decidedly do so manually in case Stack gets stuck decades later.)

deleted 10y ago

[deleted]

grey-area 10y ago

I mostly agree. Things you'll need in a more sophisticated app which are not in the stdlib and would be tedious to reinvent each time: named params, auth, csrf, nested templates, minified and fingerprinted css/js, grpc as you mention, wysiwyg editing, stats, oauth etc. Many projects will only need a few of these, some will need all, and almost all non-trivial code needs third party libraries of some kind. Using go just for services and writing your ui in js just means you're shifting those problems into js libraries, and now you have 350,000 problems, including left-pad. I agree this hostility to a 'framework' (a.k.a. a bunch of libraries) while containing some truth, has become a damaging religion. Library authors in Go tend to stress they are not writing a framework to appease the anti-framework gods, and new users are told to just use the stdlib without the caveat that larger projects will require more structure and pkgs from elsewhere. The main reasons new users and in particular beginners look for a framework to get started with are quite simple - it provides guidance as to best practices, provides reassurance when they face unfamiliar problems, and gives them a community to ask questions in if they get stuck. None of these are unhealthy reasons. I do understand and sympathise with the hostility in some quarters to frameworks as monolithic bags of code which everyone imports and uses when they don't have to, but feel this hostility is being cargo-culted on places like reddit rather than understood as an admonition not to unthinkingly import lots of code.

twotwotwo 10y ago

The "using only the Go Standard Library" was added to the title when it was posted to HN. The post builds an example app with the stdlib, but I don't see advocacy against using other code in it. I think python.org leaves writing a Django introduction to the Django people; this seems like that. The Go community does have a tendency to avoid building or looking for all-inclusive frameworks, but, e.g., gokit.io, gorillatoolkit.org, and various third-party database tools (sqlx, gorm) are still popular.

_ph_ 10y ago

This article is meant as an entry-level tutorial. And for that I quite appreciate how it shows the basic mechanics of the standard library. Of course, for a production application, you would introduce other libraries and frameworks as needed, but for teaching, it quite helps if not too many layers are added. You should add an external library to a project only after you clearly understood, which problem it solves and how :).

PaulRobinson 10y ago

So, first of all, for the examples you cite - reds, memcache, elastic search, aws, etc. - I have never, ever seen a member of the Go community say "don't use a library". The Go community is anti-framework, not anti-library. And what's the problem with frameworks? Well, remember up until now most Go shops (including my own), are micro-service orientated. You want small, lightweight, high-performance services. Why would you want or need a large monolithic bag of tricks in there? If you need complex routing, are you sure it's a micro-service? If you can't keep track of the datastore and need an ORM, are you sure it's a micro-service? Also, it's a discipline, not a requirement. In the same way other languages have their idioms (I'm a Ruby dev of 10+ years experience too - those idioms are baked in _hard_ for me), Go's idioms are around structure, performance, and what is reasonable to write at a larger level. Should you use libraries in Go? Yes. Should you use frameworks? Nobody is stopping you, but are you sure Go is the right place for you and your monolithic application? Also, I don't see a problem with the official Go website having a tutorial in Go using the standard library. Why would they not?

crdoconnor 10y ago
There's multiple good reasons for using a framework. 1) It enforces appropriate design patterns for the task at hand. 2) It produces code structures that are standardized rather than idiomatic. 3) It provides a superstructure that allows the integration of a variety of different plugins without having to write a lot of boilerplate. I've no doubt this applies to go as equally as it applies to any other language. That said, bad frameworks (which is most of them) are often worse than none at all.
- PaulRobinson 10y ago
  I don't think you read my comment, or at least if you did, you didn't understand the point I was making. Micro-services are the appropriate design pattern that means frameworks are redundant in a micro-service architecture. Code structures do not need to be standardised in a service you can read the entire source code to in 20 minutes and replace in a few days if you need to. Micro-services do not want or need the integration of a variety of plugins, and little to no boilerplate is required.

dualogy 10y ago

> ...but, this 'dont use anything but the standard library' movement that keeps popping up here and on reddit is just ridiculous. It's just fall out from people who can't be bothered figuring out how to use 3rd party dependencies. Unlikely, I myself slowly came to arrive at this philosophy after 15 years in programming. Nothing lasts forever except bit-rot! Look if I want to look back at my youth in old age, that'll mean looking at, running, playing with old code. Do I want my time spent discovering and documenting obscure bugs in rare contexts/situations of other people's code, or my own? Guess which. Has a 3rd-party framework/lib been fine-tuned and painfully optimized for many months for my actual use-case, or their authors'/audience's? Guess which. Is the stuff these actually offer any actual rocket science, or just pretty basic easily grokked stuff except 80% of it I don't even need and that 10% I really do and nobody covers turns out to be nigh on impossible to integrate with their very peculiarly own idiomatic ways of describing things which I wouldn't ever have any trouble parsing through had they used my own peculiarities? Guess. Now don't get me wrong, am I going to reinvent CUDA, OpenGL, .NET/JVM or other crucial infrastructure layers, of course not. But most helper libraries and bootstrapping frameworks are at best fluff for a MVP, then get that timebomb the hell out of your codebase built-to-last-the-ages. Do it for your golden years. (I make an exception for 3rd-party Haskell code as of now. First, you usually just need functions together with the insights that drove their design and workings, not as copy-paste but to adopt-adapt and thus most efficiently learn from. Secondly, the core language is just 6 primitives or so, everything else in Haskell is technically syntactic sugar and language extensions, so writing "pure" Haskell would probably be as nightmarish as coding in Lisp s-expressions (then again, I sure know some delight in this). Thirdly, with equational reasoning and referential integrity guaranteed for every piece of Haskell code that compiles, the fragility is a lot less and mostly comes from IO interactions with the outside/real world, which I'm ultimately going to recoup control over myself anyway. Further, most Haskellers are as of now way more seasoned and I can only learn from their work. Even furthermore, even much/most of the built-ins are written for learners or clarity, not efficiency/robustness/all-edge-cases-correctness/etc and will need custom replacements with time, on a case-to-case basis. Lastly, it'll be a breeze (in comparison) to just keep various versions of older compiler versions around, it's all quite self-contained for the most part, Stack excels at this but one could decidedly do so manually in case Stack gets stuck decades later.)