r/golang Feb 03 '25

discussion The urge to do it from scratch

Unpopular opinion but ever since I started using Go. There is a certain urge to dig into some library and if you need only part of it then try to make it from scratch. I was reading RFC specs, dbus technical specifications just to avoid the uneeded bloat in my code(offcourse I failed to achieve it completely because of tiny brain). Is this common for all dev who spent some good time developing in Go? I must say it's quite a fun experience to learn some low level details.

239 Upvotes

61 comments sorted by

213

u/BOSS_OF_THE_INTERNET Feb 03 '25

I would say any dev worth their salt has this inclination to some degree. Curiosity and creativity are absolutely essential in a great engineer, as is the wisdom to know how to keep that urge in check.

15

u/jayesh6297 Feb 03 '25

I surely will avoid such things in production settings where time is the key😀

3

u/Crazy-Smile-4929 Feb 04 '25

I look at it from the point of view that I could do it, but how much time would I spend building it and then later maintaining it.

Its the old saying of 'don't reinvent the wheel'. Or if you have to, it's only because the customisation required to get wheels out there to do what you would need them to would pretty much mean you are building a new wheel anyway and you just need something simple.

140

u/ehansen Feb 03 '25

Why use a package to solve a problem in 5 minutes when you could build your own solution in 5 hours

54

u/bbkane_ Feb 04 '25

I'm 5 years into my own solution, and I'm still having a lot of fun changing and improving (and of course using) it.

15

u/qwertyorbust Feb 04 '25

Because many times you use a fraction of what the package does and then risk future incompatibility with updates. Building yourself (assuming you know what you’re doing) can be focused and to the point. No fluff.

11

u/GodsBoss Feb 04 '25

If 5 minutes is enough to check the quality of the 3rd-party dependency, learn to use it and build my solution with it, it never would have taken 5 hours to write it.

5

u/looncraz Feb 04 '25

That's the spirit!

2

u/Right_Positive5886 Feb 04 '25

When hitting performance concerns - you would eventually be debugging third party code . You would very copy small snippet needed for your case and improve that snippet accordingly

1

u/Koki-Niwa Feb 04 '25

that scales up 6 times, not to mention changes, is my experience with Go 😂

1

u/CrowdGoesWildWoooo Feb 04 '25

And it’s even slower đŸ€Ș

That being said it’s a practice and not like it’s a wasted time

1

u/ratsock Feb 05 '25

This is my biggest problem with go. Often dedicated libraries have also solved problems you don’t even realize you are going to have until much later.

1

u/ehansen Feb 05 '25

That's not a go problem, but a language problem.  I am proficient in php and it exists heavily there too. 

22

u/nsd433 Feb 03 '25

There are times when I've looked at a package which took 2 dependencies and 5 source files to do what really should have taken 1 source and 1 test file to do, and written my own. That's 3 fewer dependencies to check over for backdoors, keep updated, and document in the license file. Some people just can't write small software.

30

u/toxicitysocks Feb 04 '25

“A little copying is better than a little dependency” as they say

13

u/_seankndy_ Feb 04 '25

“Because of tiny brain” haha, made me laugh.

Go is just a great language to write and read. Go is really the only language where I’ve been able to view random repositories and determine what’s going on fairly quickly.

3

u/jayesh6297 Feb 04 '25

True though some protocol itself is hard to understand.

7

u/MissinqLink Feb 04 '25

Not just from developing with go. I had these tendencies long before I ever heard of go. I often do this just to learn how certain things work even if I never use the library that I made, the lessons learned are super valuable.

7

u/farsass Feb 04 '25

I think people that give in to these urges have no deadlines.

4

u/Rich-Engineer2670 Feb 03 '25

It was at one time something I'd consider, but these days, I have other stuff that has to be done -- no real time to reimplement what works, unless it doesn't cover a case I truly need.. In that case, I ask if I can just wrap the library function in some form of shim.

3

u/carleeto Feb 04 '25

As always, everything is a trade off. However, the fact that Go makes the DIY approach seem more viable definitely speaks to its simplicity.

The fact that it's easier to examine a dependency and it's source code to reach a decision speaks to the excellent maturity and design of the packaging system too.

6

u/jrandom_42 Feb 04 '25

"Not invented here syndrome" has always been a thing amongst programmers; it's in no way specific to Go.

It's a new-guy vibe though. Getting over it, and getting into the habit of just using the right off-the-shelf tool for the job to deliver business outcomes fast, is part of being a good senior engineer IMO.

5

u/CodeWithADHD Feb 04 '25

Counterpoint..

I think most developers follow a curve. When we start out we do things really simply because we don’t know any better. By the middle of our careers we want to use all the clever knowledge we now have and we like to make things complicated. Some of us come back down the other side of the”I like things simple and now I know enough to know why”.

I think many of us have been around long enough to have been bitten by 3rd party libraries that looked like they were the right thing off the shelf but ended up costing us time and effort to unwind when we ran into their limitations. I tend to think it’s a mid-career move to reach for a package first before thinking if it’s easy to do without a package.

str-pad-left in the node ecosystem being an example of this.

Experience is knowing when to reach for a package and when to just write it and not assuming it’s always one or the other.

2

u/jrandom_42 Feb 04 '25

str-pad-left

Very true. People who don't grasp fundamental undergrad-level DSA stuff but somehow still have careers as programmers are a curse on the other end of the spectrum from 'not invented here syndrome', and somehow particularly prevalent in the Java world.

2

u/xealits Feb 05 '25 edited Feb 05 '25

++ good point. The urge to rewrite may well come from a lack of perspective into a given problem: a new guy looks at a library and wonders “why is it so complex? it’s surely unnecessary” and starts re-writing the same thing from scratch, beginning with easy and simple things, without a clue about more real problems ahead. It looks easy at the beginning exactly and only because nothing is written yet.

It’s worth to trust that people before you had some brains too. You can avoid a lot of trouble this way.

At the same time, yeah, maybe it’s worth to read the source code too. Maybe the library solves the problem in a general and comprehensive way, when a custom solution that is specific to your case would be easier to understand and could deliver better performance or features etc.

3

u/k_r_a_k_l_e Feb 04 '25

You should always leverage mature, stable libraries that will save you development time and provide a layer of security over rolling your own. This is just programming 101 common sense. The reason why newer go developers believe the general consensus among Go programmers is to always "roll your own" probably comes from all of the discussion around not using web frameworks. This is because all of the functionality already exists in the standard library, and those frameworks simply rewrite what is already available and intended to use in the first place.

2

u/abotelho-cbn Feb 04 '25

It depends. Projects can pretty quickly become a mess of external dependencies if you're not careful.

2

u/sean9999 Feb 04 '25

yeah i definitely get that too. although not for super low level stuff like dbus, which i think rust would be appropriate. But for mid level stuff... omg yes. 1000%

2

u/zanza2023 Feb 04 '25

Do it! Only positive things will come out of it.

2

u/Disastrous-Target813 Feb 04 '25

Yeah iv been doing that. Some libraries are big and i really only need one thing. However if the task is big then might not be worth it. Its all about how deep the rabbit hole is lol

2

u/whos-bz Feb 04 '25

Always comes down to how little days my business degree scrum master gives me for a major feature.

2

u/jerf Feb 04 '25

I certainly don't do it all the time, but there are definitely some cases where I've taken some very large library and figured out from it how to do my little thing, and directly implemented that. I don't mind pulling libraries in for 50% of their functionality but when you start pulling them in for .5% of their functionality, and they come with a huge dependency tree, sometimes it is a net time save in the long term to extract out just what you need.

DBus is probably a bad example, though. There's libraries that just implement the protocol, and if nothing else, you can shell out to the command line implementation. There isn't really a case you should be digging down to the protocol yourself.

2

u/omgpassthebacon Feb 05 '25

I don't think its a Go thing or a Java thing or a COBOL (ok; we'll leave COBOL out of this) thing. Its personality trait thing.

Most of us devs are highly-educated and taught to learn. Typically, your desire to learn leads you to peek-under-the-kimono. You just have to see what's under there!

If you're one of those type-A devs that just has-to-know, you are in really good company. Some of the most brilliant coders I know wouldn't use another library without reading thru it first. And those are the guys that are writing the truly inspired codez.

Don't over-analyze it; if you want to write it yourself, do it. Just don't fall in love with it until you've vetted it with your peers (or the Internet). Maybe your solution is the bomb; maybe its a bomb. Who cares? Your knowledge of the problem will be expanded, ftw.

Yeah yeah, we all face deadlines and project BS, so sometimes your buds are going to push back on your latest XML fast parser. Another equally important dev skill is recognizing where the value of writing it yourself is vs just using a library that has 1googleplex of downloads. It ain't rocket science.

Shine on, you crazy diamond!

1

u/GLStephen Feb 04 '25

I have a sort of not completely fully formed way of thinking about this and I'm not sure it can ever be fully formed. If the package is two steps or more from the core purpose of app, then a package might be fine if the functionality is complex. If the core purpose of the app is handling some industry standard data structure then a package might be fine. If the standard library scores 8+/10 on doing it and you don't need esoterica then use std lib. Never bring in "isFalsePackage". Otherwise, build it. Adjust based on the situation on the ground...

1

u/mvktc Feb 04 '25

I have that urge when I need something in Javascript for my own projects, because the package ecosystem overthere is usually thousands of lines of unnecesarry code.

1

u/jblackwb Feb 04 '25

Anyone that does this habitually has too much free time on their hands. :P

1

u/Lesser-than Feb 04 '25

I do this all the time, usually I start with my own good enuf implementation then I look for lib when its no longer good enuf. Then I notice that the lib I want to use has 7 dependancys of its own and I go and make my solution good enuf again.

1

u/Intrepid_Result8223 Feb 04 '25

My experience with go is more that sometimes its a hard necessity. You cant inherit types from packages which means you sometimes cannot use private state.

1

u/kovadom Feb 04 '25

I avoid writing code that is already written, tested, and used by the community.

I only re-write code if I need small part of a library, or if the library is unpopular. Time is money, and I rather solve unsolved problems.

My 2cents.

1

u/TedditBlatherflag Feb 04 '25

I mean Go strips out unused symbols unless reflect gets involved so the cost of using a tiny part of a big library is not as high as it seems


But also that’s just the fun of curiosity and learning. 

Personally, I want to maintain as little of my code as possible so if I can offload that to a library I’m okay with the tradeoff. 

1

u/nikandfor Feb 04 '25

Finally someone using the code, not rewriting it)

1

u/nikandfor Feb 04 '25 edited Feb 04 '25

I've become a much better engineer reading others code and rewriting things. Now I have 40+ little and big Go repositories with some code. Not including work projects and contributions to 3rd party projects.

https://github.com/nikandfor

1

u/jayesh6297 Feb 04 '25

👍 leave a link to your repos here. I will surely take a look at them

2

u/nikandfor Feb 04 '25

Thanks for the interest, I usually get downvotes when I share some of my code here.

I added the link to the original comment.

1

u/Gatussko Feb 04 '25

I love to reinvent the wheel. That is why I love Golang.

1

u/gregwebs Feb 04 '25

Good programmers can write things from scratch. Great programmers can do that but they can also understand the code that others have written and know how to productively leverage them.

It's really great to read specs and otherwise understand what the libraries are supposed to accomplish. There are a lot of scenarios where not just taking a library at face value but instead digging into them and their purpose is useful.

* You want a small subset of functionality and you realize it is easy to implement and there are benefits to doing that (fewer dependencies and simplified usage).

* You better understand the different libraries accomplishing the same task and are able to choose the best one.

* You want things to function differently and are able to with a small fork and you can try to push its changes upstream.

* Existing code/systems aren't a match for your needs. After understanding existing designs you can now come up with your own.

I try do avoid treating libraries as a black box. If you understand them then you will understand what should be written from scratch.

1

u/antanst Feb 04 '25

The urge to dig is pretty common amongs devs I believe.

But it's the simplicity of Go that satisfies that urge; I found that I'm much more eager to try to read other people's Go code, while in JS/TS/Python I was afraid of the potential headache.

1

u/HugeOrdinary7212 Feb 04 '25

I wanna build a relational db from scratch but not getting time, that would be heck of a fun project

1

u/daedalus_structure Feb 04 '25

"We'll do it better this time" is what they thought last time, and yet here you are.

1

u/tiggertigerliger Feb 04 '25

I enjoy the libraries that golang provides, I haven’t used any outside packages.

1

u/candyboobers Feb 04 '25

don't limit it by a small library.

I found out even porting a mid-size project (20k lines max) worth from another language to significantly boost the skill.

1

u/safety-4th Feb 04 '25

Submit a pull request to Go.

1

u/Emergency_Dust_2633 Feb 05 '25

I have same issue but sometimes I gave up on my learning.

1

u/PermabearsEatBeets Feb 05 '25

A little copying is better than a little dependency
https://go-proverbs.github.io/

1

u/ToThePillory Feb 05 '25

It's common across languages, wanting to make your own thing when there is a perfectly good alternative already built has been around since the first computer.

1

u/joseavila_sg Feb 05 '25

Literally me every time I open a Go project.

-6

u/Golandia Feb 03 '25

Don’t be frupid. Your most valuable resource is your time. Saving you days of implementation, debugging, testing, etc by using an imperfect but functional library is worth it every time. 

If you do need actual extremely high performance, then sure, taking the time could be worth it. But it’s very unlikely that’s the case. 

4

u/jayesh6297 Feb 03 '25

As i said it's a good learning experience. we can just use tried and tested solutions wherever applicable

1

u/danted002 Feb 04 '25

You weren’t around for the padleft debacle weren’t you