Would you be annoyed if an automation was written in go

[-]

MasterSea8231@reddit (OP)

I’m a solo sys admin so the question was more about if i left and someone was hired behind me i don’t want to make someone life harder than it needs to be

[-]

i_hate_cars_fuck_you@reddit

I guess in that case I'd be asking myself what the skill level of your replacement or underlings would be.

Documentation will always be more important than the language of choice anyways. Powershell or Bash is always the most common language, but you mentioned portability so I'm assuming those aren't good options for you. If that's the case, then it's all about documentation, because even if you choose something more well known like python you're in dependency hell at some point.

[-]

gordonv@reddit

What happens if the code has a flaw and needs rework?

If you can fix it in a reasonable amount of time and deploy it to the users, then you've resolved the issue.

If this is a "tape and bubblegum" solution that will break and leave users and the process stranded, then that's a big no.

That's the only real concern. When it breaks, how does it get fixed. Who is fixing it? How long will it take? How do you deploy the solution? A few good setups have an answer for all these questions. The majority of businesses don't have this simple level of foresight.

[-]

1hamcakes@reddit

Go is excellent. I wish more systems automation used Go.

It's one of my goals for 2025 to become proficient with Go.

[-]

gordonv@reddit

Are you the only person that can use XYZ language in your environment? If so, then yes, I would be highly annoyed and would move to reject your code. Merely because no one else can work with it.

Nothing against GO from a technical standpoint. And I don't mind if you use it to automate your own private tasks you maintain for yourself. As soon as your tool becomes public facing, you being the only person with a handle on it becomes a problem.

[-]

degoba@reddit

It depends on the environment. There are so many languages in use at my work nothing really phases me anymore.

[-]

pdp10@reddit

Better than most languages, particularly for the runtime dependencies.

There will always be situations where a language is not a great choice. Executable size could be an issue in embedded applications, for example. Your debugger needs to know the Go ABI.

[-]

picklednull@reddit

The bus factor is a relevant consideration. How many other people can maintain what you write? I can’t even get people who can write proper PowerShell, so something like Python or Go is a real stretch.

Beyond that, generally speaking, for sysadmin type automations, something like standard shell / PowerShell / Python is better because they’re interpreted and built-in to the platforms.

And I say that as a Go user.

[-]

SeaFaringPig@reddit

Use COBOL like a real man.

[-]

TheFluffiestRedditor@reddit

I’ll take your Cobol and raise you Perl.

[-]

SeaFaringPig@reddit

NEWB!!! Everyone know Perl.

[-]

Newbosterone@reddit

Nah, PL-1. Program Language One, who needs anything else?

[-]

dodexahedron@reddit

It has a 1 in its name. Therefore, it must either be the first one or the best one.

Q.E.D.

Sign me TF up!

[-]

InfraScaler@reddit

But we started with zero!

[-]

bgatesIT@reddit

i tend to write automations in python but have been liking go more and more, notably for the portability also. Granted all of my automations get pushed to a Kubernetes cluster to be managed and orchestrated, so there all pretty easy to implement.

[-]

Select-Cycle8084@reddit

I'm probably just not reusing someone else's automation scripts if I'm taking over their position.

[-]

ABotelho23@reddit

Huh? Do you have any idea how much infrastructure glue we wrote? That would be totally mental.

[-]

Select-Cycle8084@reddit

He specifically said take over for him. If it was a team dynamic that is different, I'm not blindly running scripts left over from a predecessor without a full review of them, at which point it would likely take less time to do the tasks or automate it myself.

[-]

Krigen89@reddit

Everyone should always start over?

Sounds like a waste of time and ressources. If the automations work and are well documented, I don't see the problem.

[-]

SevaraB@reddit

I want to write it in GO because I like the portability of the executable.

I'm not married to any particular language for the same reason I don't love this statement.

Automation = tooling. Tooling is heavily circumstantial- you build tooling that makes sense for the given environment.

There's still room for personal preference, but if you aren't leading off with "what are the requirements in this environment?" you're not starting your build process from a good place.

Without more context, this statement boils down to a solution in search of a problem.

[-]

Head-Sick@reddit

No, go is a fine language. If you have proper documentation then I'd be fine with it. I don't know a ton of go, but I'd personally view it as a great chance to learn more as well.

Also I like the little gopher guy.

[-]

tankerkiller125real@reddit

The only reason I would mind where I work is because the company standard is PowerShell/.NET (Core) but I wouldn't mind otherwise. As someone now responsible for maintaining an open-source project written in Go with zero prior experience I've found the language to be mostly easy to learn (although there are some weird things with it specifically when working with bytes, but that's me)

[-]

coomzee@reddit

I would do a security consideration before starting.

[-]

RoomyRoots@reddit

No, Go was created exactly to do that.

[-]

dodexahedron@reddit

If the environment, team, company, etc already makes use of Go as standard practice, no - I'd be perfectly fine with it.

If it's because you prefer to use Go, but everything else or the majority of everything else is in not-Go, then yes - I'd be very annoyed and push back on it in pretty clear terms.

Those terms being "no." Because I'm the boss. 😅

[-]

chilli_cat@reddit

So go no-go

[-]

dustojnikhummer@reddit

I like Powershell (except for the code signing bs), colleagues use Python etc.

Doesn't matter as long as it is documented (insert joke about "what documentation") and is clean enough to be maintained by others.

Of course, as long as the runtime is reasonable.

[-]

CraigAT@reddit

I don't think I would be annoyed, but if it was in a Windows environment I'd probably question why it wasn't done in PowerShell.

Does anyone else in the team use Go? If not, could you teach someone to debug your source code and recompile your program within your notice preiod?

I have programmed in several languages, so whilst I am not familiar with Go, I could probably pick it up fairly quickly. However the majority of my team would probably struggle and just abandon the "tool" if it broke.

As well as making your source code available and documenting the program, could you also document the tasks your program does and the existing manual process - to serve as a fallback, should your program no longer work or for someone to re-automate the process in an other tool.

[-]

-happycow-@reddit

Go is a good language. There is some of the ecosystem that takes some time getting used to and understanding. But you cannot complain about the speed, and/or the language's utility.

One bad thing, naturally is the compiled nature of the language - don't know about modern go, maybe there is a JIT way of doing it similar to Roslyn compiler for C# ... Not sure that ever turned out a good project

Anyway -- many good tools are Go, and it makes sense.

BUT, build a support group around you -- don't just go it alone -- you will make people dislike you. Don't do that to yourself if you can spend a bit more time, and create a support team first.

[-]

ThinkMarket7640@reddit

For interpreted languages you need to install the runtime anyway, with go you can achieve the same thing using ‘go run’.

[-]

-happycow-@reddit

There are always pros and cons. It’s not a right or wrong situation. It’s a discussion that has to happen around the specific usage and performance needs and the skill sets available and a group of other concerns.

[-]

MasterSea8231@reddit (OP)

What do you mean by support group?

I’m not sure if there is anyone that could help support me even if they could. I’m like 1 of 2 people that can code in the department. I would love a support group but I’m not sure that is feasible in my company

[-]

chesser45@reddit

If no one else is interested in the code please make it readable and not obscure for the sake of optimization.

[-]

MasterSea8231@reddit (OP)

I try my best to make my code readable. I’m already writing in a compiled language so i figure that’s good enough for optimization

[-]

Inevitable-Course-88@reddit

While go doesn’t have a JIT or interpreter, it has a command go run filename.go that quickly compiles and runs the “script” without leaving behind an executable

[-]

mwenechanga@reddit

Don’t just GO it alone! Eh? Eh? Alright, I’ll stop.

[-]

AdministrativeFile78@reddit

It doesn't take much to annoy me. But no, i like go

[-]

mkosmo@reddit

Go isn't used for any other automation in the company, nor is it on the roadmap for any automation... so I wouldn't sign of on the addition of a new tool with a limited support system and less skillset.

But that's not to say your shop wouldn't. You need to talk to leadership to determine whether it's something they're willing to support... and whether or not the company wants to onboard go and the relevant toolchains.

[-]

unethicalposter@reddit

Golang is a great choice it can do a ton.

[-]

Nietechz@reddit

Personally, I won't care, but I really think it's better to use the native tools for automation. Windows? Powershell. Linux? Bash

Something cross platform, probably Python that most folks know.

[-]

TerrificVixen5693@reddit

Nope. Language is but a tool, and if it’s your project and I want to use this over python or bash, I’m all in, as long as it’s readable.

[-]

reubendevries@reddit

Go is pretty damn readable- I’m not suggesting it doesn’t have warts (cause it does, as do all other programming languages) - but readability shouldn’t be a problem. The issue I think is probably the fact that what they are building needs to be compiled first before using, which means you need to compile after making a change.

[-]

samon33@reddit

If Go is the right tool for the job, and a language that the rest of the team agree on etc, then "go" for it.

But it really depends on what you are automating - for example if you're working with M365, then just stick with PowerShell, because that's what 99% of the documentation, blog posts, etc will be about and what other sysadmins will be familiar with. Not to mention that while 90% of the M365 world can be managed using the Graph API from whatever client/language you like, there's still a small 10% (or whatever) part that is only possible via PowerShell, so you then end up with a split workflow.

There's also a lot to be said for the overly-verbose PowerShell syntax (assuming you don't go all CLI on shorthand) in terms of readability and comprehension by technically concluded but non-coder colleagues. At a previous job I wrote hundreds of thousands of lines of PowerShell, and while there were a number of people in the team who couldn't write code to save their life beyond copy/pasting from the interwebs or vibe-coding with ChatGPT, they could usually still read through a script and understand what it would do if they executed it, which was important.

[-]

Phate1989@reddit

I work with graph in python almost exclusively.

I deal with tenants that have 30k entra users and even more groups.

I dont know how anyone works with large datasets in powershell.

Almost all my calls are async, which is challenging enough but in powershell its excruciating.

I only use pwsh when I know the sys admins might have to interact with my code.

[-]

uptimefordays@reddit

Go, Python, Ruby, PowerShell—I don’t care as long as you follow the style guide, document logic, and use version control.

[-]

dodexahedron@reddit

document

Whelp... There goes 90% of everything ever written out there. 😩

[-]

uptimefordays@reddit

“Who needs all these comments?” People who can’t understand their own code 6 months later.

[-]

Icy_Party954@reddit

Depends on what it is. If its mostly stringing together shell calls. Yeah just go with a shell language. If its not python is probably better, just because of its nature, a true scripting language, common etc.

Nothing against go just my two sense. Sees to me as being more complex just for fun, which I get the temptation, but Ive wrote shell scripts when yeah C# or Java, id have preferred but the shell scripts were the language of the area so that's what I wrote

[-]

Smith6612@reddit

I have never cared for the language as long as things are documented, the code is clean, and the selection of language was done with the best intentions.

[-]

simpleittools@reddit

Go is my primary language. I would be thrilled.

[-]

EchoPhi@reddit

How would you feel walking into an environment based on powershell, mysql, postgresql, cmd, c+, c#, python cobal, cold fusion, excel?

It's all the same wrapped differently. It's why we have jobs. Enjoy go!

[-]

elatllat@reddit

GoLang is memory-safe which is good, but if the automation is mostly calling other tools via shell (or any non-lib way) then a shell script seems more fitting/native. On the other hand shell scripts can be the wrong choice sometimes due to speed or complexity.

[-]

BlackV@reddit

is it just you that knows GO, then NO!
when you get hit by a bus, what happens then ?

but it kinda depends what you're automating and where

is it go vs powershell? is it go vs python? is it go vs c/+/#?

that aside no I wouldn't have a problem with it as such

[-]

MedicatedDeveloper@reddit

Depends what is being automated.

[-]

ManyInterests@reddit

Do you work with other engineers who know Go? If you were the only person who knew Go or wanted to use Go, yeah, I'd be pretty annoyed.

As an engineer that does know Go, it wouldn't be my first choice, but sure, why not. We do some things in Go... mostly Terraform providers and such. But otherwise, Python (for our internal use or backend services) or Rust for CLIs and distributed binaries.

[-]

knightofargh@reddit

Are you going to comment and document it?

Then fine.

But don’t ask sysadmins to willingly fix your Go for you.

[-]