Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may return from the caller. And there is a reason why golang doesn't have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects' code.


Agreed - I thought this looked pretty reasonable, if a bit parenthesis-heavy, until I saw this example:

    func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
    }
When you nest the calls to try inside another method call, like this, the control flow really becomes obscured.


I dislike this proposal for the same reason. Looks like a function but does not behave like a normal one. I personally don't mind the verbose error handling in go and I think it's clear and easy to follow.


> People wouldn't expecting calling a function may return from the caller.

Why? This is essentially the same as the reset/shift pattern in e.g. Scheme - when you call shift from within a reset call, that might cause you to return directly from that. And that is a rather well-behaved pattern which composes quite well, it's nothing like the inherent weirdness of, e.g. call/cc.


Go kind of has macros, like everything else, Go's solution to first level features in other languages is called //go:generate.


Do you think it would be better if it was called try_or_return?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: