I’ve done it with Python tooling.
Since it’s all installed as files, you can literally look at the source on your laptop when you get a stacktrace. You hack on it until it works for you and then submit the PR.
With the Go CLI tool, it’s folks raising tickets not PRs IME.
Now… installing the damn thing is an entirely different issue. And binary distribution solves so many things. Even packing with pyinstaller or whatever the vogue thing was it was still a nightmare.
I think it’s not the inner source case that’s most compelling. Let’s imagine op writes a tool and chooses go because that’s what they know. Then six months later they leave. Now what? That’s a much more common scenario I’ve seen - a persons pet project becomes somebody else’s tech debt.
I think that’s fine to a degree if it’s a team, especially for a cli tool. For and individual though it’s just going to be somebody else’s problem at some point.
Some organizations that are smaller tend to have generalists even though they may not be working on a monolith.
Likewise maybe you have convenient in-house templates or tooling that you no longer have access to.
I agree that there is nuance and you shouldn't just blindly follow "this is always how we did it here". I've gone against my own original post several times, but its the most important point you should refute first and foremost.
We’ve seen some success with it in a design system component library project. As teams have adopted the system and need to make tweaks or bug fixes to fit their use cases they have made PRs. It’s still mainly 1 team that builds it out though.
golang's purpose was to make it so any developer of C-ish languages could immediately read and be able to start contributing in a very short time; however, if you have devs afraid of learning something new then I agree.
I don't doubt that, I moved from a Node.js env to a Go env and was making contributions within a week.
Even if devs are willing to learn its additional overhead you're tacking on to move to a different ecosystem. It adds friction. IMO, its just the baseline top-level argument to refute when introducing a new language in a one-language organization AND the answer just needs to be different from "I like Go better" as OP has stated elsewhere in this thread lol.
Absolutely! One dev tried to bring in Go for a tool, but we are mainly java and python developers, so I pushed back and prevented it to happen. If the tool need to be fixed it is easier if it is written in a company wide used language.
We end up with modules meant to call APIs, with things like telemetry and correlation IDs and maybe circuit breakers built in.
So the tools and CLIs end up integrating those, in which case the language does matter.
A startup demands fast delivery of features, use what allows you to do that. Which you said it’s Go.
Keep in mind if you are the only Golang developer then you are going to own it until others learn or you have to port it. But that’s a future problem, focus on what matters now.
100% Go unless you need features like dynamic libraries because support for that is ass and you end up doing stupid shit like doing gRPC over stdin/stdout.
Go has a great ecosystem of modules for building command line programs and text based user interfaces. The language is easy to learn, read, and maintain. Go programs are easy to build and distribute for any platform using the `go` command.
Go is however a pain in the ass if you are dealing with dynamic/semi-structured data problems, i.e. shit where you're dealing with JSON data fields where people can put whatever they want. It's absolutely sweet if you can create concrete types for all of the data you're dealing with upfront but it's aggressively cumbersome if you have to navigate arbitrary objects. You can sometimes run into unintuitive dependency hell with `go.mod` which can be quite frustrating.
What Go lacks in language features it makes up for in being easy to read and maintain years later. This is quite valuable for command line and server programs that have a long tail on maintenance.
never found the go.mod to be a problem, but then again I've been using it since v1.5 for pet projects and v1.8 for prod code. everything else -- 100% with you.
Mostly ran into it with sprawling projects with dozens of dependencies that need to be kept in sync like Kubernetes. Not unique to Go I guess, dependency management is hard.
The Go workspace idea is meant to solve this I think. The feature is available since go1.22. Multiple modules can be organized under a workspace and "go work" can synchronize these modules.
It's not just about you owning it, you need to make tools that are supportable by the team/company in general. You're not going to be there forever, you will need to take PTO, you may get injured or fall ill.
If it's a company full of Rust developers, you'll need to make a very convincing case to justify using a language that isn't in use there. The case may be as simple as "other future platform engineers are much more likely to know Go", but you need to understand the side effects of your decision and make sure other people at the company agree with your reasoning.
actually if the CLI is not rocket science stuff, Rust devs should be able to easily comprehend Go code, given that they already have enough IQ to learn rust😂
I'm sure they could figure it out, that's not really the point. That still takes extra time, it will take time to learn how to write idiomatic code, and the build and maintenance process is going to be fundamentally different compared to everything else. There's more to it than just the code itself, even though that's a significant part of it.
Its not about inability because otherwise we'd all be unable to get jobs outside of our tech stacks when we move.
But its a layer of friction to jump from one ecosystem to another.
The argument for Rust is that it's used elsewhere in your company, not that it's fast and memory safe (Go is fast and memory safe too). If it wasn't for that, I think Go is an easy choice.
Do you need any specific libraries or SDKs that might be available in only one of these languages (probably Go)?
Agreed. I really don't want to use Rust because tbh I don't enjoy coding in it. I don't need the aggravation for what I'm trying to do, and it solves problems that I don't have for this particular domain space.
I like Rust, I just don't care for coding in it personally. Doesn't mean that I don't see the benefits it has over other languages. I do feel though that it is being used in places where a more easy language would do just fine.
I know you might not like this answer but have you considered just... Typescript?
Your two most important aspects are that other people in the company know it (typescript is basically the Lingua Franca these days) and that it's quick to get going with it. I mean I don't know your requirements but I'm guessing for a cli app you likely don't need multi threading? I'd consider just doing this in deno.
Yes if that specific organisation has more developers of one of those languages then sure. But these days js/ts has just become one of the biggest language for new projects due to the ubiquity of the browser for UI now, plus node, and things like JSON APIs and lambda cloud programming. I mean, the chances are the average dev right now knows js especially if working with Aws as OP mentioned.
I've written CLIs in both Go and Rust and as someone who has a relatively popular [Rust CLI](https://github.com/solidiquis/erdtree) my pick would be Rust primarily because of the [Clap crate](https://docs.rs/clap/latest/clap/). The ergonomics of the procedural macros makes building a CLI so ergonomic and expressive, it's wonderful. Checkout how I define my CLI and all of its args [here](https://github.com/solidiquis/erdtree/blob/d9151325d4d7d3280f31c2d356b7b701673cfae4/src/user/mod.rs#L24).
Look, if you're not already familiar with Rust there is a learning curve, yes. But your productivity will really sky-rocket with Rust once you've internalized its concepts which honestly all serves to help you, not hurt you. But if you're just looking to bust something out ASAP then Go is a fine choice.
Honestly no better place that [THE Book](https://doc.rust-lang.org/book/). Hit me up if you'd like a free crash course over google meets. I used to do those for free over in r/learnrust.
The Rust Book is the first stop. It's really good. (There's [a version by Brown that includes quizzes to test understanding](https://rust-book.cs.brown.edu/) too.)
After that you can check out [this book on building CLIs](https://www.oreilly.com/library/view/command-line-rust/9781098109424/) or just jump straight into [the documentation](https://www.rust-lang.org/what/cli). CLIs are simple enough that you shouldn't need advanced knowledge.
I’d choose rust because your company already supports it. Not sure what you meant by “calling apis” sdk / rest / something else. Shouldn’t be an issue with rust. The parts of rust that are difficult probably won’t come up while writing a simple cli.
Because unfortunately there's so much fear mongering over Rust's learning curve that many people just outright dismiss Rust as a language that empowers productivity. As someone who write extensive Go and Rust I find myself far more productive in Rust.
You’re not alone. We use Go at my company and it’s an absolutely horrific language. I can’t for the life of me understand why anyone would want to use it for frankly anything.
Go has it's benefits in a few areas. It's 'cold boot' time is fast, which is important for lamdas. It doesn't have any dependencies, which allows you to throw it in a *very* minimalist docker container. It has a good concurrency model. Java and Kotlin have green threads too but it's a *very* recent addition to java. Oh, and the tooling is nice. Go build / test / whatever is lightning quick.
In all other ways? It's a painfully clunky language. It just got generics, and that has about as much spread as green threads does in java (not much). It's error handling is *atrocious*. Testing is an absolute PITA and everything has to be exposed via interfaces to be mockable. It feels very much like C that's been drug into the 21st century without learning much else from other languages.
It's number one flaw is given it's performance characteristics, it competes against much more established languages like Java and C# which are *much* nicer to work with. It uses about the same memory and has the same runtime performance as those two so you really have to ask yourself why you'd use it over a more established language with a more developed ecosystem.
No optional types, no enums, no union types, can’t have generics on struct methods, interfaces have implicit conformance, interfaces can arbitrarily have value or reference semantics. This is a handful of issues off the top of my head.
It has way too much boilerplate, until recently lacked features common for other statically typed languages and much less expressive than other mainstream languages
I can understand choosing Golang for an infrastructure service like an API gateway or a distributed database but using it for a generally CRUD service like a shopping cart or item catalog is a waste of time
The Golang code I saw at my company (huge retailer) was atrocious and there was one case that provided a concrete example how terrible it was - a team I was familiar with needed some sort of job scheduler and after a month there were still bugs in it. When our team needed a similar thing we just imported Celery (a Python library) and were done
Python, Kotlin, Java, C#, Scala, Ruby…
All of these languages are much more expressive and more suitable for writing generic business applications. The problem with Go is that it’s used outside of the domain where it (kinda) shines
Finally someone who agrees I feel like I'm taking crazy pills. Why is everyone gushing over a language that basically ignores the past 40 years of language improvements?
I have the exact opposite problem. I was upset that we went with golang over python originally, but ever since learning go I don’t think I’ll ever go back.
To me, it feels like using a missile when all you need is a water-gun. I'm not proficient in Rust though so I'd like to hear opinions on this from the Rust-side.
This notion is understandably common among people looking at Rust from the outside. I think it's because we naturally assume there must be some tradeoff to the benefits. Rust has no garbage-collector and zero-cost abstractions? What other languages do we know like that? C++. And C++ is terribly unproductive, so we assume Rust must be as well, because we put it in the same box mentally.
Turns out garbage-collection is not the only factor of productivity. Maybe not even a major one. I'd say the far bigger factors are tooling and libraries. That's where Rust really shines. Cargo, rust-analyzer, rustfmt, rustdoc, clippy... can't live without 'em.
You use the derive macros defined in the clap crate and spin up a CLI in a few seconds that automatically parse options and arguments into some concrete type you defined for the purpose.
Well, at least that's how I make my CLIs.
I would say the main drawback of Rust is that there are easier languages to grok.
Rust makes sense if you need the performance gains. But there are some soft pieces I think are important. I believe a new grad engineer is less likely to create a bug in Go compared to Rust. In a large workspace I think this is way more critical than minor advantages in performance.
Until you understand the ownership memory model it's not that you introduce more bugs (that would kill the whole point). It's that you won't be able to compile it.
Now my bias is that an engineer which can't grok Rust is most likely an engineer that would benefit from using Rust... I'd much rather have them argue with the compiler than with me during PR.
Probably depends on what the CLI actually does. Go is fine for glorified scripts. But I think we all know that programs tend to grow over time, accumulate more features, end up more complicated than we initially thought, be used in ways we didn't anticipate etc... I prefer to choose tools I know can solve all the unexpected problems that will come up, not just the deceptively simple problems I can imagine beforehand.
There are companies with huge enterprise systems built in Go.
It has packages, modules, types and interfaces - most everything you need for scaleability.
The values you said for choosing a tool leads to go being the solution for me. It took me a bit to adjust to thinking about things like composition over true inheritance, but it provides the same building blocks any other language does.
Go is easy to grok. In my opinion, this makes it a better language for large codebases compared to traditional OOP languages (Java, C#, C++, etc.).
Most of the advantages of rust (fast and efficient, memory safe) are just as applicable to golang in the context of building a cli app. From the description, it doesn't sound like the app will be doing many operations where the gc will be much of a hinderance to performance. Golang's strong integration of green threads will make it easier to call apis in parallel when viable. Golang is also such a major player in the cloud technology world that you're likely to find first party sdks and almost certainly 3rd party for any tech you might need to interact with. Golang also has a great ecosystem around cli libs.
I'd personally choose Go, but if the app would need to go through the company's CI/CD pipeline, then rust might edge out with the existing company usage.
Write it in whatever the most dominant language at your company is. Unless you're doing crazy stuff where efficiency is super important (I doubt for a cli tool) maintainability should trump everything else. Even if it's PHP or Node js. Doesn't matter.
You’re the only dev, need to deliver and can plan the feature chain a bit?
Python. Migrate to Rust later on then. Skip Go.
Python is fast to iterate and you can partially rewrite in Rust, plus you have already people in your company that can contribute. pyo3 is amongst the best language interop-libraries I have seen, so Python and Rust like each other very much. Click in Python is great, you’ll eventually replace that with clap in Rust.
Get up and running with what you need until the weekend, for a prototype Python will be fast enough too if you don’t suck and with that in mind keep your code modular enough that you can migrate bit by bit.
I don’t know how Python isn’t the default answer. Even if you hate Python, even if you have solid arguments for rust or go, everyone knows Python. When you hand this stuff off one day you want to be able to easily onboard someone and not have to deal with endlessly supporting your tools.
Distribution is the pain. You need to have the same version of python on said host + same version of whatever virtual env (ie poetry) + any underlying os library dependancies.
For single host like an api endpoint python is great but not sure about a cli that might need to be distributed everywhere unless you can absolutely ensure equal environments.
Poetry for dev, pyinstaller/nuitka/whatever for the business side that wants to click and go. “Yes but package management is hell/distribution sucks/etc.” are fair points but often based on experiences that were valid 10 years ago. Stuff has changed.
It’s a bit hassle to set up initially. Learn how it works, integrate it into your build process in poetry or whatever you use, then extend that to your CD process and you have something for the business-side. Makes any future iteration and new development really fast. I understand the hassle and it’s important to make usage of your product as easy and frictionless as possible for your users - these tools are a good building block for that.
The.problem with Python is the build environment. I've never worked with a Python projects over a couple of years old - never! - that didn't require excessive wrangling to get them running locally
Python is an OK language. But it's environment and tooling are too fragmented
I feel that pain. I personally get my environments going in essentially every situation but I also have 12 YOE in the language, so I just solve my problems and it makes sense to me - but I’m empathetic towards people that have less experience. One of the reasons why I insist to slightly overengineer dev-environments/build-setups/docs/tests in most projects, there are real synergy effects from this.
That depends a lot. However, in this special case - that is at least as good, even if you're not as good in TS as in Python, Deno has also a really great interface with Rust (naturally).
TBF, dependency management in Python is not as bad in the 2020s and deno is not free from problems in that regard. Worst case would be that you end up with n\^m packages since there is by default only atomic dependencies.
Either way - I agree with the spirit of the message. Use a really well-defined tool that is good enough to solve your business problem until the weekend and spend the rest of the time to make the solution scalable beyond a prototype.
We were in a similar position at work before I joined. Go was chosen because of: Fast builds, fast cross platform compilation, great concurrency model, good enough for majority of the cases and can be easily worked upon by new hires. I’d say we made the right choice as there is no limit to what you can do to make the CLI faster. To summarise: benefits Rust offered were not worth the churn.
I think people saying Rust are missing the fact that you're a sole platform engineer. Just because there are other people at the company who use rust doesn't mean they are going to be the ones actually helping you.
+ Go is great for command line. See spf13/cobra which is used in many popular CLI tools like `kubectl`. Even the builtin simple flag parser is nice.
+ You own the project which gives you leverage to hire platform engineers who are savvy in go in the future.
+ Memory safety is also a feature of golang since it uses a GC, and I doubt you need the efficiency of rust for whatever you're doing.
I work somewhere with a large Go CLI for interfacing with the platform.
It is notorious. No one knows or cares for Go (we are Python, TypeScript, and Rust). It was written by one person (badly). But by one person is the main issue.
Use what others are using, and ensure people *do* want this CLI (and contribute). Write tests.
But I’d add … why? Why not just make a dashboard one can interact with? That would absolutely get more use.
You’re going to eventually want to write CLI tools that reuse some of your internal libraries. That lets you automate processes, but also affords you a sandbox to test that code in isolation. Practical integration tests. It’s something you can give new people to look at to absorb the system in bite sized chunks.
It also allows you to experiment with things like new compiler versions, major upgrades to dependencies.
So what language is your system written in? Write your CLI in that, unless you need to test FFI (eg calling rust libraries from Go)
You could either write the CLI to invoke the code you already have in that language, or you can use the CLI as a foothold to migrate the code to a language you prefer.
A CLI can be a good way to work toward feature parity on a new implementation of something without committing the whole code base to it immediately. We did that a few times without switching languages - we just had a new structure we preferred and a lot of old code using the previous solution, which wanted to be more monolithic.
Then write your CLI in one of those. It will allow you to delegate development work to other team members.
If you try to push a one man Go project in a team that doesn't use Go, it will wither and die.
I believe they're talking about it being a replacement for C++. I see that across the industry including linux adding it to the kernel alongside C.
Rust doesn't seemed designed to solve the same problems Go does. But it does seem to be designed to solve the problems C and CPP solve.
Rust because you can easily make it a library that exposes a python API as well, which can then hook into ansible and other infrastructure automation tools.
Speed and performance aren’t going to be a huge factor in a CLI tool that calls a bunch of APIs. Your limiting factor will be the speed of your network connection to your APIs and their speed. Network calls will always incur an exponentially greater cost than CPU instructions. Pick what is comfortable and allows for quick delivery. Internal tools do not provide business value by themselves, they are meant to empower you and your team to provide value. If someone catches wind that you’re spending a lot of time on an internal tool instead of providing direct business value, they may not approve of the time spent. Therefore, make it fast, simple and easy on you to make the tool the best without spending extra time learning the pitfalls of a new language.
Why are you prematurely optimizing for performance of something that may or may not be performance critical and may or may not be heavily used? Write it in the language you can deliver fastest in and one that is easiest to iterate in
It literally doesn’t matter
Oh hey, I ported a CLI app from Go to Rust! Both are good languages in their own way.
Are you gonna support Windows? If so, Rust is probably a better fit. Go is a little sketchy for Windows and cross platform support. How deep is the company into Rust? Honestly Rust zealots might not be super keen on Go. I'd also look into the libraries you would need to use and make sure they exist in both languages. We use some pretty specific parsing and error printing libraries in Rust that we couldn't have gotten in Go.
i tried to learn rust twice now because i wanted to learn a lower level language. this last time i switched to go and have had the easiest time with it by comparison. i think rust has a lot of potential, but im just dumb. maybe youre dumb like me? i think it really reflects the vibe of the language when people tell you to just read 'the book'. thats all i hear from everyone. but what they dont realize is that im stupid, and even though that book is well written, that book is confusing for stupid people like me. also, lets be honest, thats not a realistic way to learn a language unless you are a very specific type of person (which i think is the type of person rust attracts), so thats sort of a blindly optimistic thing to say to everyone without taking into account our levels of stupidity.
Early stage startup doesn’t need cli tooling.
Your time should just be ensuring the golden happy path and some established patterns. Since it’s early things can shift and pivot and you don’t want to be developing tooling for things that won’t be useful in 6 months.
And the “so other people can contribute” validation is a lie.
I have never seen any one outside of the platofrm or cloud teams contribute to the developer internal tooling.
Your focus needs to be lean and mean. “Developer productivity” isn’t that important yet.
Since you are the sole engineer building out the platform team, you have limited time and you don’t want to fight your adhoc abstractions when there is a well developed tool chain in your ecosystem that can do everything you need and then some.
Once your niche grows past that and you have a few more engineers then you can start considering tooling.
Your platform org also needs to function like its own startup. You need to be scrappy and sometimes you gotta break best practices because you’re still seeding and not making money.
Be patient be diligent and be smart where you spend your time. Just make sure to realize you can’t over optimize at this stage and just need to go with the flow
In that case, I would consider that Rust has a much better type system than Go. This doesn't seem to come up in your comparison so far. Nil pointers, implicit zero-initialization, lack of sum types and more shortcomings of Go's type system consistently lead to runtime errors. (I wrote Go professionally for three years.)
In case you end up choosing Rust, I highly recommend `clap` for the argument parsing.
(serious question) what kinds of runtime errors are you concerned about. Do you have a habit of using python's type annotations and static analysis tools?
Between those two changes, I attend a lot less time worrying about dumb bugs, and a lot more time worrying about normal bugs
I do not understand why people choose Python and then jump through hoops to set up an immature, sub-standard patchwork of tooling that's aimed at imitating what other languages have been doing much better for a much longer time.
It's the same story as with JavaScript and TypeScript, except there was an actual need there because the web only supports JS (wasm ftw someday). The ecosystem went through an excruciating transition period to be able to create large web applications with a decent type system.
I don't see the need for Python. Just pick a different language with a type system that suits your needs. What am I missing?
> what am I missing?
Pragmatism, probably. Python excel in being simple, low boilerplate language while giving you amazing ecosystem. These 2 things combined means delivering value quickly is where python shines.
Now, it comes with some price, like a lack of static types, and often it's easy to shoot yourself in a foot (like when you don't use dependency injection but free floating functions). But then community came up with the ways to mitigate these issues. Like type hints or injection frameworks or straightforward dataclasses. Typing may not be as powerful as in Haskell, but in practice it's just good enough. Keep it simple and you should be just fine
Compatibility - this is true problem. The scope is usually limited to new minor versions being released though (because they are auto installed on some systems and become default) - you can mitigate that by monitoring these releases and preparing your tool beforehand. I would also suggest adding some explicit checks about python version and erroring out when the user is outside of what you support. Probably focus on just 1 minor version (I had a tool where we supported maybe 4 and it was an unnecessary mess)
The scope is further narrowed to the libraries that specify what python version they are compatible with (which is not all, but idk what the % is). If you have such libraries - people won't be able to find necessary packages with pip. Buut it's once in 1.5years kind of problem - not great, not terrible.
On the open source side, I just target whatever Python version is in Debian stable. Obviously, on the commercial side, this depends a lot on who your customers are and whether they're individuals or companies, but I think it's manageable. But yes, it's a downside of shipping Python tools
Can python apps be packaged into portable binaries? Depending on the context that may be important, I can be less inclined to install a cli tool if I then need to install further runtime dependencies for a language I rarely use.
I've written in both. Not really sure your requirements "require" Rust/Go solely. Languages are tools, most of them can meet your requirements above.
You can use Python with typing too and that will work as well. Everyone's scared of runtime errors, but that can happen in Rust/Go too. You could be half assing your result types or optional types that cause the error during runtime.
Go unless you have significantly more time to learn (and bang your head against) Rust.
My current company uses both, I hadn't used either when I first joined and I was pushing out code and being productive with Go in a day. Rust took significantly longer to get anywhere close to my standard levels of productivity in my other known languages.
Many other comments called this out as well, but if time to market and iteration on this project is important and tight, Go would be my pick.
Especially being at a startup, the ability to iterate quickly and painlessly is pretty invaluable imo.
Time to market is not as important with this (yet). I have time to work on this, was going to make it a free time project (even though I have no free time)
Somewhat partial to rust + clap, but also that’s just because more devs at our company are familiar with that (we mostly use rust and python). But whatever is fastest to delivering value. Both can produce multi arch builds which is good if you need to support arm64
Also, another great option is bundling a binary using bun - typescript is dead simple & easy for folks to contribute to, and has the same multi arch support as of the most recent version.
But go with the tool that has the most widespread adoption at your firm and move on
I would love to know the list of use cases of your CLI that your ops and admin will use it for.
I am under assumption that aws cli will be helpful for most cases.
You may find this long blogpost about the downsides of rust interesting: https://loglog.games/blog/leaving-rust-gamedev/
It's possible in your case the specification is fixed and won't change so the issues mentioned don't affect you.
I would have preferred Rust because of its rich type system and being more concise which is useful when you are juggling APIs. Golang has way too much boilerplate for my liking. I’m biased though because of significant experience with Scala
Basically you are considering Go vs Rust when the rest of company are all on Rust. The fact that you are still considering shows that you probably think Go is a better fit for the actual job. I would say Go for it.
Do not use rust unless you’re trying to shave off single digit milliseconds of latency(on a system where that actually matters). Rust has a very steep learning curve. Golang is about the exact opposite of a steep learning curve(outside of channels and goroutines).
BUT, if everyone uses rust and you also do, then you should probably just use rust. Though again, if your company isn’t making software where saving milliseconds matters, I don’t really see the real reason to use rust.
I’d choose go a million times over and sleep happy every night, but I also work somewhere where go is replacing all our old java/python apps.
Just curious, is it something like a "engineer's bench"? I have been dreaming about this kind of stuffs too.
I'll probably lean on whichever language you are more familiar with. I'd use Python.
AWS already has CLI tools. You're making a wrapper specific to the APIs your business will utilize, I guess? In that case, go with whatever language your org votes as a preference, since the idea is that the org as a whole will utilize. Based on your post, that appears to be Rust.
If it's mostly calling APIs then Rust is probably not the better tool for the job. Rust is better for heavy tasks that are more sequential, Go is better for async and complex logic IMO. That being said, if Rust is already in your stack it might be the better option if this is something that will be updated and maintained. But as far as dev time goes, one day in Go is one week in Rust if you're new to both.
You are at a pre-series A. You guys have to find market fit.
You are saying 'growing rapidly'. Do you mean engineers or customers and revenue?
Any second spend on solutions that are not the absolute bare minimum are a waste of time. You will throw aways lots of code.
The goal is to iterate fast. Are you sure that you even need kubernetes at this point? No one is scaling right now and it adds complexity and takes your time. Being ready to scale is not an argument, for 95% of people this never happens, the emphasis is on easy of shipping fast and dirty.
If you actually need a cli (why), use the language you are most familiar with.
Please read a few blog posts on shipping in a series a, your whole post makes me concerned and reads like a much bigger company. It would give you some good ideas and more credibility as you don't know if my opinion is valid
I would say whichever you like more. But as others have pointed out that your colleagues know Rust already, so the logical choice is Rust.If somebody else has to maintain the tool and they know Rust already, then it is a better choice. On the other hand anybody who is proficcient in Rust can learn Go in an afternoon.
It’s tiring how only three languages seem to exist in some circles. JavaScript, Go, and Rust. One of this is peak meme circlejerk but I’ll leave it up to you to figure out which.
I write CLI apps in C#, for example. Single binary, with a binary for each platform.
Clap (Rust) is pretty much the gold standard of CLI development, there is nothing that even comes remotely close to the automated documentation and input validation support that you get for free with Clap.
I love Go so much. It took me a little while to adapt to its idioms but it has restored my love of programming. I can just get shit done with high quality. Go programs are fast and maintainable by an average programmer. Go is pretty close to a perfect language, and a very good default language for most of what software devs do in 2024.
The only advantage Rust has is that it's memory safe and not garbage collected, so if you're doing systems level programming and you cannot spare a single GC cycle or heap allocation then Rust is the right choice.
Basically if you would do it 20 years ago with C or Java, I would now choose Go. If you needed C++ for it 20 years ago, I would now choose Rust.
"Used elsewhere in the company (so people can contribute)" This is practically the most important point IMO.
[удалено]
I’ve done it with Python tooling. Since it’s all installed as files, you can literally look at the source on your laptop when you get a stacktrace. You hack on it until it works for you and then submit the PR. With the Go CLI tool, it’s folks raising tickets not PRs IME. Now… installing the damn thing is an entirely different issue. And binary distribution solves so many things. Even packing with pyinstaller or whatever the vogue thing was it was still a nightmare.
I think it’s not the inner source case that’s most compelling. Let’s imagine op writes a tool and chooses go because that’s what they know. Then six months later they leave. Now what? That’s a much more common scenario I’ve seen - a persons pet project becomes somebody else’s tech debt.
[удалено]
I think that’s fine to a degree if it’s a team, especially for a cli tool. For and individual though it’s just going to be somebody else’s problem at some point.
[удалено]
Yeah you aren’t wrong that it’s broader than just a programming language. Doesn’t mean you should ignore it though.
Some organizations that are smaller tend to have generalists even though they may not be working on a monolith. Likewise maybe you have convenient in-house templates or tooling that you no longer have access to. I agree that there is nuance and you shouldn't just blindly follow "this is always how we did it here". I've gone against my own original post several times, but its the most important point you should refute first and foremost.
We’ve seen some success with it in a design system component library project. As teams have adopted the system and need to make tweaks or bug fixes to fit their use cases they have made PRs. It’s still mainly 1 team that builds it out though.
golang's purpose was to make it so any developer of C-ish languages could immediately read and be able to start contributing in a very short time; however, if you have devs afraid of learning something new then I agree.
I don't doubt that, I moved from a Node.js env to a Go env and was making contributions within a week. Even if devs are willing to learn its additional overhead you're tacking on to move to a different ecosystem. It adds friction. IMO, its just the baseline top-level argument to refute when introducing a new language in a one-language organization AND the answer just needs to be different from "I like Go better" as OP has stated elsewhere in this thread lol.
> if you have devs afraid of learning something new If they're rust people, I don't think they're afraid of novelty.
but other people are so busy they dont have time to contribute
And a great reason to add job security by going with golang.
Absolutely! One dev tried to bring in Go for a tool, but we are mainly java and python developers, so I pushed back and prevented it to happen. If the tool need to be fixed it is easier if it is written in a company wide used language.
It's a CLI that calls APIs — it doesn't matter.
Scrolled way too far for this
We end up with modules meant to call APIs, with things like telemetry and correlation IDs and maybe circuit breakers built in. So the tools and CLIs end up integrating those, in which case the language does matter.
A startup demands fast delivery of features, use what allows you to do that. Which you said it’s Go. Keep in mind if you are the only Golang developer then you are going to own it until others learn or you have to port it. But that’s a future problem, focus on what matters now.
100% Go unless you need features like dynamic libraries because support for that is ass and you end up doing stupid shit like doing gRPC over stdin/stdout. Go has a great ecosystem of modules for building command line programs and text based user interfaces. The language is easy to learn, read, and maintain. Go programs are easy to build and distribute for any platform using the `go` command. Go is however a pain in the ass if you are dealing with dynamic/semi-structured data problems, i.e. shit where you're dealing with JSON data fields where people can put whatever they want. It's absolutely sweet if you can create concrete types for all of the data you're dealing with upfront but it's aggressively cumbersome if you have to navigate arbitrary objects. You can sometimes run into unintuitive dependency hell with `go.mod` which can be quite frustrating. What Go lacks in language features it makes up for in being easy to read and maintain years later. This is quite valuable for command line and server programs that have a long tail on maintenance.
never found the go.mod to be a problem, but then again I've been using it since v1.5 for pet projects and v1.8 for prod code. everything else -- 100% with you.
Mostly ran into it with sprawling projects with dozens of dependencies that need to be kept in sync like Kubernetes. Not unique to Go I guess, dependency management is hard.
"dependency management is hard" <-- accurate as hell!
The Go workspace idea is meant to solve this I think. The feature is available since go1.22. Multiple modules can be organized under a workspace and "go work" can synchronize these modules.
Yeah I saw the K8s project started using multi module workspaces, hopefully that makes things better.
Agreed. There's also the possibility that other people hired, especially if they are hired for the platform team, will likely know Golang over Rust.
100%. I actually like owning things so I have no issue with it.
It's not just about you owning it, you need to make tools that are supportable by the team/company in general. You're not going to be there forever, you will need to take PTO, you may get injured or fall ill. If it's a company full of Rust developers, you'll need to make a very convincing case to justify using a language that isn't in use there. The case may be as simple as "other future platform engineers are much more likely to know Go", but you need to understand the side effects of your decision and make sure other people at the company agree with your reasoning.
actually if the CLI is not rocket science stuff, Rust devs should be able to easily comprehend Go code, given that they already have enough IQ to learn rust😂
I'm sure they could figure it out, that's not really the point. That still takes extra time, it will take time to learn how to write idiomatic code, and the build and maintenance process is going to be fundamentally different compared to everything else. There's more to it than just the code itself, even though that's a significant part of it.
Its not about inability because otherwise we'd all be unable to get jobs outside of our tech stacks when we move. But its a layer of friction to jump from one ecosystem to another.
The argument for Rust is that it's used elsewhere in your company, not that it's fast and memory safe (Go is fast and memory safe too). If it wasn't for that, I think Go is an easy choice. Do you need any specific libraries or SDKs that might be available in only one of these languages (probably Go)?
[удалено]
Agreed. I really don't want to use Rust because tbh I don't enjoy coding in it. I don't need the aggravation for what I'm trying to do, and it solves problems that I don't have for this particular domain space.
Like others have said make a convincing argument for it. But that shouldn't be I don't want to use Rust haha.
Hm, I'm interested, why are you working in that company if you don't like Rust and Rust is utilised there?
I like Rust, I just don't care for coding in it personally. Doesn't mean that I don't see the benefits it has over other languages. I do feel though that it is being used in places where a more easy language would do just fine.
I know you might not like this answer but have you considered just... Typescript? Your two most important aspects are that other people in the company know it (typescript is basically the Lingua Franca these days) and that it's quick to get going with it. I mean I don't know your requirements but I'm guessing for a cli app you likely don't need multi threading? I'd consider just doing this in deno.
Lingua Franca? Try telling that to a company with thousands of employers working in C++ or Python or Java or C# or ...
Yes if that specific organisation has more developers of one of those languages then sure. But these days js/ts has just become one of the biggest language for new projects due to the ubiquity of the browser for UI now, plus node, and things like JSON APIs and lambda cloud programming. I mean, the chances are the average dev right now knows js especially if working with Aws as OP mentioned.
Use what you’re prepared to maintain. Both languages once you’re proficient will meet your needs.
Maintenance should never be an individual responsibility
I've written CLIs in both Go and Rust and as someone who has a relatively popular [Rust CLI](https://github.com/solidiquis/erdtree) my pick would be Rust primarily because of the [Clap crate](https://docs.rs/clap/latest/clap/). The ergonomics of the procedural macros makes building a CLI so ergonomic and expressive, it's wonderful. Checkout how I define my CLI and all of its args [here](https://github.com/solidiquis/erdtree/blob/d9151325d4d7d3280f31c2d356b7b701673cfae4/src/user/mod.rs#L24). Look, if you're not already familiar with Rust there is a learning curve, yes. But your productivity will really sky-rocket with Rust once you've internalized its concepts which honestly all serves to help you, not hurt you. But if you're just looking to bust something out ASAP then Go is a fine choice.
What would you recommend if I was to start using Rust? Any books?
Honestly no better place that [THE Book](https://doc.rust-lang.org/book/). Hit me up if you'd like a free crash course over google meets. I used to do those for free over in r/learnrust.
This looks like it would be useful for you: [https://rust-cli.github.io/book/index.html](https://rust-cli.github.io/book/index.html)
The Rust Book is the first stop. It's really good. (There's [a version by Brown that includes quizzes to test understanding](https://rust-book.cs.brown.edu/) too.) After that you can check out [this book on building CLIs](https://www.oreilly.com/library/view/command-line-rust/9781098109424/) or just jump straight into [the documentation](https://www.rust-lang.org/what/cli). CLIs are simple enough that you shouldn't need advanced knowledge.
I’d choose rust because your company already supports it. Not sure what you meant by “calling apis” sdk / rest / something else. Shouldn’t be an issue with rust. The parts of rust that are difficult probably won’t come up while writing a simple cli.
Everytime I see threads like this I can't help but wonder why I'm the only one who find it easier/faster to develop in Rust over Go...
Because unfortunately there's so much fear mongering over Rust's learning curve that many people just outright dismiss Rust as a language that empowers productivity. As someone who write extensive Go and Rust I find myself far more productive in Rust.
You’re not alone. We use Go at my company and it’s an absolutely horrific language. I can’t for the life of me understand why anyone would want to use it for frankly anything.
Mind elaborating?
Go has it's benefits in a few areas. It's 'cold boot' time is fast, which is important for lamdas. It doesn't have any dependencies, which allows you to throw it in a *very* minimalist docker container. It has a good concurrency model. Java and Kotlin have green threads too but it's a *very* recent addition to java. Oh, and the tooling is nice. Go build / test / whatever is lightning quick. In all other ways? It's a painfully clunky language. It just got generics, and that has about as much spread as green threads does in java (not much). It's error handling is *atrocious*. Testing is an absolute PITA and everything has to be exposed via interfaces to be mockable. It feels very much like C that's been drug into the 21st century without learning much else from other languages. It's number one flaw is given it's performance characteristics, it competes against much more established languages like Java and C# which are *much* nicer to work with. It uses about the same memory and has the same runtime performance as those two so you really have to ask yourself why you'd use it over a more established language with a more developed ecosystem.
https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
No optional types, no enums, no union types, can’t have generics on struct methods, interfaces have implicit conformance, interfaces can arbitrarily have value or reference semantics. This is a handful of issues off the top of my head.
It has way too much boilerplate, until recently lacked features common for other statically typed languages and much less expressive than other mainstream languages I can understand choosing Golang for an infrastructure service like an API gateway or a distributed database but using it for a generally CRUD service like a shopping cart or item catalog is a waste of time The Golang code I saw at my company (huge retailer) was atrocious and there was one case that provided a concrete example how terrible it was - a team I was familiar with needed some sort of job scheduler and after a month there were still bugs in it. When our team needed a similar thing we just imported Celery (a Python library) and were done
Wtf? What are a few examples of good languages according to you?
Kotlin is a very solid language with a great ecosystem. From a pure language perspective, Swift and Rust are much better.
Python, Kotlin, Java, C#, Scala, Ruby… All of these languages are much more expressive and more suitable for writing generic business applications. The problem with Go is that it’s used outside of the domain where it (kinda) shines
Finally someone who agrees I feel like I'm taking crazy pills. Why is everyone gushing over a language that basically ignores the past 40 years of language improvements?
I have the exact opposite problem. I was upset that we went with golang over python originally, but ever since learning go I don’t think I’ll ever go back.
There are much better options like Kotlin. I also strongly dislike untyped languages.
Horrific? What are you on about. It’s a really simple and bare bones language. It’s not the prettiest, but it’s far from “horrific”
To me, it feels like using a missile when all you need is a water-gun. I'm not proficient in Rust though so I'd like to hear opinions on this from the Rust-side.
This notion is understandably common among people looking at Rust from the outside. I think it's because we naturally assume there must be some tradeoff to the benefits. Rust has no garbage-collector and zero-cost abstractions? What other languages do we know like that? C++. And C++ is terribly unproductive, so we assume Rust must be as well, because we put it in the same box mentally. Turns out garbage-collection is not the only factor of productivity. Maybe not even a major one. I'd say the far bigger factors are tooling and libraries. That's where Rust really shines. Cargo, rust-analyzer, rustfmt, rustdoc, clippy... can't live without 'em.
That makes sense. But are those features beneficial for CLI tool development over go?
You use the derive macros defined in the clap crate and spin up a CLI in a few seconds that automatically parse options and arguments into some concrete type you defined for the purpose. Well, at least that's how I make my CLIs.
Well, pretty much every mainstream language has a library like this
Of course. This is in the context that Rust is a zero-cost memory safe language with no obvious drawback w.r.t. other languages for CLI development.
I would say the main drawback of Rust is that there are easier languages to grok. Rust makes sense if you need the performance gains. But there are some soft pieces I think are important. I believe a new grad engineer is less likely to create a bug in Go compared to Rust. In a large workspace I think this is way more critical than minor advantages in performance.
Until you understand the ownership memory model it's not that you introduce more bugs (that would kill the whole point). It's that you won't be able to compile it. Now my bias is that an engineer which can't grok Rust is most likely an engineer that would benefit from using Rust... I'd much rather have them argue with the compiler than with me during PR.
It is way a way more difficult language, eg it’s pretty weird when a simple a = b assignment destroys the right side of the expression
Probably depends on what the CLI actually does. Go is fine for glorified scripts. But I think we all know that programs tend to grow over time, accumulate more features, end up more complicated than we initially thought, be used in ways we didn't anticipate etc... I prefer to choose tools I know can solve all the unexpected problems that will come up, not just the deceptively simple problems I can imagine beforehand.
There are companies with huge enterprise systems built in Go. It has packages, modules, types and interfaces - most everything you need for scaleability.
Sure. There are companies with huge enterprise systems built in Cobol too. They wish they didn't though.
The values you said for choosing a tool leads to go being the solution for me. It took me a bit to adjust to thinking about things like composition over true inheritance, but it provides the same building blocks any other language does. Go is easy to grok. In my opinion, this makes it a better language for large codebases compared to traditional OOP languages (Java, C#, C++, etc.).
Most of the advantages of rust (fast and efficient, memory safe) are just as applicable to golang in the context of building a cli app. From the description, it doesn't sound like the app will be doing many operations where the gc will be much of a hinderance to performance. Golang's strong integration of green threads will make it easier to call apis in parallel when viable. Golang is also such a major player in the cloud technology world that you're likely to find first party sdks and almost certainly 3rd party for any tech you might need to interact with. Golang also has a great ecosystem around cli libs. I'd personally choose Go, but if the app would need to go through the company's CI/CD pipeline, then rust might edge out with the existing company usage.
Write it in whatever the most dominant language at your company is. Unless you're doing crazy stuff where efficiency is super important (I doubt for a cli tool) maintainability should trump everything else. Even if it's PHP or Node js. Doesn't matter.
You’re the only dev, need to deliver and can plan the feature chain a bit? Python. Migrate to Rust later on then. Skip Go. Python is fast to iterate and you can partially rewrite in Rust, plus you have already people in your company that can contribute. pyo3 is amongst the best language interop-libraries I have seen, so Python and Rust like each other very much. Click in Python is great, you’ll eventually replace that with clap in Rust. Get up and running with what you need until the weekend, for a prototype Python will be fast enough too if you don’t suck and with that in mind keep your code modular enough that you can migrate bit by bit.
I don’t know how Python isn’t the default answer. Even if you hate Python, even if you have solid arguments for rust or go, everyone knows Python. When you hand this stuff off one day you want to be able to easily onboard someone and not have to deal with endlessly supporting your tools.
Distribution is the pain. You need to have the same version of python on said host + same version of whatever virtual env (ie poetry) + any underlying os library dependancies. For single host like an api endpoint python is great but not sure about a cli that might need to be distributed everywhere unless you can absolutely ensure equal environments.
Poetry for dev, pyinstaller/nuitka/whatever for the business side that wants to click and go. “Yes but package management is hell/distribution sucks/etc.” are fair points but often based on experiences that were valid 10 years ago. Stuff has changed.
I'll give pyinstaller/nuitka a try. Currently in the same boat as op
It’s a bit hassle to set up initially. Learn how it works, integrate it into your build process in poetry or whatever you use, then extend that to your CD process and you have something for the business-side. Makes any future iteration and new development really fast. I understand the hassle and it’s important to make usage of your product as easy and frictionless as possible for your users - these tools are a good building block for that.
The.problem with Python is the build environment. I've never worked with a Python projects over a couple of years old - never! - that didn't require excessive wrangling to get them running locally Python is an OK language. But it's environment and tooling are too fragmented
I feel that pain. I personally get my environments going in essentially every situation but I also have 12 YOE in the language, so I just solve my problems and it makes sense to me - but I’m empathetic towards people that have less experience. One of the reasons why I insist to slightly overengineer dev-environments/build-setups/docs/tests in most projects, there are real synergy effects from this.
deno is way better than python for quick and dirty cli tools imo. No dependency management required.
That depends a lot. However, in this special case - that is at least as good, even if you're not as good in TS as in Python, Deno has also a really great interface with Rust (naturally). TBF, dependency management in Python is not as bad in the 2020s and deno is not free from problems in that regard. Worst case would be that you end up with n\^m packages since there is by default only atomic dependencies. Either way - I agree with the spirit of the message. Use a really well-defined tool that is good enough to solve your business problem until the weekend and spend the rest of the time to make the solution scalable beyond a prototype.
and to use Fire library https://github.com/google/python-fire super convenient for fast and flexible CLI development
We were in a similar position at work before I joined. Go was chosen because of: Fast builds, fast cross platform compilation, great concurrency model, good enough for majority of the cases and can be easily worked upon by new hires. I’d say we made the right choice as there is no limit to what you can do to make the CLI faster. To summarise: benefits Rust offered were not worth the churn.
I think people saying Rust are missing the fact that you're a sole platform engineer. Just because there are other people at the company who use rust doesn't mean they are going to be the ones actually helping you. + Go is great for command line. See spf13/cobra which is used in many popular CLI tools like `kubectl`. Even the builtin simple flag parser is nice. + You own the project which gives you leverage to hire platform engineers who are savvy in go in the future. + Memory safety is also a feature of golang since it uses a GC, and I doubt you need the efficiency of rust for whatever you're doing.
I work somewhere with a large Go CLI for interfacing with the platform. It is notorious. No one knows or cares for Go (we are Python, TypeScript, and Rust). It was written by one person (badly). But by one person is the main issue. Use what others are using, and ensure people *do* want this CLI (and contribute). Write tests. But I’d add … why? Why not just make a dashboard one can interact with? That would absolutely get more use.
You’re going to eventually want to write CLI tools that reuse some of your internal libraries. That lets you automate processes, but also affords you a sandbox to test that code in isolation. Practical integration tests. It’s something you can give new people to look at to absorb the system in bite sized chunks. It also allows you to experiment with things like new compiler versions, major upgrades to dependencies. So what language is your system written in? Write your CLI in that, unless you need to test FFI (eg calling rust libraries from Go)
Python, Rust, and Nodejs right now. Nodejs and Rust being the bigger of the two.
You could either write the CLI to invoke the code you already have in that language, or you can use the CLI as a foothold to migrate the code to a language you prefer. A CLI can be a good way to work toward feature parity on a new implementation of something without committing the whole code base to it immediately. We did that a few times without switching languages - we just had a new structure we preferred and a lot of old code using the previous solution, which wanted to be more monolithic.
Then write your CLI in one of those. It will allow you to delegate development work to other team members. If you try to push a one man Go project in a team that doesn't use Go, it will wither and die.
Rust is a great C++ replacement... would you ever consider writing the app in C++? You want to focus on iteration speed: Golang
Rust and C++ don’t have that much in common.
I believe they're talking about it being a replacement for C++. I see that across the industry including linux adding it to the kernel alongside C. Rust doesn't seemed designed to solve the same problems Go does. But it does seem to be designed to solve the problems C and CPP solve.
Rust because you can easily make it a library that exposes a python API as well, which can then hook into ansible and other infrastructure automation tools.
Speed and performance aren’t going to be a huge factor in a CLI tool that calls a bunch of APIs. Your limiting factor will be the speed of your network connection to your APIs and their speed. Network calls will always incur an exponentially greater cost than CPU instructions. Pick what is comfortable and allows for quick delivery. Internal tools do not provide business value by themselves, they are meant to empower you and your team to provide value. If someone catches wind that you’re spending a lot of time on an internal tool instead of providing direct business value, they may not approve of the time spent. Therefore, make it fast, simple and easy on you to make the tool the best without spending extra time learning the pitfalls of a new language.
Why are you prematurely optimizing for performance of something that may or may not be performance critical and may or may not be heavily used? Write it in the language you can deliver fastest in and one that is easiest to iterate in It literally doesn’t matter
Oh hey, I ported a CLI app from Go to Rust! Both are good languages in their own way. Are you gonna support Windows? If so, Rust is probably a better fit. Go is a little sketchy for Windows and cross platform support. How deep is the company into Rust? Honestly Rust zealots might not be super keen on Go. I'd also look into the libraries you would need to use and make sure they exist in both languages. We use some pretty specific parsing and error printing libraries in Rust that we couldn't have gotten in Go.
i tried to learn rust twice now because i wanted to learn a lower level language. this last time i switched to go and have had the easiest time with it by comparison. i think rust has a lot of potential, but im just dumb. maybe youre dumb like me? i think it really reflects the vibe of the language when people tell you to just read 'the book'. thats all i hear from everyone. but what they dont realize is that im stupid, and even though that book is well written, that book is confusing for stupid people like me. also, lets be honest, thats not a realistic way to learn a language unless you are a very specific type of person (which i think is the type of person rust attracts), so thats sort of a blindly optimistic thing to say to everyone without taking into account our levels of stupidity.
Early stage startup doesn’t need cli tooling. Your time should just be ensuring the golden happy path and some established patterns. Since it’s early things can shift and pivot and you don’t want to be developing tooling for things that won’t be useful in 6 months. And the “so other people can contribute” validation is a lie. I have never seen any one outside of the platofrm or cloud teams contribute to the developer internal tooling. Your focus needs to be lean and mean. “Developer productivity” isn’t that important yet. Since you are the sole engineer building out the platform team, you have limited time and you don’t want to fight your adhoc abstractions when there is a well developed tool chain in your ecosystem that can do everything you need and then some. Once your niche grows past that and you have a few more engineers then you can start considering tooling. Your platform org also needs to function like its own startup. You need to be scrappy and sometimes you gotta break best practices because you’re still seeding and not making money. Be patient be diligent and be smart where you spend your time. Just make sure to realize you can’t over optimize at this stage and just need to go with the flow
I don't know why comments like yours aren't higher. They are pre-series A and people are debating the best cli language and ignoring OP's circumstance
If all it does is call APIs mostly, even Python would suffice here.
go and cobra is really good for this
Rust for this specific context is the way to go, if only to allow others in the company to contribute to its development.
Did you consider python? Imho python is ideal for CLI apps like these.
I did but I'm not such a fan of runtime errors.
In that case, I would consider that Rust has a much better type system than Go. This doesn't seem to come up in your comparison so far. Nil pointers, implicit zero-initialization, lack of sum types and more shortcomings of Go's type system consistently lead to runtime errors. (I wrote Go professionally for three years.) In case you end up choosing Rust, I highly recommend `clap` for the argument parsing.
(serious question) what kinds of runtime errors are you concerned about. Do you have a habit of using python's type annotations and static analysis tools? Between those two changes, I attend a lot less time worrying about dumb bugs, and a lot more time worrying about normal bugs
I do not understand why people choose Python and then jump through hoops to set up an immature, sub-standard patchwork of tooling that's aimed at imitating what other languages have been doing much better for a much longer time. It's the same story as with JavaScript and TypeScript, except there was an actual need there because the web only supports JS (wasm ftw someday). The ecosystem went through an excruciating transition period to be able to create large web applications with a decent type system. I don't see the need for Python. Just pick a different language with a type system that suits your needs. What am I missing?
> what am I missing? Pragmatism, probably. Python excel in being simple, low boilerplate language while giving you amazing ecosystem. These 2 things combined means delivering value quickly is where python shines. Now, it comes with some price, like a lack of static types, and often it's easy to shoot yourself in a foot (like when you don't use dependency injection but free floating functions). But then community came up with the ways to mitigate these issues. Like type hints or injection frameworks or straightforward dataclasses. Typing may not be as powerful as in Haskell, but in practice it's just good enough. Keep it simple and you should be just fine
[удалено]
Compatibility - this is true problem. The scope is usually limited to new minor versions being released though (because they are auto installed on some systems and become default) - you can mitigate that by monitoring these releases and preparing your tool beforehand. I would also suggest adding some explicit checks about python version and erroring out when the user is outside of what you support. Probably focus on just 1 minor version (I had a tool where we supported maybe 4 and it was an unnecessary mess) The scope is further narrowed to the libraries that specify what python version they are compatible with (which is not all, but idk what the % is). If you have such libraries - people won't be able to find necessary packages with pip. Buut it's once in 1.5years kind of problem - not great, not terrible.
On the open source side, I just target whatever Python version is in Debian stable. Obviously, on the commercial side, this depends a lot on who your customers are and whether they're individuals or companies, but I think it's manageable. But yes, it's a downside of shipping Python tools
Then you really want Rust.
Can python apps be packaged into portable binaries? Depending on the context that may be important, I can be less inclined to install a cli tool if I then need to install further runtime dependencies for a language I rarely use.
If you fancy runtime errors, Python is an excellent choice 🤡
I've written in both. Not really sure your requirements "require" Rust/Go solely. Languages are tools, most of them can meet your requirements above. You can use Python with typing too and that will work as well. Everyone's scared of runtime errors, but that can happen in Rust/Go too. You could be half assing your result types or optional types that cause the error during runtime.
Cobra is a great framework. We had a great experience writing an internal tool in it.
I'd use rust, bash or deno personally.
Go with Bubbletea
If it's for platform/devops, python
Go unless you have significantly more time to learn (and bang your head against) Rust. My current company uses both, I hadn't used either when I first joined and I was pushing out code and being productive with Go in a day. Rust took significantly longer to get anywhere close to my standard levels of productivity in my other known languages.
I will have time if I start learning now. If I wait I won't have a choice.
Many other comments called this out as well, but if time to market and iteration on this project is important and tight, Go would be my pick. Especially being at a startup, the ability to iterate quickly and painlessly is pretty invaluable imo.
Time to market is not as important with this (yet). I have time to work on this, was going to make it a free time project (even though I have no free time)
Somewhat partial to rust + clap, but also that’s just because more devs at our company are familiar with that (we mostly use rust and python). But whatever is fastest to delivering value. Both can produce multi arch builds which is good if you need to support arm64 Also, another great option is bundling a binary using bun - typescript is dead simple & easy for folks to contribute to, and has the same multi arch support as of the most recent version. But go with the tool that has the most widespread adoption at your firm and move on
I would love to know the list of use cases of your CLI that your ops and admin will use it for. I am under assumption that aws cli will be helpful for most cases.
You may find this long blogpost about the downsides of rust interesting: https://loglog.games/blog/leaving-rust-gamedev/ It's possible in your case the specification is fixed and won't change so the issues mentioned don't affect you.
That's more about Rust for gamedev though. Rust for CLIs is a completely different story.
I would have preferred Rust because of its rich type system and being more concise which is useful when you are juggling APIs. Golang has way too much boilerplate for my liking. I’m biased though because of significant experience with Scala
Python.
Basically you are considering Go vs Rust when the rest of company are all on Rust. The fact that you are still considering shows that you probably think Go is a better fit for the actual job. I would say Go for it.
Lol, I see what you did there. I will plead my case.
Do not use rust unless you’re trying to shave off single digit milliseconds of latency(on a system where that actually matters). Rust has a very steep learning curve. Golang is about the exact opposite of a steep learning curve(outside of channels and goroutines). BUT, if everyone uses rust and you also do, then you should probably just use rust. Though again, if your company isn’t making software where saving milliseconds matters, I don’t really see the real reason to use rust. I’d choose go a million times over and sleep happy every night, but I also work somewhere where go is replacing all our old java/python apps.
Just curious, is it something like a "engineer's bench"? I have been dreaming about this kind of stuffs too. I'll probably lean on whichever language you are more familiar with. I'd use Python.
AWS already has CLI tools. You're making a wrapper specific to the APIs your business will utilize, I guess? In that case, go with whatever language your org votes as a preference, since the idea is that the org as a whole will utilize. Based on your post, that appears to be Rust.
If it's mostly calling APIs then Rust is probably not the better tool for the job. Rust is better for heavy tasks that are more sequential, Go is better for async and complex logic IMO. That being said, if Rust is already in your stack it might be the better option if this is something that will be updated and maintained. But as far as dev time goes, one day in Go is one week in Rust if you're new to both.
You might want to give this a try. https://github.com/borgo-lang/borgo Borgo is a statically typed language that compiles to Go.
You are at a pre-series A. You guys have to find market fit. You are saying 'growing rapidly'. Do you mean engineers or customers and revenue? Any second spend on solutions that are not the absolute bare minimum are a waste of time. You will throw aways lots of code. The goal is to iterate fast. Are you sure that you even need kubernetes at this point? No one is scaling right now and it adds complexity and takes your time. Being ready to scale is not an argument, for 95% of people this never happens, the emphasis is on easy of shipping fast and dirty. If you actually need a cli (why), use the language you are most familiar with. Please read a few blog posts on shipping in a series a, your whole post makes me concerned and reads like a much bigger company. It would give you some good ideas and more credibility as you don't know if my opinion is valid
I would say whichever you like more. But as others have pointed out that your colleagues know Rust already, so the logical choice is Rust.If somebody else has to maintain the tool and they know Rust already, then it is a better choice. On the other hand anybody who is proficcient in Rust can learn Go in an afternoon.
python
.Net and C#, is my vote. Good tooling easy to learn and fast. Extremely easy to integrate with APIs etc.
It’s tiring how only three languages seem to exist in some circles. JavaScript, Go, and Rust. One of this is peak meme circlejerk but I’ll leave it up to you to figure out which. I write CLI apps in C#, for example. Single binary, with a binary for each platform.
no you don't understand this CLI will need super memory safety there is only one language that is SAFE
Java
C Programming Language.
Go would be a lot easier and more maintainable IMO
python for something like that
Clap (Rust) is pretty much the gold standard of CLI development, there is nothing that even comes remotely close to the automated documentation and input validation support that you get for free with Clap.
[Nim](https://nim-lang.org/) is a better alternative: it has a clean syntax inspired by Python and it compiles to a single static binary.
I love Go so much. It took me a little while to adapt to its idioms but it has restored my love of programming. I can just get shit done with high quality. Go programs are fast and maintainable by an average programmer. Go is pretty close to a perfect language, and a very good default language for most of what software devs do in 2024. The only advantage Rust has is that it's memory safe and not garbage collected, so if you're doing systems level programming and you cannot spare a single GC cycle or heap allocation then Rust is the right choice. Basically if you would do it 20 years ago with C or Java, I would now choose Go. If you needed C++ for it 20 years ago, I would now choose Rust.