Have you ever actually taken a look at it? https://nodejs.org/api/index.html
> In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. Because the standard library is so good, for most projects this is perfectly reasonable.
Meh. The Python stdlib has been considered "good" for a long time[0], but the last few years people commonly reach out for external dependencies.
It's not because the stdlib has gotten less good (the opposite), it's because the experience of publishing and using external dependencies has significantly improved.
> I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager.
They do, they just don't have one. Which is why people tend not to bring in external dependencies: bringing in external dependencies in Go is a traumatic experience, much as it used to be in Python a few years back.
[0] in fact this exact same argument was relatively common in the mid-to-late aughts, Java developers dipping their toes into Python would complain about the state of dependency management and get told that the stdlib is so good you don't need dependency management, the stdlib is almost all you need and there's no need for advanced dependency management for just one or two dependencies…
few years back being pre-2011, with pep 405[0] and virtualenv[1] solving most of the nostalgic py dep hell problems.
venv's been a option since 2007, only getting pep'ed later?
Initial pip release was also 2011. Now I wonder what I used pre-pip?!
edit: easy_install, doh!
For not needing a dependency manager, Go sure has developed an amazing number of them!
https://github.com/golang/go/wiki/PackageManagementTools
https://github.com/avelino/awesome-go/blob/master/README.md#...
In fact, Go probably has the most package managers of any language I've ever seen.
And of course, standard library APIs age with time. Perl and Python are good examples. Both ship with packages that were really good in their day, but have long since been superceded by community-created tools. But the core has to keep shipping the old thing for backwards compat and the maintainers are reluctant to add yet another package that does the same thing.
Dependencies have their downsides, but being able to assemble the best of what's out there rather than relying on the best of what was available at some point in the past has a lot of advantages too. Languages with good dependency management seem like the best possible option.
Go's refusal to embrace this is a huge pain point. Dep is a decent start, but without a community actually doing things like releases, changelogs, and all the other things that go into a solid ecosystem, it's a half measure at best.
Go has indeed embraced it and is working on `dep` the officially sanctioned dependency manager.
It's under the official golang github repository.
https://github.com/golang/dep/graphs/commit-activity
Agreed that it's a decent start, however I disagree with the lack of releases. If you look at the git history there is a lot of activity in it.
I've found some legitimate bugs[1] in simple functions that don't give me a ton of confidence in it either.
Personally I find the standard libraries in the likes of Python and .NET Core much more comprehensive, intuitive, and reliable.
[0]: https://golang.org/pkg/time/#Time.Format [1]: https://github.com/golang/go/issues/15852
It's sure not perfect, and it's impossible to please everyone but I think it was worth the experiment.
i don't understand this. yes net/http is nice but there's no router, there's no orm (yes i know that's not really possible at all because of strong typing), yes database/sql exists but you know most everyone uses at least sqlx and e.g. lib/pq. yes html/template is nice but we're all doing SPAs now anyway. okay there's logging but e.g. no websockets. so in what sense is the stl really complete? what modern web app could you write with just the stl?
You don't need an ORM. Mapping database tables to objects directly is a really bad idea. Write SQL, it's easy, simple and cheap. Yes, you'll repeat yourself. Golang generally prefers some repetition to some dependency.
You don't need middleware. Once you get used to handling routes as logic, then the need for middleware kinda vanishes.
You can use the semi-official google websockets package [0]. It's borderline whether this could be considered part of the standard library or not (I use the google uuid package all the time for the same reason). I believe there's an intention to include these packages in the standard library at some point, probably Go v2.
Try it out, it's liberating.
You don't need middleware, but it is much more readable with r.Use(jwtVerify) then writing a deeply nested half router with logic.
If you're running a single endpoint, then the router is adding zero value.
Community should better be saying try std library if you find it verbose try framework(router+ORM)
Those people should try being maintenance programmers sometime /curmudgeonly-grumble
I agree, but the point is that you can do this with just the "almost official" package. It's not like you have to use the gorilla package because there's no standard library package.
And, Go had many third-party Router, ORM, Websocket and Template Engine implementations out there, many of them are also proud to be ... independent, so you're less likely to end up in a Dependency Hell.
Go standard library is not there to force people to use it, rather, it's there to setup a standard so different people can work together more effectively.
So:
> in what sense is the stl really complete? what modern web app could you write with just the stl?
1, It's huge, but not complete;
2, You can actually do it with just Go standard library (No third-party package) if you REALLY wants to. It's not very hygiene though, you will end up wrap many things up for better project structure (And resulting many packages that you might later proudly put on your GitHub page): Use net/http as HTTP server (Request handling and parsing); use net.Dial to connect database and cache (And write their protocol); html/template for outputting rendered HTML landing page; encoding/json for parsing and outputting API request and respond.
Three fallacies of dependencies: https://www.youtube.com/watch?v=yi5A3cK1LNA
> what modern web app could you write with just the stl?
Lots. You just have to change your frame of mind.
> i know that's not really possible at all because of strong typing
Once you realise the above, you also realise that most of the time you don't need all that fancy stuff and you just write super boring code that works.
This. This is the essence of Go to my mind :)
As for ORM, you should basically never use an ORM, ever. They’re a crutch. Learn SQL, write some basic mappers and your SQL will be so much quicker and more optimized than an ORM can generate. An ORM is literally throwing money out the window.
But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done.
I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again.
If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.
The DB access parts of the code look similar to the rest of the codebase, rather than a chunk of text embedded that looks like ransom note (kidding - I know caps aren't mandatory). Enough fine control to closely influence the generated query. No real performance penalty. There's also a good mocking library available for tests.
It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object <-> table mapping) it's all scary and weird.
Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though.
So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA
What? Definitely the opposite. First of all, ORMs are just tools, as the name implies they are object-relational-mappers. That's it, you writing SQL to translate to objects is just you writing an ORM, although a very tiny one.
Modern ORM frameworks are incredibly more productive with better security and reliability than hand-crafted SQL and mapping code. Unless you're working at serious scale, doing custom reporting, or other complex scenarios, they handle 99% of CRUD database operations perfectly well. Wasting time reimplementing an existing tool is quite literally throwing money out the window.
No. Absolutely not. This is the fundamental mess that ORMS create.
Objects DO NOT map cleanly to tables.
Eventually your code discovers this, and suddenly it's a world of pain because the ORM can't handle it.
Let me tell you one thing that isn't solved yet: Serialization of arbitrary objects to json and back.
How do you deal with two refererences pointing to the same object? Duplicate the data?
What about circular references? Give each object an id and save a symbolic reference?
What about polymorphism? Should a json array be turned into an array or an list or a json map turned into an object or a hashmap?
You need a type discriminator attribute.
ORMs have already solved those problems well.
The actual problem is that databases are distributed systems and you still have to write queries with the still 10 times better querybuilder of your ORM. Just try writing raw JDBC queries. It's so painful I'd still use the ORM even if my project only uses native SQL queries via the ORM api.
You will probably now ask what's the point of ORMs if you still have to write queries? Well, it's in the damn name. Object relational mapper. It maps stuff. It's not advertised as WYQFY. "Writes your queries for you"
As mentioned, if you're in the 1% scenario where this approach doesn't work then you already know you should be using something else. Not knowing when to use what is a far bigger issue than any problem an ORM can cause.
If you throw away the concept that anything in your database has to map to anything in your code base, then you design better databases. Different databases, more to the point.
You can lay out your tables however you want, and you can then map them to objects using an ORM. That's what mapping means, to translate from domain to another. There's no limit on how things are actually designed and ORMs usually do a much better job of handling all that bulk code for you. Nothing is stop you from writing SQL yourself if you really need something complex but again, you should know when and where that is.
In Node, the standard library is effectively non-existent, so Node devs get trained and acclimatised to dependencies.
In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. Because the standard library is so good, for most projects this is perfectly reasonable.
I'd say the first thing every Node dev should know when learning Go is that they don't need a dependency manager. If you can't do it with the standard library then you're probably doing it wrong (at least until you've got some experience with the library).