• Content count

  • Joined

  • Last visited

Community Reputation

3,132 Excellent

About CarlZalph

  • Rank


Visited by the Title Fairy
  • Visited by the Title Fairy

Recent Profile Visitors

10,892 profile views

Single Status Update

See all updates by CarlZalph

  1. I've decided it.  I'm going to learn Go as a programming language.

    Installed and things are functional.  Play time.

    1. Show previous comments  10 more
    2. Mobbstar


      So... "panic" is just what other programming languages call "throwing an error"? Or does it automatically look for the next Catch in the traceback and skip functions without any?

    3. CarlZalph


      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.

    4. CarlZalph


      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.