I get this sentiment. There's an attitude among golang developers that things which are "trivial" to implement don't belong in the go standard library (even if they would see high usage). That, and Go's animosity toward generic code and syntax sugar make me feel like I'm fiddling with nuts and bolts sometimes.

For example, Go stubbornly excludes a math.Round() function from it's math package because "the bar for being useful needs to be pretty high" (this comment was followed by several buggy implementations of the method[1]). Go excludes integer math functions, and the lack of generics means I have to cast to float64 or write my own implementation everywhere.

Go’s lack of versioned packages and central repository makes packaging cumbersome.

One of the big headscratchers of the golang ecosystem. It's resulted in a million different package managers and ridiculous tools that rewrite all of your imports for you.

My favorite method of managing requirements now is glide[2] which pins all of your dependencies (to a git commit or tag) in a glide.lock file. Glide fetches dependencies into the vendor directory, but you never need to commit your vendored dependencies. Instead, commit the glide.lock file and glide can fetch everything for you.

----

1. https://github.com/golang/go/issues/4594#issuecomment-660733...

2. https://github.com/Masterminds/glide

The lack of generics is the only real pain point I feel with Go, but it's not for trivial integer functions--rather for larger data structures, like various kinds of trees. Of course, it's silly to think Python "does it better", Python has no typing at all, which you can do as well in Go via `interface{}`, and there are data structures libraries which do exactly this, but you pay a performance cost (probably still faster than Python).

Compared to Python, Go severely lacks expressive power.

TL;DR: Go is a language designed for nobody, no matter what niche you try to fit it into it's missing some feature that's desirable in that space.

You. I'm extremely happy with its trade-offs, with the only thing I really miss being generics. Most other things people complain about Go I find refreshing like standardizing on vendoring, static compilation, no "expressive" bs to stroke a programmer's ego while producing potentially harder to read/debug code and so on.

i've moved from python -> go for server backends & some personal command-line tools, and couldn't be happier.

i still use python for interactively for figuring stuff out, but for anything big enough to be saved to a file, i'll reach for go.

ymmv!

Expressive translates to "easier to read".

Having 100 lines of very simple procedural statements to accomplish what an expressive language does in 5 higher level lines doesn't make the 100 lines easier to reason about or maintain.

At worse it makes reasoning about their memory/speed beahavior harder -- but when it comes to reasoning about their functionality and the correctness of your program it's orders of magnitudes easier.

but on the other hand, having simple code where it's easy to point at each bit and say 'that does this, that goes here' can also make code easier to understand.

for me personally, on balance, the latter wins outweigh the former losses when going from python -> go. i'd say it's probably a small bump down in expressiveness for a large jump up in 'look and know what it does'-ness.

(it's not like go is really missing that much that python has -- maybe list comprehensions (which are great!), tuples, and generators?)

it'd be fun to do some empirical investigation of these things. take some toy problem, code up idiomatic, by-the-language-advocates solutions, and then throw them at large groups of people asking them to make some change, or fix some deliberately introduced bug, and see how the #s came out. :)

python reads like pseudo code and is arguably the most readable language out there.

C has more expressive power than assembly and is also more readable.

I guess that depends on who is practicing.

"You cannot pay people enough to carefully craft boilerplate code" (quoting the founder of Jane Street). When you glaze over while reading boilerplate, or wearily copy-paste when you write boilerplate, the chance to make an error grows significantly.

This used to be a problem with Java (and still partly is), despite static typing and top-notch IDEs.

It's sad when a new language suffers from that, too.

OTOH, it took Java 8 years to introduce generics. Go just need to mature a bit (not ironically; it needs to sort out less ambitious technical issues first).

Python can be friendly, but in practice people frequently use Python's magic features for everything. Go reigns people in, which can be a burden for some, but I appreciate the predictability.

If you need even more, check out http://coconut-lang.org/

[0] http://mypy-lang.org/

edit: Also, everyone, and I mean ev-rey-one that writes more than 12 lines of Python code a day needs to be using PyCharm. Navigation, inference, type safe refactoring, pure gold.

This is the exact rational behind type hinting.

  my Int $a = '3';
  Type check failed in assignment to $a; expected Int but got
  Str ("3") in block <unit> at <unknown file> line 1

http://blogs.perl.org/users/zoffix_znet/2016/04/perl-6-types...

Doesn't Python have any type checking system available s a module?

I was thinking of using Typed Clojure, but the advantages would unfortunately not translate to the libraries that I use.

It is not completely impossible. For example, Erlang / Elixir, two other strict dynamically typed languages have had Dialyzer for years:

http://learnyousomeerlang.com/dialyzer

You annotate your functions with types they accept and return. Run this tool and it shows inconsistencies. The more you annotate and the more precise the types, the more helpful it is. This is not Hindley–Milner types here (this is actually called Success Typing), but goes along way to do what you suggest i.e. you can have your cake and even eat some of it ;-)

Python now has mypy, that I understand is rather similar. Guido at least is rather fond of it. But it is still new and I haven't yet heard of it used in real world:

http://mypy-lang.org/

https://news.ycombinator.com/item?id=12065217

It is a great tool to play with new languages and features.

Thanks!

I don't understand this complaint about Go. Either a function can result in an error or it can't. If it can result in an error and you don't handle that error, your program's behavior is undefined. Undefined behavior is a bad thing.™

Go forces you to handle the error (or explicitly ignore it). That design choice results in remarkably stable programs.

I completely fail at writing rust, but their implementation of error handling is much nicer.

Want to call a function, returning the error up to the caller on error? Instead of

  res, err := somefunc()
  if err != nil {
    return err
  }

  let res = try!(somefunc());

  let res = somefunc().unwrap();

  let res = somefunc().expect("somefunc broke :(")

But that isn't really forcing you to do anything. There are 3 ways you can deal with an error: handle, ignore, or panic. In many cases go programs ignore errors when they really should panic.

It is disappointing that the go "equivalent" that you often see in examples is

  res, _ := somefunc()

rust makes it impossible to ignore the error, while also making it easy to skip error handling if you just want to abort on failure.

if I could write code in go + rust generics + macros and not have to deal with the lifetime borrow checking crap, I would be so happy :-)

You might like OCaml. It's easy to write like Go but with a much more useful type system. Downside: concurrency is not as pleasant as in Go… at all. Then again, I see a lot of things written in Go that aren't particularly concurrent and just happen to use Go because the author wanted a moderately high-level compiled language with automatic memory management. OCaml is excellent for those.

(…Once you've used it for a bit. I admit it looks kinda weird at first.)

I recall Reason didn't yet support some important part of OCaml syntax, but I don't remember what that was.

Though I don't dispute that Reason is a good thing—Erlang saw a lot of growth from Elixir, hopefully Reason will get people into OCaml.

I agree; I find Reason to be a completely pointless project except if Facebook hopes to fracture the OCaml community.

But yeah, I also don't think the Reason syntax is that massive of an improvement: https://xivilization.net/~marek/blog/2016/05/19/reason-lets-...

  if err := someFn(); err != nil { return err }

  if err := someFn(); err != nil { panic(err) }

  intval = convert("42").unwrap()

  if intval, err := convert("42"); err != nil { panic(err) }

  intval = convert("42")

  intval, _ := convert("42")

intval := mustConvert("42")

in go, but 'must' type functions don't exist for every method in every library.

  match somefunc() {
    Ok(res) => res,
    Err(e) => return Err(e)
  }

  res, err := somefunc()
  if err != nil {
    return err
  }

Also, while I don't really know Go, doesn't

  res, _ := somefunc()

Correct, with the minor note that it of course depends on your usage. If `res` is a pointer, any usage of it will panic because you ignored the err

This would be an absolutely terrible Go programmer. Like "I only log in as root to avoid typing sudo and my password" level retarded.

  func magic() (int, error) {
    a, err := foo()
    if err != nil {
      return 0, err 
    }
    b, err := bar()
    if err != nil {
      return 0, err 
    }
    c, err := baz()
    if err != nil { 
      return 0, err 
    }
    return a + b + c, nil
  }

  func magic() int throws SomeException {
    return foo() + bar() + baz()
  }

It's the multivalue return semantics that's the problem here. It's impossible to chain multivalue functions together to write anything succinctly. Worse yet, it's easy to simply ignore the error and create latent bugs because the first return value (which you're probably not ignoring) now has a "zero-value" which can be semantically valid. Whereas if I simply didn't catch the exception, it will be caught, perhaps by main(), but it will be caught, and I won't be populating my data structures with gibberish, which I can very easily do with Go.

  "It's impossible to chain multivalue functions together to write anything succinctly"

Thus _you_ can choose the best approach based on _your_ needs. The following are _both_ examples of idiomatic Lua.

Example 1:

  local v, errdesc, errcode = foo()
  if not v then
    if errcode == 1 then
      ...
    elseif errcode == 2 then
      ...
    else
      error(errdesc)
    end
  end

  local v = assert(foo())

  local v = assert(foo(assert(bar())))

There are some errors that Lua will always throw, like memory allocation failures. These can be caught like any error, and the Lua VM is never put in an inconsistent state. But they're an example of the kind of non-specific error where you normally only catch them, if at all, at some logical transactional boundary--an image transformation in a photo editor, or a client request for a web server. Lua is, notably, one of the few scripting languages where allocation failure is recoverable. And rather trivially recoverable, in fact.

EDIT: error() is a specialized built-in: it's how you "throw" in Lua. But it will throw any value, not just a string.

Go is an interesting language when you have a project with dozens of developers, because it explicitly, by design, does not let you introduce any concept of "your needs". Go is not ashamed of the fact that it has one way of doing things, and that way is rarely elegant. But it _is_ effective.

My argument was only that multivalue error returns are not necessarily so limiting. Rather, IME they're a great compromise that can permit the best of both worlds. I always wondered why Lua's idiom was never picked up by Go. So much of Go seems lifted wholesale from Lua, or at least a shared ancestor. Particularly Go's goroutines, lexical closures, and how cleanly they interoperate; both of those constructs are much more limited in languages other than Go or Lua because of shortcuts taken to simplify the [pre-existing, broken] implementations (e.g. JavaScript and Python). But especially Go's exception mechanism, with syntax and semantics likewise almost identical to Lua's.

  a, err1 := foo()
  b, err2 := bar()
  c, err3 := baz()
  return a+b+c, errs.Combine(err1,err2,err3)

Lol, I thought a long time about how I could express that feeling. now I understand, in Go the developer is doing the compiler's work ...

So:

     if x, err := foo(); err != nil {
       return 0, nil, err
     }

     x := check foo()

    if err != nil {
        return "", 0, err
    }

    return myStructType{}, nil

If all of the exception handling code is at the end of the block, you lose context (which of the three file opens the this FileNotFoundException), scope (every variable you want to use during cleanup has to be declared outside the try, initialized to a sentinel, and then checked in the catch to be sure the try initialized it to the real value), locality (the code, the error handling, and possibly the finally block all deal with the same things, and should be in sync, but are spread out), and more...

Error codes are verbose, but exceptions have issues to.

Neither one is ideal for me but error codes are the lesser of two evils for the time being.

Sometimes you don't care about the context. You can have middle-ware code: [top level code]<->[your code]<->[library]. Maybe you don't care if library throws a "disk full" exception or "network down", littering that part with "if err != nil ... " might not be the best solution. Top level code might decide to log the error, retry, retry and log, send a page, or even just let another layer on top of it decide.

But as you say it is a trade-off. At lest Rust provides a neat try! macro, it goes a long way in handling boilerplate.

   let mut f = try!(File::open(filepath));
   let a_byte = try!(f.read_u8());

I like seeing which parts of my program can fail, and I want to be forced to consider what should happen in different failure scenarios.

I like explicit error handling because not only is it obvious where my program can fail (and why), but it is obvious where it can't fail too.

With exceptions, any line of code may fail. Or maybe not. It is all invisible.

(Now this assumes a language that enforces return code checking; I use C and a static analysis pass today, but a few languages get this built-in).

> You can think of error handling as using case analysis to determine whether a computation was successful or not. As you will see, the key to ergonomic error handling is reducing the amount of explicit case analysis the programmer has to do while keeping code composable.

Yes, handling errors is important and should be done, however it need not result in a block of text that people just skim over and that is easy to get wrong.

[1] https://doc.rust-lang.org/book/error-handling.html

Is there a more elegant way to handle errors in a concurrent language than returning error values? In general, exceptions do not work well within async programming. Too many JavaScript developers use exceptions and I advise to return errors instead. At least Go is consistent.

Exceptions do work well with synchronous programming, which is Go's model.

Can you elaborate on this? This doesn't seem true. For example, see Hello World: fmt.Println returns an error, which is implicitly ignored.

No, it doesn't. For example: https://play.golang.org/p/jGMmsaorez

Python is safe by default because you don't need to actively look for errors: when an error happens and there is no exception handling code you get a traceback, and the only way to ignore an exception is explicitly writing an (in)appropriate exception handling cause.

The problem is handling the error every time the function is called in the same place it is called and adding extra visual noise to the business logic.

Other ways to handle errors:

* Throw an exception. Program for the default happy path and throw an exception if something ... exceptional happened. This way code is not littered with 50% error handling which makes hard to read understand what it should be doing "normally". There is a trade-off there. But this has been implemented badly in other languages C++, Java and Go writers probably looked at that thought "No, way" and threw that idea away. I think Python does this right and it greatly goes to simplify code.

* Crash the goroutine (panic?). It is a bit like an exceptions but it applies to systems with concurrency units (goroutines, threads). However, in general that might not work as well because of two things -- shared memory, you can't just restart or assume a crashed goroutine hasn't scribbled over the heap memory, somehow or left data in an inconsistent state. And the other thing is goroutines don't have identifiers. so you can't say, I want to know if goroutine x crashes, then I want make sure y crashes as well, or I want to restart goroutine x and try again. But, that is not Go, that is Erlang / Elixir. Once you have seen process monitoring, linking, supervision trees and how they result in shorter, clearer code and less operational pain and suffering, it is hard to go back.

(Also if this sounds so alien and crazy, think about OS processes. A program has a pid. You can kill it using a pid, restart it. You know it hasn't scribbled over memory and messed up with other programs. This what sane operating systems do it has been this way for many decades, early Unix and then NT on windows. Other languages basically behave like Windows 3.1, which is cool, but is 1995 cool, not 2016 cool).

Should also mention Rust probably as well. Rust does a good job handling a lot proving there won't be data races at runtime between threads. Restarting a thread there is not as dangerous. But from what I guess still kind of awkward in the code. But even for the case explicit error handling, it has the try! macro which goes a good to visually simply the code. It does this because it decided that functions can return an agreed Result type which can be an ok value or an error. If it returns an ok, it passes the value along to the code that called, it if gets an error it returns early with the error. (Here it assumes both the caller and callee return Result. I don't know much about Rust so this might all be wrong, if anyone knows better please correct this ^).

I don't understand why "Go forces you to handle the error (or explicitly ignore it)". I find [a sample program](https://gobyexample.com/writing-files) and remove all the error checking code. Nothing unlike in Python happens. It compiles without warnings (even C can warn you about not using returned values).

I can see how Rust forces people to either handle the error, or explicitly ignore it. When you forget about it, it just doesn't compile.

There are way more advanced ways to handle errors than if err != nil boilerplate.

In before: Unchecked exceptions that I can forget about instead of always handling the errors gracefully or consciously pushing down the stack.

Not any more than you can forget about the returned error code in Go (val, _ := foo() etc). But with all the added convenience of exceptions.

What you'd seem to describe, and which Go lacks, are Optionals that you have to handle for every option.

And lots of other schemes (even Conditions).

I'm pretty sure that's an underscore right there, that very explicitly means "I'm consciously ignoring this error". Not sure what you're talking about with Optionals and Conditionals. Errors in Go are in the end structs that satisfy the error interface. That doesn't have to be an errors.Error, you can implement your own to satisfy more complex needs.

Unless you have very specific requirements for that one line, you don't go writing code like:

    case f x of
        Nothing -> Nothing
        Just y -> case f y of
            Nothing -> Nothing
            Just z -> z

    do
        y <- f x
        fy

Mind rewriting

       do
        y <- f x
        fy

say with an example like response, err := http.Get(someURL)

How would this example look like in haskell if error handling is abstracted away?

    resp, err := http.Get(someURL)
    if err != nil {
        return nil, err
    }
    res, err := DoStuff(resp)
    if err != nil {
        return nil, err
    }
    return res

    do
        resp <- http.Get(someURL)
        DoStuff(res)

    resp, err := http.Get(someURL)
    if err != nil {
        return nil, err
    }
    return DoStuff(resp)

    do
        a <- operation1
        operation2 a -- This one returns nothing
        b <- operation3 a
        c <- operation4 b
        operation5 c

    from math import sqrt

    def f(a):
        if (a >= 0):
            return (True, sqrt(a))
        else:
            return (False, None)

    def do(a):
        (ok, y) = f(a)
        
        if ok:
            (ok2, y2) = f(y)

            if ok2:
                return (True, y2)
            else:
                return (False, None)            

        else:
            return (False, None)

    
    # example
    for x in [2, -2]:
        (ok, y) = do(x)

        if ok:
           print("Result: {}".format(y))
        else:
           print("Calculation failed.")

    # Output
    >>> Result: 1.189207115002721
    >>> Calculation failed.
     

    import Control.Monad (mapM_)

    {- 
       Maybe Double represents a computation that either
       returns a Double or fails. In this case, fail
       when passed a negative number. Note: this is not
       the same as throwing an exception.
    -}

    f :: Double -> Maybe Double
    f x
      | x >= 0 = Just (sqrt x)
      | otherwise = Nothing

    -- Fleshed out version of OP's snippet
    eval :: Double -> Maybe Double
    eval x = do
        y <- f x
        f y

    {-
       do notation desugars to monadic binding; in this
       case eval can be desugared to the equivalent definition:
          eval x = f x >>= f
    -}


    -- Here's why this is convenient, because you can pattern match
    printIf :: Show a => Maybe a -> IO ()
    printIf (Just x) = putStrLn $ "Result: " ++ show x
    printIf Nothing = putStrLn "Calculation failed."

    -- This is basically the equivalent of the Python for loop
    main :: IO ()
    main = mapM_ (printIf . eval) [2, -2]

    f <$> f <$> x

    f x >>= f

By the way, is this the Civilization III armor? I never knew what model they got the image from. It is British... I always expected it to be German for some reason.

I thought we killed this notion already but it still seems to be lurking around. It doesn't support volatile, doesn't let you specify what goes on the stack vs heap(or pin anything for that matter).

Great for web services? Sure. Low level C replacement? Nope, for my money that's Rust.

Go is a fully GCd language with lexical closures. All memory is automatically released when it's no longer _referenced_. So the distinction is irrelevant.

As for volatile, it doesn't really do what most people think it does. volatile prevents _logical_ loads and stores from being moved. What that means for when you're dipping into assembly can vary from compiler to compiler. For typical code the volatile qualifier is only relevant when using setjmp/longjmp, for signal handlers, and in the C11 standard, for some kinds of threading.

In design and spirit I think Go is very much the successor to C. Though, I've never written a line of Go in my life and code primarily in C most days, so I'm only half informed. But if you look at the history of both C and Unix, they were never about performance, per se. What distinguishes them is ease of implementation, ease of portability, and a philosophy of achieving _easy_ performance gains by shifting a subset of hard problems onto the caller (the so-called "Worse is Better" theory). Thus, C was designed so that it could be compiled in a single pass (without an AST). Similarly, one of the reasons the Go compiler is so fast is because of very intentional language design decisions. Those approaches result in all manner of unintended consequences in addition to the intended consequences, and it's important not to conflate the two.

I don't think you can compare a GC memory model with heap/stack. There's a sliding scale of tradeoffs that you get from a fixed stack -> heap -> GC. There's also a set of hardware out there that doesn't have a unified memory model. There's millions of these types of devices out there in your set-top box, game console and many other places. If you don't have direct control over memory you'll never be able to work with them and will always need a C/C++/Rust wrapper around the low level bits.

Lastly, I'd never want to use volatile for threading[1]. There's no memory barrier semantics, instruction ordering semantics(aside from with other volatile reads). If you need thread synchronization you should to use the platform specific atomics otherwise you're in for a world of pain(and god help you if you're going from x86-win32 -> ARM, there's an implicit memory barrier in x86-win32 that most people don't know about).

[1] Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering. A read from a volatile variable that is modified by another thread without synchronization or concurrent modification from two unsynchronized threads is undefined behavior due to a data race. - http://en.cppreference.com/w/c/language/volatile

I've used it a few times when a library needs to initialize some [very simple] global state, but where I didn't want to require the application to always link in libpthread. Even on Linux that can be an issue for dlopen'd modules. glibc has bugs when late binding libpthread, and some BSDs don't even pretend it works (it just fails loading outright).

It was supposed to, but quickly after release they "pivoted" (is the correct usage of the term?) by rephrasing a bit what "systems" are in "systems languages". I don't quite believe that out of all people, Rob Pike, didn't know what "systems languages", but anyway, it was meant to be replace C, C++ I think, but ended up attracting more of a Python, Ruby and some Java crowd. A lot of Java people I know who ended up using it, had mixed feelings, mostly due to lack of generics (sorry that is a belabored point and mentioning it will probably leads to banning from go language forums at this point). A lot of Python people I know enjoy Go, mostly to do better perceived performance and also ease of deployment.

A language does not have to replace C to be "low level". You sound like the type of person who, thirty years ago, would argue that C isn't low-level because it isn't assembly.

For me the dividing line is if your language abstracts away memory management. If I don't get control over where memory lives and how I access it not low level.

PC is this nice homogeneous memory structure but there's many systems that have specific semantics around different address spaces and you may need to be able to access and manipulate them in specific ways.

I don't have experience with Go beyond reading some snippets, but the Asciinema developers clearly developed with it and they seem to think it so. It's not some notion going around but something an (at least moderately) experienced developer says.

I'm not saying they must be right, they might simply be more experienced in Python and prefer Python because of that, but I don't think it should be dismissed as "some notion that's still going around".

Edit: You just got downvoted it seems; I didn't.

Low level is a very ambiguous term, for some it simple means anything to do with CLI. For others, it means kernels, drivers, etc.

It's more that Go keeps getting held up as a replacement for C without understanding what makes C/C++/Rust viable in their domains. It's all down the the memory model and if you don't have control over that then it isn't a replacement.

Take volatile for instance, there's certain pieces of hardware that you'll never be able to use Go for without wrapping some parts of the hardware in C because there's fundamental memory IO semantics that volatile provides but Go doesn't support.

I know it wasn't intentional, but this change feels like a huge FU to users. If I'm forced to use Asciinema again, I'm going to have to resort to using it from from within a Docker container where the mess is, at least, sandboxed, but that option has its own drawbacks.

    pip install asciinema

https://hub.docker.com/r/ontouchstart/asciinema/

The majority of comments are fair, although I'd disagree with it being C2.0 and err != nil getting old - I much prefer it to exceptions.

In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.

If I had any complaint it would be that go could offer some way to setup default handling that simply returns zero and error for any unhanded errors.

I know the same thing can be done with try, catch finally but then you have the same problem of needing to know what errors may be returned so you can make sure an wrap that call in a try statement.

  result, _ := thirdparty.ReturnsError()

With that said though, i have a hard time understanding complaints like:

> if err != nil { gets old even faster.

I may be biased, because my time in frontend JS land, but i love checking errors every time. It's a language feature to me.

Ignoring errors and expecting something else to care and catch/handle them is just.. worrying to me. Likewise,

  try
    .. stuff ..
  catch
    .. stuff ..

Have you ever checked out Maybe (http://learnyouahaskell.com/a-fistful-of-monads#getting-our-...)?

Go also has most of the listed libraries(like http, arg parsing, json) included in stdlib. I'd argue that the the http library in Go is one of the best out there :)

Can't disagree about dependency management, hopefully it gets addressed sooner rather than later. There was a good discussion with the Go team on the topic at Gophercon today.

How many Go package managers out there ? that's right that's the problem. Why invest in this one when most of the community don't use it, don't even tag their releases properly, and frankly just don't care about anything not in the core library or not written by Go maintainers? this is a fucked up situation. I read in this thread that Go is "battery included", well no, it has a few percs and a lot of issues.

Go maintainers "We are very opinionated about things but somehow we let the community handle package management because we delivered an half backed one (go get) that fits our needs and we don't care about yours" are a joke.

Maybe Go would be well served by a well written package manager. Maybe. But I've never seen one that makes the process unequivocally better. go get really is good enough for the simple case, which is, 99% of the time, what people want.

For me, huge complex dependency graphs are a big code smell. I get concerned whenever I see a program that pulls in lots of very large dependencies using a very fragile mechanism (example: Pip/setup tools) it bothers me.

My question is, what would "fix" the situation for you? A pip-style package manager? Because go get has all the important features (in my opinion) without all the pain that comes from such a complex tool. I admit that a lack of semantic versioning is a major pain point right now, but that's only because the go community hasn't found a good solution, in my opinion. But I've actually been working on that particular problem and I think I've nearly solved it. It's just a matter of time before someone figures it out.

[0]: https://github.com/cheggaaa/pb/pull/55

Worth noting that Go has `flag`, `json`, and `http` in its standard library, and they're all much higher easier to use than the Python equivalents. In Python, you unmarshal your JSON into a dict or list and then write a function to convert it into the right object while making sure the structure is correct. With Go, the library does the right thing out of the box.

But I will say that 'flag' isn't even _close_ to being comparable to argparse. flag is, like, the bare minimum you would need to write a command line application that accepts flags and generates help text. There are dozens of libraries for Go that more closely resemble argparse because flag's capabilities are so limited.

It's a shame Go's flag package is so poor. Even Docker, who seem to be hugely invested in Go, say "seriously just don't use it". [1]

[1] http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...

Completely understand their reasons. Nothing wrong with Python for what they're doing.

https://github.com/ontouchstart/grs/commit/39d04916ffd678d50...

It seems that

go get github.com/asciinema/asciinema

only downloads and installs the code from the default github branch which is now Python codebase. Fortunately they keep the golang code in a golang branch.

Although my repo is just a sandbox to study how to explore and learn bleeding edge technologies, unfortunately it also shows how fragile our github centered software ecosystem is becoming.

The Python runtime is relatively poor (slow and limited by the GIL) but the language is extremely popular [1].

Is there any other language which is a "best of both"?

[1] https://news.ycombinator.com/item?id=3746692

This constrains the space quite a bit. Languages significantly less popular than Python are excluded by definition [1]; languages subscribing to very opinionated design decisions or too low-level (like C) are also excluded by definition.

This only leaves Java, C++, Python itself, and Javascript. If you run Python on a JIT runtime like PyPy [2], you'll probably achieve significant speedup.

Erlang, Elixir, Scala, Clojure, languages that also have good approaches towards concurrency are not very popular in the greater scheme of things.

[1] the TIOBE index is an imperfect measure of popularity, but let's use it here -- http://www.tiobe.com/tiobe_index

[2] http://speed.pypy.org/

So, thank you for listing some less-popular languages as well. Unfortunately, of all 8 languages listed in your post, is C++ the only one which can produce standalone binaries and thus match the easy deployment of Go?

I find this quote quite surprising if he speaks about Go. As long as your customer got Python (with the right version) and all of the dependencies installed, everything is fine. But if you bring 3rd party dependency (say.. requests?) you are in a world of pain. If you add non-pure python dependency that's even worse.

While with Go, you just need to compile your stuff? (assuming your libraries support your target system)

Am I missing here something?

Authors cite superior support for tty on variant archs. But by using golang as the central pipeline manager, calls to jsdom or PIL or ffmpeg simply become another stage in the pipeline. Any number of Python microservices can be composed, while retaining golang as the glue providing timeouts, sync, etc.

Still, whatever works for the Asciinema is OK in my book. Great service and will be recommending to all!

EAFP gets older even fasterer.

> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.

This SO answers it nicely: http://stackoverflow.com/a/11360880/6189743

    try:
        bar = dictionary['foo']
    except KeyError as ex:
        # handling

    bar = dictionary.get('foo')
    if bar is None:
        # optional handling, None might be OK

    bar = dictionary.get('foointeger', 0)
    # now you don't even need handling

That addresses the specific case mentioned, of course, but not others. Occasionally you do have to handle exceptions but this almost always revolves around I/O, and you can isolate those portions in well-defined types that expose functionality to the rest of your program instead of trying every few lines.

The place to use EAFP in this example is in dict.get itself:

    def get(self, key, default=SENTINAL):
        try:
            return self[key]
        except KeyError:
            if default is not SENTINAL:
                return SENTINAL
            raise

I absolutely love Python's exception handling, and I strongly subscribe to EAFP (not just in coding, even), but I rarely use try/except, because most of the time your business logic (where I spend most of my time) should be delegating to something (external/internal library, etc.) that handles exceptions, rather than littering your business logic with low level logic.

I'm reacting to the explanation of EAFP using that example. And no, Python's implementation does not do that, since (a) I'm almost positive dict.get is not Python and (b) your code is quite obviously incorrect.

You sho-bout that?

https://repl.it/Cbu8/4

If you're new to programming, you can learn a lot more by listening than by arguing.

    >>> {}.get({}) is None
    TypeError: unhashable type: 'dict'

    >>> {}.get("key") is None
    True

    >>> {}.__hash__ is None
    True

    >>> "key".__hash__ is None
    False

    def get(self, key, default=None):
        try:
            return self[key]
        except KeyError:
            return default

    def get(self, key, default=None):
        return self[key] if key in self else default

If you're speaking with someone new, you can learn a lot more by not condescendingly assuming competence of the other party, particularly when they correctly spotted those three problems and you didn't. I trust this reply will alleviate the misconception.

[0]: https://github.com/python/cpython/blob/master/Objects/dictob...

[1]: https://github.com/python/cpython/blob/master/Objects/dictob...

I don't know what typo my first example has (the bug you mentioned), but the point is to teach you about the value of using try/except in abstraction, rather than littered throughout your code.

Despite our alpha mentalities, we are not worlds apart, truthfully. My original response came across sounding hardliner pro-try-except, anti-anything-else, but my point was only that people abuse exception handling in their primary business code (e.g., directly handling a network IOError in a Django view). As a result, they have a bad time. Libraries and utils should be relegated to exception handling duties like that. When following principles like developers love Python's try / except blocks for their clarity.

Do not project your "alpha mentality" onto me, please. I am the polar opposite of "alpha." That was all you.

You were wrong, and I didn't stoop down to assuming anything about your competence as you so desperately tried to get me to do. Instead of blaming wine like a child, you should probably objectively look at yourself and your judgments of people. Your attitude is not uncommon, and I specifically look for it when I interview.

I'd have a lot more respect for you if you'd own the mistake, but I can tell that you're not going to, so this will be my last comment in this thread as well.

1) the "except" semantics help hit home the point you expect the key to be there most of the time

2) in cases where the exception will rarely be raised, the "try ... except" route runs faster than the ".get() ... if" route.

Through a link in your link you get: "Look before you leap"

Also, i did not complain at all - i was confused and posted it to help others. You start off assuming i had negative intentions, and i don't appreciate that. I was simply helping.

Granted I should've done it with Celery to begin with, but I think that's part of Go's problem it lures you into using it when you probably shouldn't.

https://github.com/asciinema/asciinema

There's very little code there; porting from scratch would take a few evenings. I wouldn't extrapolate too many conclusions from this.

I don't understand the rationale here. Why would a linux distro reject a package that incorporates all of its dependencies, thereby becoming dependency-free?

https://lwn.net/Articles/660429/

https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packagin...

To leave Python means there were some kind of problems with it?

How are those problems being addressed now?

...or was this always a political/personal preference thing?

They drank the Go Koolaid, like many others, and then came to their senses. Go isn't a silver bullet, it's a trade off,like everything else. Speed is nice. Go is fast. But when you're codebase becomes full of "if err!=nil {" , it starts getting ugly.

Go has showed there is a place for a safe C in Python's clothes. Go just doesn't fulfill that idea though, the language is too rigid to be enjoyable for a lot of people.

"if err != nil { gets old even faster."