[rglullis]

> "If I don't know this tech stack, what do I do?"

If you don't know how to use a tool that does one job, either you learn it or you just delegate that job to someone who knows it already. But defending the practice of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".

[lelanthran]

> If you don't know how to use a tool that does one job, either you learn it or you just delegate that job to someone who knows it already.

How is that different from "If you don't know how to use the tool (Go), either you learn it or you just delegate that job to someone who knows it."?

> But defending the practice

Woah there cowboy, I wasn't advocating an architectural decision suitable for a FAANG. I was "defending" the position of "why you an extra tool for this one program that has no other dependencies?"

> of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".

In much the same vein, switching to Ansible, Fabric, etc simply to install a single binary to a single place smells a lot like "resume-driven-development".

[pdimitar]

You are being needlessly picky here, Golang is in fact a very viable replacement for both sh/bash/zsh and Python scripts, it compiles to a single static binary, can be cross-compiled to every supported OS on another host, and is thus easy to distribute.

I already started replacing parts of my shell scripts with Golang programs and the experience is miles ahead.

And if the project is already written in Golang, it makes even more sense if the dev is also partially the DevOps. Why wouldn't they make the experience as seamless as possible for themselves and the rest of the dev team? What good would Ansible do if everyone has to yet learn it?

As for the person you originally replied to, I'd definitely make a separate program that provides tooling related to the main program... but that's the only different thing I'd do.

Your snarky "coders gonna code" comment is detached from reality, we have jobs to do, and within deadlines.

[rglullis]

> it compiles to a single static binary, can be cross-compiled to every supported OS on another host, and is thus easy to distribute.

You could say the same thing about Java or C++. Would you argue then that the best way to deploy java applications is by writing a java library and embed into your program?

> if the project is already written in Golang, it makes even more sense if the dev is also partially the DevOps.

I really don't see how that one follows from the other, and I really don't understand this conflation between roles and tooling. There is a lot more to "DevOps" than packaging/distributing/deploying. It's not just because your application code is in Go that your tooling needs to be as well.

> Why wouldn't they make the experience as seamless as possible for themselves and the rest of the dev team?

Because it's a fragile solution. You are tying the implementation of your problem to a very narrow space out of immediate convenience. I've had my share of projects with "experienced" node.js developers who are trying to do everything in node instead of reaching out of their comfort zone and looking for existing solutions elsewhere.

> we have jobs to do, and within deadlines.

Yeah, and a lot of those jobs could have been made in a fraction of the time if the developers were not trying to use their screwdrivers as hammers, and put some effort to figure out how to use the hammer in the first place.

[pdimitar]

> Yeah, and a lot of those jobs could have been made in a fraction of the time if the developers were not trying to use their screwdrivers as hammers

Did you deliberately ignore the part when I asked why would a team of devs learn Ansible if they don't know it? No, it's not fraction of the time at all, in fact it might balloon to weeks in the ideal bad conditions.

Most people would opt for something they already know and that's a fact of life. Learning Ansible or Fabric on-demand is not exactly an optimal expenditure of time and energy, not to mention that a proper DevOps professional would know various gotchas that a learning dev will absolutely miss. Sure the dev will EVENTUALLY get there. "Eventually" being the key word. Why risk botching stuff in the meantime?

> Because it's a fragile solution

Says you. I do Rust scripting in my Rust projects, Golang scripting in my Golang projects, and Elixir scripting in the Elixir ones. Works really well. Not necessarily for deploying and DevOps work, mind you, but for a lot of stuff like "populate me this sample data so I can experiment with the app" or "start only these parts of our app so we can do an integration test with them after" etc.

I also did part of the deployment actions, not all though, if that makes a difference. I don't know the exact situation of the person you replied to.

> You could say the same thing about Java or C++

Huge, huge disagree here, probably the biggest I ever expressed on HN. :D

So many environment variables, compiler switches, and various runtime dependencies and so many other things that it's not even worth starting, it can fill up a PhD thesis and have room for more after.

Your statement cannot be more wrong if it tried. I have several serious objections to the Golang the language that prevent me from adopting it as a main career choice -- but its portability and distribute-friendliness are one of the best in the world right now. You can criticize it for a lot but criticizing it for these two things would be severely uninformed.

> I really don't see how that one follows from the other, and I really don't understand this conflation between roles and tooling. There is a lot more to "DevOps" than packaging/distributing/deploying. It's not just because your application code is in Go that your tooling needs to be as well.

Sure there's more to DevOps, I agree, but I was under the impression that the guy you replied to was tasked with doing part of DevOps so he found a way of doing it with less friction.

Conflation between roles and tooling is unfortunate indeed and I sympathize with your statement there. It's simply an artifact of imperfect work conditions (so 99.999% of all work places).

I can relate to your frustration about non-optimal processes but you are overreacting a bit.

Can their homegrown solution backfire? Absolutely, of course it can. But often times we have to make do with what we have right now and can't optimize for the far future.

If a DevOps wants to pick up the torch and do the job properly they are free to do so but yet again, I was under the impression that the person in question was wearing several role hats at the time.

[rglullis]

> "populate me this sample data so I can experiment with the app"

Which is well within the role of the developer. "Deploy to Hetzner" is not.

> I was under the impression that the person in question was wearing several role hats at the time.

Sure, I also have to do everything on my own in my own projects. But again, the function determines the tool, not the person performing the job. When I'm wearing my application developer hat, you'll see try to do as much as possible with Python, but that doesn't mean that I will try to turn every problem into a python script.

[pdimitar]

> Which is well within the role of the developer. "Deploy to Hetzner" is not.

Well, OK, I can't argue with that as much. Maybe the guy truly found it easier to do so? No clue. I know I'd definitely try with a shell script, then with the project's language, and only then with a dedicated tool. As much as I try to be a good senior backend dev -- and I know a lot of stuff and tooling that are not at all mandatory for my role -- I still can't find the time and energy to become a properly good DevOps; too much investment, and for specific cloud platforms. To this day I can't justify it and can't make myself "git gud" with AWS.

> When I'm wearing my application developer hat, you'll see try to do as much as possible with Python, but that doesn't mean that I will try to turn every problem into a python script.

No you really should not, Python is a nightmare in portability. I can trivially use venv-s and other tooling to make sure stuff is isolated and works fine but the whole house of cards is still always just one `brew upgrade` command away from falling apart. Eventually I've given up. If Python can't be trivially made portable then it's a bad tool for scripting, no matter what many people think and say (in fact, a lot of people using a tool often times speaks badly for its quality; to me "Python is good" is a mass delusion but that's a huge topic in itself that I won't tackle here). The fact that many people don't know anything else but Python is not an excuse.

Golang is a much better choice for quick scripting and that's a demonstrable fact. You can parse CLI flags and use their values and even throw some validation is some 10-15 coding lines and from then on you can use various super-useful libraries; there even exist a few that emulate a number of UNIX tools so you can still have a single binary that can do a lot without depending on anything except a kernel being present in the system (which also makes the resulting binary very convenient in constrained / container environments).

You might think I am getting hung up on details but I felt that I have to debunk the idea that Python is a good scripting tool. No it really isn't, and most Python devs never test on a random Mac or Linux machine where the dev is NOT using Python as a primary language. It's a fragile mess.

But now we're arguing in circles about familiarity. :) I recognize the irony. But for what it's worth, I didn't know Golang and made it a goal to learn it long time ago because I liked its distribution story and (mostly) ease of use (with a bunch of caveats nowadays, sadly).