Hello! Recently I read somewhere that Go does not need frameworks at all, so what is the reason to learn them, but to faster your work? And what frameworks are usually used in real projects in tech companies? I’m so confused right now…
As always, this depends. There is no typical “real project”, only projects with similar or different requirements. Some of these requirements may make it feasible to use a framework, others may not.
Start with the Go standard library.
Excellent advice from lutzhorn. Go with the standard library.
There are lots of reasons to do that:
- You’ll learn the standard library, which is extremely good (in both quality and performance).
- Frameworks usually expand upon the concepts from the standard library, so even if you decide to use frameworks (later), it is better if you know the standard library already.
- The standard library always works with the version of Go you are using, since it is built into the Go release.
- If you use external libraries, you introduce additional dependencies:
a) Can make writing your code trickier, since Go does not allow cyclical package dependencies.
b) Can make compiling your code trickier (this is why Go modules were introduced).
c) Quality of external libraries varies (some are really good, others, not so much).
d) It’s not always obvious which versions of external libraries are compatible with which versions of Go.
More notes about learning Go:
Beginning Perl (Wiley © 2012 / Wrox)
Chapter 19: The Next Steps
It’s difficult to say that you truly understand a programming language until you understand the libraries for that language. Your author, for example, “knows” Java and has programmed in it from time to time, but he doesn’t actually know the common libraries for the language. Thus, although he may be a strong programmer, many companies would think twice about hiring him as a Java programmer. (Or he’d take such a serious pay cut that it wouldn’t be worth it.) This chapter introduces you to the unholy trinity of Perl: DBIx::Class, Template Toolkit, and Catalyst. These three modules are probably the most common modules used to build large-scale websites. They give you incredible power, but they take quite a while to learn.
Additional book quotes here. (Go Forum)
Do not resume only at standard library even it’s a good one. Complex applications needs many more things like routes, middlewares for authentication or sessions. You can’t achieve all those very easy without a decent framework or a toolkit. Personally I use Gorilla toolkit but are many good options like Echo, Gin and so on.
I only use Go to program my own personal projects and have never worked with a team for Go development, so take this advice with a grain of salt, but I would suggest to use the standard library by default until you have a reason not to.
When you have a concrete scenario, e.g.:
I have problem
A. I’m trying to use package
Xfrom the standard library but that has been difficult because of
Band/or it causes issue(s) with
I would recommend posting on this same community (or another like it) to ask “What should I try now?” People here will provide helpful answers like “I had that issue too and package
Y fixes it,” or better yet, “Package
Z in the standard library was built specifically to solve that!”
By trying to stick to the standard library, you make it easier for developers using your package to understand it so they’re both comfortable enough to use it in their own projects and/or more likely to contribute to your project because it’s based on the standard library.
However, when you really do need more than the standard library has to offer because your problem domain is outside of what the standard library solves, then it makes sense to find another library. Albert Einstein is attributed the following quote: “Everything should be made as simple as possible, but no simpler.”
Overheard in conversation.
What do you think of the ‘Rails’ language?
Ruby is the language, Rails is a framework written in the Ruby language.
@nurmi-labs I’m not sure I understand; is your point that knowing the language is only part of the job, and that you need to know libraries to be a more productive developer in a language? If so, I agree that you need to know libraries, but my point is that the standard library is powerful in Go. If you’re starting a new project and need to host a web site from it, I would still say start with the standard library until you have a reason to switch.
If you know ahead of time that you’re going to need something feature-rich, then using a library makes sense, but at the same time, if you don’t know exactly why you need a library, then how do you know you’re picking the right one? When someone asks “what web framework should I use for my new project?” It’s hard to provide a useful answer without knowing exactly what they’re doing. People answer based on their own experiences they’ve accumulated from projects that they’ve worked on, but it’s hard to know if that particular library will help the asker.
I still think the right way to do it is to use the standard library until you determine that it won’t work for you. Then when you ask the community what they suggest, you can provide background to the issue you’re having so they can provide relevant suggestions.
Two other languages in which frameworks have been written have been mentioned above.
Also considerations on external dependencies, and the relevance of the standard library.
But what has not been touched upon has been best practices, and I would refer then to the following.
As Perl has been mentioned, to use an example from another language, I recently created a global cache for MetaCPAN modules, an ordinary user (not a member of the wheel group) can test whether the dependencies will install, considerations thereby referring to the version of the system Perl, and MetaCPAN modules’ versions, then a member of the group wheel can download those MetaCPAN module versions into the global cache, installation of OO modules required by DBIC (a.k.a. DBIx:Class) and Best Practices’ modules (a.k.a. Perl::Critic & dependencies); DBIC is used with the Catalyst framework. There were 2 minor issues with the installation of the Best Practices’ modules, a Clone module dependency did not pass all tests on some Linux distributions, the failing test went through a poor man’s rewrite, and a new release was made within a day, and circa Perl v5.26 a new regexp modifier was added, and as I was running Perl v5.22.2, this caused shell messages to be output when starting Perl::Critic, running a
sed command on one of the Perl::Critic .pm files (post-install) corrected that.
Basically this comes down to economics, is it efficient to use a framework where there is the potential of an increased burden upon software maintainers, the learning curve of personnel regarding the framework of choice notwithstanding.
I’ll put in a plug here for Eris, minimalism at its best.