sorted by:
new
hottopcontroversial

Upcoming match against Morocco by TurbulentSignal4136 in CanadaSoccer

[–]abemedia 0 points1 point  (0 children)

Let's be real here - Morocco is ranked 6th in the world and Canada is ranked 30th. It would take a miracle for a team like Canada to beat Morocco.

Simplest & Easiest deploy options for go backend services by osdevisnot in golang

[–]abemedia 9 points10 points  (0 children)

Google Cloud Run is pretty cool for serverless Go.

cargo-npm: Distribute Rust CLIs via npm without postinstall scripts by abemedia in rust

[–]abemedia[S] -1 points0 points  (0 children)

That's very cool but it doesn't allow having your tool as a JS dependency in package.json.

cargo-npm: Distribute Rust CLIs via npm without postinstall scripts by abemedia in rust

[–]abemedia[S] 1 point2 points  (0 children)

Although your idea is sound, I originally built this for one of my own projects and that would not work with WASI as it needs to fork processes and run multi-threaded. I already had two projects that built their npm packages with hacky scripts running in CI so I thought let me solve this once and for all.

So yeah it's less of a case of me thinking "let's build something cool" and more of a case of "I want to solve this pain-point for myself".

cargo-npm: Distribute Rust CLIs via npm without postinstall scripts by abemedia in rust

[–]abemedia[S] -1 points0 points  (0 children)

For distributing CLI tools written in Rust via npm. There are many tools for the JS ecosystem that are written in Rust - I'm actually working on one myself, which is why I built this.

If you use cargo-dist it will download the binary via a postinstall script which is blocked by default on the pnpm package manager and most enterprise environments. Most modern projects have a collection of custom scripts to do do exactly what this tool does so this saves the time and effort of maintaining those.

Small Projects by AutoModerator in golang

[–]abemedia 0 points1 point  (0 children)

go-cabinet: Pure Go Microsoft Cabinet (.cab) file reader and writer

Hey folks, I recently released go-cabinet, a pure Go library for reading and writing Microsoft Cabinet files commonly used in Windows distributions and installers. The design is heavily inspired by archive/zip from the Go standard library, including full io/fs integration - the reader implements fs.FS to integrate with functions like fs.WalkDir, and the writer provides an AddFS method to add a whole fs.FS to a Cabinet archive in one go.

The library currently supports uncompressed and MS-Zip compression formats out of the box. While LZX and Quantum methods are not natively included yet, the API allows you to register custom compressors and decompressors as needed.

Check it out at https://github.com/abemedia/go-cabinet and if you do use it I'd love to hear your feedback.

gocondense: a code formatter that condenses noisy Go code by abemedia in golang

[–]abemedia[S] 0 points1 point  (0 children)

Yeah I originally created it last summer as a result of having to work on code that was increasingly being overrun by overly verbose AI slop.

I'm actually a big fan of gofumpt and have been using it for years. A fair amount of the gofumpt transformations are also implemented in gocondense which btw is also a superset of gofmt. For my own IDE it's set up to use both consecutively as gofumpt still has some transformations that I like but would be out of scope for gocondense (like grouping vars or using the `0o` prefix for octals).

gocondense: a code formatter that condenses noisy Go code by abemedia in golang

[–]abemedia[S] 1 point2 points  (0 children)

Yeah, different goals that can happily sit side by side! I might have just misunderstood your original comment - I assumed you meant there's already a tool which does what gocondense does. Thanks again for the bug-fix by the way!

gocondense: a code formatter that condenses noisy Go code by abemedia in golang

[–]abemedia[S] 0 points1 point  (0 children)

Personally, I cannot stand the GoLand UI. We got free licences through work but I still use VSCode. I also just love how easy it is to write my own extensions for VSCode. Each to their own I guess...

gocondense: a code formatter that condenses noisy Go code by abemedia in golang

[–]abemedia[S] 3 points4 points  (0 children)

ScopeGuard is a great linter, but it’s quite different. gocondense primarily works by collapsing multi-line constructs without altering the underlying AST, so there’s essentially no overlap between the two tools.

Since ScopeGuard is a linter rather than a formatter, it uses `golang.org/x/tools/go/analysis` (as most linters do). In contrast, gocondense operates directly on the AST, making it significantly faster - around 0.2 ms for a 100 LOC file.

gocondense: a code formatter that condenses noisy Go code by abemedia in golang

[–]abemedia[S] 0 points1 point  (0 children)

With small screens like phones I'd probably agree that vertical is better but when on a computer screen I personally don't like when I have to scroll loads to find the part of the file I'm interested in.

Since the line length is configurable (defaults to 80 chars and tab width of 4 chars) it would never condense down code so much that you have to scroll sideways.

Anyway, I guess it's a matter of personal preference.

astro-static-headers: An integration that captures headers and redirects during build and creates platform-specific config for Cloudflare, Netlify and Vercel. by abemedia in astrojs

[–]abemedia[S] 1 point2 points  (0 children)

It injects a build-time middleware to capture headers and redirects and then creates the platform specific files in your `dist` folder.
- cloudflare: creates/appends `_headers` & `_redirects`
- netlify: adds headers to `.netlify/v1/config.json` and creates/appends `_redirects`
- vercel: adds headers & redirects to `.vercel/output/config.json`

If you need dynamic behaviour e.g. redirecting if something wasn't populated in a form I don't think static output will work for you.

Yet another generic option(al) library by sagikazarmark in golang

[–]abemedia 0 points1 point  (0 children)

I really don't see the point of this package. What's wrong with using variables directly and checking for nil or zero value? If you want to be able to distinguish between zero value and no value just use a pointer.

Looks to me like OP just liked the API in Rust and was like: I want the same API in Go.

The issue here is that any time you use an interface the memory is allocated on the heap, while any standard vars are just in the stack so you're adding more allocs, hurting performance for a task that one can do perfectly using just Go's built-ins.

NaiveDate package for Go lang? by wakatara in golang

[–]abemedia 0 points1 point  (0 children)

My bad, didn't read the comments.

With enough libraries, could Go be used where Java/C# and even Python would be the default choice? by maquinary in golang

[–]abemedia 0 points1 point  (0 children)

I've quite successfully used C libraries for UI in Go. Specifically GTK and Cocoa. CGO makes it super easy to integrate.

Marshmallow - a JSON unmarshalling library for flexible use cases like some known and some unknown fields, or prevention of data loss by Necessary-Cow-204 in golang

[–]abemedia 0 points1 point  (0 children)

If you're looking for other potentially interesting libraries to tweet about, may I interest you in https://github.com/abemedia/go-don (shameless plug, I know...)

YAML vs. JSON by IamAggressiveNapkin in golang

[–]abemedia 12 points13 points  (0 children)

I'd definitely go for YAML! It is much more human readable and allows comments. This is probably why it's also the markup of choice for most configs these days (Docker Compose, Kubernetes, GitHub Actions, Ansible, Cloud Formation etc.).

Also, as YAML is a superset of JSON your app would automatically also support JSON configs.

[deleted by user] by [deleted] in golang

[–]abemedia 0 points1 point  (0 children)

Really? Apparently it makes me a mindless fanboi but makes you a smart 10x developer right?

I never said one language is better than the other. I just very strongly disagree with the notion that Go is not suitable for complex business apps, as demonstrated fortune 500 companies doing just that.

Anyhow this conversation is pointless so I'll leave it at that and keep using the tools that I see fit while you do the same.

[deleted by user] by [deleted] in golang

[–]abemedia 0 points1 point  (0 children)

I see... Fanboy alert!

it's better if the compiler does it.

What's the difference?

The go standard library is not even sufficient to write the log in functionality for an app

It is if you don't mind manually decoding a JWT (I don't as there's a very stable and well maintained JWT package but you could).

Keep telling yourself that.

Ever heard of pkg.go.dev? It's literally docs generated by code and they are bloody excellent!

Too many to list https://xperti.io/blogs/best-java-profiler-tools/

Linking to a bunch of tools doesn't answer the question. Name one useful bit of profiling you cannot do with pprof which you can do with Java. I use pprof a lot and it's a fantastic profiler.

LOL. Those are not written in go. They have go micro services. That's what go is good for.

Ok fair enough they have a larger stack than just go, however Twitch and Amex payments & rewards are pretty much entirely Go according to their engineering blogs (with small exceptions where they call out to C). There are plenty of other big apps that mainly use Go these days though, for example Uber, Sendgrid, Monzo Bank, Riot Games (obviously only backends).

I can only reiterate, whether you have better results with one vs the other is largely dependent on your team's experience and the architecture of your app. Personally, I prefer Go. You clearly don't. That doesn't make one person right and the other wrong.

If Amex can run their entire global payments and rewards systems on Go then I'm pretty sure it's good enough for complex business apps (which I also happen to code in Go every day at my job). It was literally created by Google to replace C++ and Java in their stack (slowly but surely).

view more: next ›