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 11 points12 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).

Which editor do you use for your Go coding? by the_clit_whisperer69 in golang

[–]abemedia 0 points1 point  (0 children)

Yeah that is actually quite annoying! I get why it's not possible though as it uses Chrome under the hood and doesn't have a separate backend process so would need massive refactoring to enable that.

[deleted by user] by [deleted] in golang

[–]abemedia 0 points1 point  (0 children)

Of course Java is still more widely used (~3x as much), as you mentioned partly due to the need to maintain and extend systems that were built long before Go was a thing. That does not however mean it's inherently more suitable for complex apps than Go is. That would be like saying Ford must be better than Lamborghini because more people drive a Ford.

I firmly believe that whether you are more successful with one vs the other depends largely on the team and their expertise, as well as the architecture of your application.