Golang

I’ve spent years reaching for Makefile by default, but I recently started using Taskfile for my projects instead. While it’s still the industry standard, it often feels like a mismatch for the specific needs of a modern web stack… Since moving a few of my workflows over, I’ve found it much better suited for the way I work today.

Here are three features that convinced me:

=> Self-documenting by design

With Makefile, just getting a readable help output requires a cryptic grep | awk one-liner that’s been copy-pasted between projects for 40 years. Taskfile simply has a built-in desc field for each task, and running task --list instantly shows everything available with a clean description. It’s a small thing, but it makes onboarding new developers (or just returning to a project after a few weeks :) ) so much smoother.

=> Truly cross-platform without hacks

Make was designed for Unix. The moment someone on your team opens a PR from Windows, you’re suddenly wrestling with OS detection conditionals, WSL edge cases, and PowerShell compatibility. Taskfile was built cross-platform from day one. It uses sh as a universal shell by default, and if you do need platform-specific commands, there’s a native platforms field that handles it cleanly at the command level. No more fragile branching logic.

=> Built-in validation and interactive prompts

Adding a confirmation prompt or a precondition check in Make means writing verbose, bash-specific shell code that breaks outside of bash. Taskfile has prompt and preconditions as first-class features: one line to ask for confirmation before a deploy, another to verify an env variable is set. It works on every platform, out of the box, no shell scripting required.

In my opinion, Taskfile feels like a much more predictable and modern successor!

What do you think about it?

Given the following short function

func example(foo string) error {
    if bar, err := doSomething(foo); err != nil {
        return err
    } else {
        doSomethingElse(bar)
    }
    return nil
}

Why does the linter recommend I change the if block to

    var bar whateverType
    if bar, err = doSomething(foo); err != nil {
        return err
    }
    doSomethingElse(bar)
    return nil
}

In my mind the former example restricts the bar variable to the smallest scope that is needed, and more clearly identifies doSomethingElse as something that should only happen if err != nil.

I know it's redundant, but now if I want to change it to an else if ... chain I don't have to worry about accidentally including or excluding code from that block, I already know exactly what's supposed to be in it. I just feel like it's a safer programming practice.

But looking forward to other opinions and discussion. Thanks!

I’ve spent years reaching for Makefile by default, but I recently started using Taskfile for my projects instead. While it’s still the industry standard, it often feels like a mismatch for the specific needs of a modern web stack… Since moving a few of my workflows over, I've found it much better suited for the way I work today.

Here are three features that convinced me:

=> Self-documenting by design 

With Makefile, just getting a readable help output requires a cryptic grep | awk one-liner that's been copy-pasted between projects for 40 years. Taskfile simply has a built-in desc field for each task, and running task --list instantly shows everything available with a clean description. It's a small thing, but it makes onboarding new developers (or just returning to a project after a few weeks :) ) so much smoother.

=> Truly cross-platform without hacks 

Make was designed for Unix. The moment someone on your team opens a PR from Windows, you're suddenly wrestling with OS detection conditionals, WSL edge cases, and PowerShell compatibility. Taskfile was built cross-platform from day one. It uses sh as a universal shell by default, and if you do need platform-specific commands, there's a native platforms field that handles it cleanly at the command level. No more fragile branching logic.

=> Built-in validation and interactive prompts 

Adding a confirmation prompt or a precondition check in Make means writing verbose, bash-specific shell code that breaks outside of bash. Taskfile has prompt and preconditions as first-class features: one line to ask for confirmation before a deploy, another to verify an env variable is set. It works on every platform, out of the box, no shell scripting required.

In my opinion, Taskfile feels like a much more predictable and modern successor!

I wrote a deeper dive with specific code examples on how these features work in practice ;)

Proposal for adding generic methods to structs (not interfaces) accepted last month ✨

While not giving us everything we could want, it's still gonna be a welcome feature.

Gophers, hey. Confusing ^ with exponentiation instead of XOR in Go seems like a pretty easy mistake to make. The bug itself is simple, but it still shows up even in some well-known projects with large codebases.

How often does this happen in your code?

I was applying for a senior backend engineer job in this european startup in the healthcare sector.

I passed through 4 rounds of 1 hour interviews. Everyone was telling me this company is remote first, nobody works at the office.

Contract type is as remote on linkedin.

The offer arrived, 80k euros. They are very reluctant in giving the contract to me so I can proceed with the bureaucracy regarding blue card and job change before 12 months.

The contract arrives and it's full of traps:

• They can require work on weekends and holidays with no notice
• There isn't a single mention to remote working on the contract
• They can relocate me to any place with a 2 months notice
• HR refused to add remote clause on the contract

To make it even worse, they were processing my emails through an undisclosed AI tool using chatgpt, in which I've sent my personal documents.

Avoid these traps like hellfire.

Company name is Recare.

The next generations of Bubble Tea, Lip Gloss, and Bubbles are available now.

For those that don't know, these are Go libraries used to easily create terminal user interfaces.

cross-posted from: https://lemmy.bestiver.se/post/876696

Comments

cross-posted from: https://lemmy.bestiver.se/post/862879

Comments