These games are so much fun (I'm talking about your other games too). Especially loved gravity snake and square

Oh I wish the RSS link is working.

Maybe this dynamic feed [0] works for you. Shameless plug: I build [1]

[0] https://rssproxy.migor.org/api/feed?url=https%3A%2F%2Fjon.bo...

[1] https://github.com/damoeb/rss-proxy/

If you remove the duplicate jon.bo/ then it seems to work; https://jon.bo/posts/index.xml

Thanks for catching this - will update on the site as well!

I would rather get paid for the sake of commitment. I'm not interested in forming a team at the moment.

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?

Have you seen arguman.org ? Similar ideas (visual wise).

I've always wished this to be open sourced. Oh man I'm glad there is no javascript nonsense, overall design is great. Thank you so much for opening this beauty :)

Are you the Slava who wrote Factor programming language? Apple hiring all the good language designers around the world dammit!

I've used in production and experience was good. Xamarin Studio is more than enough for development / debugging. Xamarin is very powerful, but usually people taking the wrong direction with Xamarin and using Xamarin.Forms. As like many other cross platform solutions Xamarin.Forms sucks. If you think making a native iOS application is easy with Swift, it is same with Xamarin too. When i develop applications with xamarin (desktop/mobile) i usually look for java/swift documentations or forums for my problems. This way i don't need separate xamarin community. Because you can write the same code in c# easily. Please check my workflow, for any further questions, twitter: @umurgdk

Recommended workflow: 0. Never ever use Xamarin.Forms other than quick prototyping. If you develop applications with other cross-platform frameworks, you already know all of them sucks and Xamarin.Forms is not an exception.

1. Create PCL / Shared project for your business logic (also your view models if you're using MVVM architecture). Believe me most of your application is platform independent (except the view layer). Your api communication, storage operations all handled here. See 3rd article to how to make storage/network platform independent.

2. Create native projects for each platform (iOS, Android, Windows) implement native views here (use xcode, android studio if you need visual designer). This part should be exactly the same as your swift/java code. For iOS you're just implementing an ApplicationDelegate class and UIViewControllers as same as your swift code. Same for Android part, nothing special to xamarin just implement your activity classes. At this level you have the full power of your native platform with one exception 3rd party native libraries. It's possible to use (yes i used some swift/java libraries for youtube player) them but really hard to integrate to your project, that part has to be improved and better documented.

3. Your shared code base need native features, for example storage implementations are totally different for each platform, or changing views (navigation) will be implemented differently for each platform. Since shared code base shouldn't know anything about native platform. You should abstract these functionalities with interfaces. For example create a storage interface with methods like saving/reading/creating files. Another example might be network communication. Abstract it as an interface on your PCL and implement this interface in your native project with full control of your platform. Your shared code base only knows how to use that interface. And then each of your native projects should implement these interfaces. At this point dependency injection may help to register implementations easily. Actually that part is what makes you share your business logic. Writing idiomatic cocoa navigation code is much better than using any cross platform implementations, you have full control but in the same time your shared code base using them without knowing anything about the platform.

best april joke i ever see.

WHY????? Do you have endless empty time?