Single Status Update
I've decided it. I'm going to learn Go as a programming language.
Installed and things are functional. Play time.
- Show previous comments 10 more
They're similar but the cause is different. You are right in that it will skip all code until it hits a recover if one exists.
In other languages you'd put the 'unsafe' code in a block and catch errors. In go you're meant to handle each error explicitly for each function that can have an error, like in C.
In go you can recover from a panic anywhere so long as you have a function that tries to recover somewhere in the stack. This allows recursive functions to throw out a panic and to be caught from the start as it unwinds the stack back to the caller.
Wrote a UDP Proxy for use with Man-in-the-Middle attacking myself. Already had one written in C, but that's not quite the point of me learning a language!
In C you're probably working with BSD-like sockets directly as I was. In short, it's a lot of setup work to be done to make it work.
- In go it's cut down a lot of this by having a 'socket' be a 'connection' that you either 'listen' from or 'dial' to. You then read/write to these connections with all of the underlying socket layer abstracted away. This is an upside of go.
In C buffers are usually malloc'd to remove them from the stack and onto the heap. Or if your program is performing under memory constraints, then a memory pool is utilized.
- In go there's no real preallocation- memory management for the programmer is nonexistent. If go can't allocate the required memory behind the scenes, then the program must terminate and there's no going back. This is a downside of go.
In C sockets should be placed on their own thread because network read/writes are blocking. Probably with pthread under *nix-like environments.
- Go routines. Threading with low effort and high code readability. Go does it better since it has innate threading.
- Performance is about the same after profiling each. It's a simple task really.
- Signal handling is *nix-like, and has about the same amount of 'boiler plate' code required to make them function.
All-in-all I'm quite happy with how much less code was required to write it, but that's more running along the lines of the language itself having such abilities prebaked, and C needing libraries. Really like the performance being very similar. Dislike the memory explosion possibility in go where there is no upper bound limits being able to be set before hand- this sort of kills go for anything with high memory constraints.
- In C you're probably working with BSD-like sockets directly as I was. In short, it's a lot of setup work to be done to make it work.