Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diving into Go by building a CLI application

eryb.space

Post reply on HN
Print view View original

101–110 of 124 posts

Re: Diving into Go by building a CLI application

#101

Post by apta »

q3k wrote: post #73
Groxx wrote: post #28

Earlier quoted context omitted.

CLIs are sorta my ideal use-case for Go. Goroutines are so error-prone to control since you don't have many options for abstraction, so it's relatively difficult to build long-running highly-stable programs... But CLIs don't usually need that. They can be ctrl-C'd if they go off the rails, and any dangling goroutines just die when the process dies. The simple distribution, fast startup, simple type system, and yolo-c…

> Goroutines are so error-prone to control since you don't have many options for abstraction, so it's relatively difficult to build long-running highly-stable programs... Oh? Building long-running microservices is literally my main use of Go, and in my opinion the language excels at it. What sort of issues are you having?

I'm not OP, but several come to mind: easy to mistakingly ignore return values (such as errors), difficult to compose, difficult to join, boiler plate heavy, no hierarchy/supervisor structuring.

Re: Diving into Go by building a CLI application

#102

Post by apta »

Groxx wrote: post #50
VexorLoophole wrote: post #35

Earlier quoted context omitted.

As the typical SysAdmin who likes to automate stuff, I have to agree. I am not experienced enough to talk about language designs. But I can say, that writing some small CLI application and deploying it onto some server is way less work with go. Simply because you can crosscompile the application and generate a standalone binary. Everytime I deploy some Python3.7 Flask Application on RHEL7 I start to scream. You were…

Alternative: I'd say Java (or similar), since it has the language abilities and sophisticated static analysis tools are readily available. But startup time is still not interactively-fast, so for CLIs it's sorta a no. For long-running processes tho I mostly like it, and stuff like compacting GCs keeps it running healthier much more easily than Go. Beyond that, dunno - I usually reach for Python since I've written it…

> But startup time is still not interactively-fast, so for CLIs it's sorta a no

They're working on it, for example: https://openjdk.java.net/jeps/310

Re: Diving into Go by building a CLI application

#103

Post by apta »

mpfundstein wrote: post #44
VexorLoophole wrote: post #35

Earlier quoted context omitted.

As the typical SysAdmin who likes to automate stuff, I have to agree. I am not experienced enough to talk about language designs. But I can say, that writing some small CLI application and deploying it onto some server is way less work with go. Simply because you can crosscompile the application and generate a standalone binary. Everytime I deploy some Python3.7 Flask Application on RHEL7 I start to scream. You were…

go is great for long running programs. in fact a large portion of the modern cloudstack is written in it. think of k8s, docker, nomad, etcd... of course one needs to understand how go routines work in order to use them correctly, but thats probably true for everything, right?

> go is great for long running programs

golang's gc is non-compacting. I wouldn't be surprised if there are cases where fragmentation becomes too much for a golang service to continue behaving properly. This becomes more likely in long running services.

Re: Diving into Go by building a CLI application

#104

Post by Groxx »

apta wrote: post #100
Thaxll wrote: post #87

Earlier quoted context omitted.

"Goroutines are so error-prone to control since you don't have many options for abstraction, so it's relatively difficult to build long-running highly-stable programs..." This comment does not really makes sense, Go #1 usage is for backend services, so it's indeed long running / stable program. "They can be ctrl-C'd if they go off the rails, and any dangling goroutines just die when the process dies" There are soluti…

His comment makes sense. golang "goroutines" are finicky compared to other ways of doing concurrency (e.g. Futures/Tasks in Scala/C# or Java's upcoming green threads). There are several reasons to this, not limited to the fact that it's trivial to mistakingly ignore return values (especially errors) when executing `go foo()`. Also, there's a lot of boilerplate involved if you want to start several of them and wait un…

I'd also label it that much of go concurrency control is intrusive, in that you need to write control-flow code into whatever it is you're trying to accomplish, or (typically) give up type safety or understandability. That's unavoidably more error-prone than not writing your own control-flow code, and I spend quite a lot of time discovering and fixing issues around it in libraries, even from some very skilled and careful teams.

Of course there are ways to achieve both in any language, but the massive educational pressure of the official docs and tutorials and examples cannot be ignored, and has profound impacts on what the community ends up building in the language.

---

It's roughly equivalent to manual memory management, IMO. Terabytes have been spilled claiming that C is safe if you're careful enough or use safe patterns, and CVE after CVE provides evidence that nobody is sufficiently careful. It has its benefits, but it also has its downsides.

Re: Diving into Go by building a CLI application

#105

Post by Fiahil »

masklinn wrote: post #90
rb808 wrote: post #85

Earlier quoted context omitted.

clap looks cool, thanks.

Check out structopt. It's a declarative layer atop clap. It's a bit polarising, but if you don't mind the "magic" (which you probably don't if you think clap looks nice) it's amazing.

It's being integrated into clap v3 :)

Re: Diving into Go by building a CLI application

#106

Post by zouhair »

eryb wrote: post #95
zouhair wrote: post #19

Just a note, xkcd has 2 image sizes. Small: https://imgs.xkcd.com/comics/confidence_interval.png Big: https://imgs.xkcd.com/comics/confidence_interval_2x.png Though not for older ones.

Thank you for pointing this out, I didn't about it. How did you come to know? It isn't on their API info page.

Webpage Source code.

Re: Diving into Go by building a CLI application

#107

Post by gerbilly »

swsieber wrote: post #68
gerbilly wrote: post #66

Earlier quoted context omitted.

When programming in Java, I routinely run code that has compile errors in it. As long as my execution path doesn't hit any code containing errors, I can run debug and even modify code in the debugger. That's exploratory programming.

That's not a general java attribute though, is it? I suspect that's because of the eclipse compiler.

Yeah you're right it's eclipse.

I haven't been able to get IntilliJ to run broken code, which is one of the main reasons I stay with eclipse at least part of the time.

Re: Diving into Go by building a CLI application

#108

Post by martinni »

dashwav wrote: post #10

Since everyone else is throwing out recommendations I personally think https://github.com/spf13/cobra is the best CLI templating system, especially because of how well it pairs with https://github.com/spf13/viper . Large projects like Hugo and Kubernetes have used Cobra to build their CLI tools, and it's fairly light as well even if you need simpler usage. We use it at my workplace simply for wrapping our microservic…

Don't think cobra and viper should be the default CLI framework. They're useful but overkill for most use case. I personally find that the standard lib has more than enough power to do everything.

Re: Diving into Go by building a CLI application

#110

Post by hoseja »

abjKT26nO8 wrote: post #59
hoseja wrote: post #54

Earlier quoted context omitted.

Oh, Rust does not have elegant strong typedefs? Bummer. Are they at least planned? It's such a boon for type correctness/safety.

It does have them: https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#...

I'm sorry but that does not look like an elegant first-class language construct, more like a pattern workaround.
Post reply on HN