Readit Newsjpillora commented on Go beyond Goroutines: introducing the Reactive paradigm samuelberthe.substack.com... · Posted by u/samber
This is not the Go way. This abstraction appears to come for free, but it does not.
Deleted Comment
Simple backoff ftw https://github.com/jpillora/backoff
jpillora commented on WASM will replace containers creston.blog/wasm-will-re... · Posted by u/hpincket
They're different things, solving different problems:
- Containers are wrappers for binaries. Any binary can be contained, and when run, it gets a constrained (fake) view of the kernel.
- WASM defines a portable binary format. WASM is intermediate-representation, in the same vein as Java byte-code.
You could reasonably put WASM binaries inside containers
jpillora commented on Go should sometimes be a no-go brainbaking.com/post/2024... · Posted by u/Tomte
If you’re a Java dev, and you try to force Java-isms into Go, you’re gonna have a bad time.
The Go philosophy http://go-proverbs.github.io/ pays off less in the short term, within a single file, or a single stdlib function, or with syntactic sugar to code golf 3 lines into 1 - it pays off in the long term, across time and people - and this makes all the difference
jpillora commented on Show HN: Mdx – Execute your Markdown code blocks, now in Go github.com/dim0x69/mdx... · Posted by u/dim0x69
See also https://github.com/jpillora/md-tmpl
With 1 git ops pipeline, it’s fine, it’s the human merge gate, it’s doing its job protecting downstream
With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series
The better approach is to build API-first then optionally, add an API client into your git pipeline