17 ms·

Asciinema 1.3 Switches from Go Back to Python

• vvanders 10y ago
  > Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). 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.
  • lucb1e 10y ago
    > I thought we killed this notion already but it still seems to be lurking around. 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.
    • vvanders 10y ago
      Yeah, not knocking their choice in Python. I think they made the right evaluation there. 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.
    • jackmott 10y ago
      Very many developers today do not fully understand what low level means, so very many things get called 'fast' or 'low level' or 'C-Like' that really are not.
    • lgunsch 10y ago
      Until you can load up Go code on a microcontroller, or build an OS kernel in it, it is not going to replace C in many circles. Go is also garbage collected, which rules it out for being low by some definitions of "low level". Low level is a very ambiguous term, for some it simple means anything to do with CLI. For others, it means kernels, drivers, etc.
      • collyw 10y ago
        C used to be considered a high level language a few decades ago.
  • 010a 10y ago
    Go is far lower level than Python, which makes the term "low level" fine. Its like calling some color swatch "black" then arguing "that's not black _enough_ to be black". Any definition we give for an absolute term like that will be fundamentally arbitrary, but we know right from wrong when we see it. 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.
    • vvanders 10y ago
      Notice I'm being careful to mention semantics not performance(although those semantics largely help with the latter). The ASM<->C bridge is much smaller since you're talking about registers and possibly custom instructions that are usually exposed via intrinsics. 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.
    • justinsaccount 10y ago
      I don't think go is much more low level than python, to me it is just much more explicit and verbose..
    • ssebastianj 10y ago
      Yeah. As a side note, I remember what Steve Klabnik once said: "Basically, Go is like a lower level Ruby or Python and Rust is like a higher level C or C++".
    • douche 10y ago
      Is Go a low-level language, or a slightly lower-level language? Woodhouse, fetch a rug!
  • wahern 10y ago
    C doesn't allow you specify what goes on the stack or heap, either. The "stack" in C is called automatic memory. What differentiates automatic memory is that it's automatically released when it falls out of scope. But it can very well be allocated using the same machinery as malloc. Yes, it behaves in some sense like a logical stack, but it needn't reside in some sequentially allocated storage, and the order of allocation or deallocation of objects in the same scope is completely undefined. Indeed, clang supports a mode with two "stacks", so that buffer overflows of automatic array variables can't easily overwrite function invocation bookkeeping. 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.
    • vvanders 10y ago
      I don't think you can conflate intent with real world application. Certainly they didn't intend for Javascript to take over the server-side world when they built the language. 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 http://en.cppreference.com/w/c/language/volatile
• antirez 10y ago
  Not related to the language switch, but I just want to say that I love Asciinema. Thanks to it I do small screencasts where normally I would be totally discouraged about the amount of work needed in order to really record a portion of the screen and upload a video recording. For people that want to show most of the times terminal based things (i.e. programmers), it is a zero-friction way to show an interactive session. Thanks for building it.
  • fitzwatermellow 10y ago
    I actually discovered it from your post the other day, antirez. The CLI thingy. And I concur. It is a truly wonderful tool I will be using extensively: Docker inits, first N steps in spinning up an instance, setup devenv and build first "hello world," and much more ;)
  • ontouchstart 10y ago
    I also discovered it from your blog post the other day. https://news.ycombinator.com/item?id=12065217 https://news.ycombinator.com/item?id=12065217 It is a great tool to play with new languages and features. Thanks!
  • kevin_thibedeau 10y ago
    I'm not so fond of the fact that recordings are served through ascinema.org. There are alternatives like ttyrec + tty-player that work just as well and don't depend on external servers.
    • shritesh 10y ago
      They can be self hosted as a JSON file and use the open source JS library to embed it
  • absorber 10y ago
    It's really great, although I wish the overlay feature will get added soon: https://github.com/asciinema/asciinema/issues/105 https://github.com/asciinema/asciinema/issues/105
• ryanlm 10y ago
  Python is the best high level language out there. I wouldn't call golang C 2.0 because it has a GC.
  • duaneb 10y ago
    I mean, unless you want it to run quickly. (The above statement is obviously absurd; I love python)
  • collyw 10y ago
    Nah, Perl.
• percept 10y ago
  This is a perfectly reasonable analysis of why a particular language choice didn't fit a particular project, without a lot of hyperbole or boosterism.
  • smegel 10y ago
    It would have been even more reasonable if they did the analysis before switching over the entire code base.
    • Scarbutt 10y ago
      sure, but you underestimate that lots of devs might learn something from this article.
      • sickill 10y ago
        Yup. People asked me to write this post as they were genuinely curious. I also think it adds something to our collective knowledge.
    • sickill 10y ago
      We did. But you see, theoretical analysis doesn't always produce accurate result and you won't learn about practical issues until you get your feet wet. Also, like I said in the post, it turned out to be not great choice for combination of this particular project AND me.
• cocotino 10y ago
  >if err != nil { gets old even faster. EAFP gets older even fasterer.
  • fizzbatter 10y ago
    For anyone needing explanation like myself: > 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 http://stackoverflow.com/a/11360880/6189743
    • jsmthrowaway 10y ago
      And as that comment correctly reminds us, .get()/getattr/etc exists for that very reason and I will almost always reject a code review that trys such an operation instead of using .get(). Don't do this: try: bar = dictionary['foo'] except KeyError as ex: # handling Do this: bar = dictionary.get('foo') if bar is None: # optional handling, None might be OK Or this: bar = dictionary.get('foointeger', 0) # now you don't even need handling You avoid scope issues with the try block, stack unwinding, all sorts of issues. This works for attributes too with getattr(). It is quite easy to work in Python without try/except, for the most part, especially if your types are well-built. 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.
      • mangeletti 10y ago
        You're confusing improper lack of abstraction with error handling methodology. 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 (made-up implementation ^ I'm not sure if Python's stdlib actually does exactly that) 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.
• fizzbatter 10y ago
  It's funny, when using C++ or Rust, Go feels like my version of Python/Javascript/Etc. There's something very appealing of it to me.. it's the NodeJS of the Typed world to me, and i love it for that. Granted, i'm trying to switch my codebases to Rust, but still - i can't imagine going back to Node/Python/etc. But to each their own, i'm not foolish enought to say i'm "right". 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 .. Gets far older to me than `if err != nil {`. But that's just me i suppose.
  • framp 10y ago
    Both gets fast really soon. Have you ever checked out Maybe (http://learnyouahaskell.com/a-fistful-of-monads#getting-our-feet-wet-with-maybe http://learnyouahaskell.com/a-fistful-of-monads#getting-our-...)?
    • mrcoleman 10y ago
      I found this guy's description of the Either monad to be rather good https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/
• knodi 10y ago
  "if err != nil { gets old even faster." This never gets old builds rock solid stable services. Completely understand their reasons. Nothing wrong with Python for what they're doing.
  • deleted 10y ago
    [deleted]
• JamesMcMinn 10y ago
  I'm left wondering why the switch was made in the first place. I spend about half my time coding in Go and love the language, but if I wasn't looking for easier concurrency or a speed boost, I wouldn't re-write an existing code base in Go. It's a lot of work to do just to revert a short time later. 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.
  • ben_jones 10y ago
    I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be familiar with every possible error a given method call can throw. To complicate the issue error messages are often cryptic, to the point where even if you do catch it it is an entirely pointless exercise. In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.
    • JamesMcMinn 10y ago
      Go was essentially designed with the idea that you shouldn't ignore errors. However, if you really don't care about errors, you can simply ignore them: result, _ := thirdparty.ReturnsError()
      • ketralnis 10y ago
        That ignores the error but then silently does the wrong thing when one is thrown. That's different to exceptions where you bail the function instead of proceeding as if nothing went wrong
    • clinta 10y ago
      Most of the time I end up writing if err != nil { return nil, err }. This seems better than a simple panic to me it allows the function to return, executing any deferred functions and doing any necessary cleanup. 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.
• mac01021 10y ago
  > they don’t like vendored (bundled) dependencies (also understandable) (Gentoo example) 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?
  • gtirloni 10y ago
    You may read more about that rationale here: https://lwn.net/Articles/660429/ https://lwn.net/Articles/660429/ https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packagin...
• danso 10y ago
  Exciting to read this, not just because of how interesting and rare it is to hear about a project not just switching languages, but from Go to Python, but to learn that the author is invested enough in asciinema to do such an overhaul. It serves a niche purpose but it serves it really well, especially for teaching code. The recent development of a self-hosted option for asciinema playbacks made it especially useful to me.
• zalmoxes 10y ago
  > Batteries included: argparse, pty, locale, configparser, json, uuid, http. All of these excellent modules are used by asciinema and are part of Python’s standard library. Python stdlib’s quality and stability guarantees are order of magnitude higher than of unversioned Go libs from Github (I believe discrete releases ensure higher quality and more stability). 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.
  • JamesMcMinn 10y ago
    That was my initial reaction too, however I think the author was listing _all_ of the libraries used by Asciinema, rather than just the ones they had to find outside of the standard lib. Their point being that Python includes them all, so there's no need to go external.
  • topspin 10y ago
    Dependency management is what drove me away. I drank the Kool-Aid; had the language specification printed and studied it with care. What a wonderful, concise language. Then I tried to actually use it for something. That something involved a few large dependencies and although I was personally able to cope with the dependency problems, after about six weeks I concluded I was wasting time; there was no way I would ever advocate to an employer or co-worker this platform. Solid, easy dependency management and easily reproducible builds are non-optional, and Go doesn't provide either without a bunch of legwork. The folks behind Go have heard this a thousand times and it has done nothing to persuade them to deal with it. That's a no-"Go" for me.
  • jzelinskie 10y ago
    My experience with finding and using a good, terminal-based progress bar library led me down the road to fixing some termios-related issues[0]. I've yet to find many great Go libraries for abstracting the terminal in a cross-platform way. [0]: https://github.com/cheggaaa/pb/pull/55 https://github.com/cheggaaa/pb/pull/55
• sergiotapia 10y ago
  Preach it! I had a similar experience with Go. I just wasn't happy writing it. "if err != nil { gets old even faster."
  • virtuallynathan 10y ago
    I find Go to be extremely fun to write code in, although the error handling can be a bit annoying.
• hellcow 10y ago
  >if err != nil { gets old even faster. 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.
  • zalmoxes 10y ago
    People love to complain about handling err, but how is it so much different from handing Maybe and Result in functional languages?
    • JoshTriplett 10y ago
      Those languages have patterns that make Result easy to handle, without introducing exception handling. For instance, Rust has "try!", and is introducing the new "?" syntax, to turn an error Result into an early return, and make code with robust error handling feel like straight-line code.
    • marcosdumay 10y ago
      It is so much different because with monads you get the error handling automatically most of the time. 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 You write: do y <- f x fy
      • kruipen 10y ago
        Or: f <$> f <$> x
        • marcosdumay 10y ago
          Yes. Or even: f x >>= f But I think those operators tend to confuse people that don't know the language, while do notation is very intuitive (although opaque).
• ben_jones 10y ago
  IMO Golang is a C-like language toted as a Python-like language. I recently replaced a hand-rolled task-queue processing service from Go to Python + Celery and its yielded large gains so far. 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.
  • jpgvm 10y ago
    Go should be faster as a queue worker in almost all cases. If you implemented the actual queue in Go that was likely your mistake, building queues is hard. If you had defered that to something like que (Postgres advisory lock based), Redis or even AMQP it should have run circles around Python.
    • collyw 10y ago
      Celery can use AMPQ or Redis for its queues.
• TheBlight 10y ago
  I've been coding primarily in Go for the last year or so. Previously some Ruby and lots of C/C++. I actually don't like coding in it very much. It's far too much typing and boilerplate stuff. I'd love to just be able to handle exceptions and move on with my life instead of checking for errors on every other line.
• fitzwatermellow 10y ago
  Often I encounter similar instances where something fundamental is missing from golang's standard packages and no third-party library exists. 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!
• zet2 10y ago
  pray for you python journey!
• quacker 10y ago
  Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). 95% of asciinema codebase is high level code... 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-66073310 https://github.com/golang/go/issues/4594#issuecomment-660733... 2. https://github.com/Masterminds/glide https://github.com/Masterminds/glide
  • weberc2 10y ago
    I'm a Python programmer by day, and I would very much appreciate a stricter type system so it was apparent what arguments a function might accept, what arguments a function might return, etc without having to open up my browser and dig through documentation. I also love that Go doesn't have much in the way of syntactic sugar--it's absolutely obvious what everything does. For example, there's no way to overload `==` so it returns an object (looking at you, SQLAlchemy). 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).
• weberc2 10y ago
  > Batteries included: argparse, pty, locale, configparser, json, uuid, http. All of these excellent modules are used by asciinema and are part of Python’s standard library. Python stdlib’s quality and stability guarantees are order of magnitude higher than of unversioned Go libs from Github (I believe discrete releases ensure higher quality and more stability). 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.
  • 010a 10y ago
    'encoding/json' is definitely more powerful than Python's JSON package. 'http' is similar. 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.
    • bakery2k 10y ago
      > 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-decide-to-write-docker-in-go/31 http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...
• shadowmint 10y ago
  I'd love to know why they decided to move in the first place? 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?
  • spriggan3 10y ago
    > I'd love to know why they decided to move in the first place? 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.
  • sickill 10y ago
    I updated the blog post with motivations for moving from Python to Go in the first place.
• mratzloff 10y ago
  For reference, here is the code base: https://github.com/asciinema/asciinema 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.
• ontouchstart 10y ago
  It took me a while to figure out why my Docker build worked yesterday but failed today. https://github.com/ontouchstart/grs/commit/39d04916ffd678d50fd75638c1af2231f9235317 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.
• curun1r 10y ago
  As a user, I'm afraid this means I'm unlikely to use Asciinema anymore. They've left me with no acceptable installation option. Go get was clean and installed a nice, statically-linked binary. The python ecosystem is messy. Not even considering the disaster that is version 2 vs 3, an installed python program is just harder to manage as files are strewn across many directories that are difficult to understand without understanding python development. This may be fine if you're writing an application and you spend enough time with it to understand the structure and purpose of the installed files, but as a casual user, it sucks. Brew isn't much better as I've continually run into problems upgrading packages. I love the idea of nix, but gave up on it after my first few installed programs all didn't work for anything involving SSL. 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.
  • donatj 10y ago
    Yep. This. I don't write Python, don't know the ecosystem, so when something doesn't work out of the box I'm screwed. Go on the otherhand I grab a statically linked binary and I'm set.
  • mixmastamyk 10y ago
    pip install asciinema
  • est 10y ago
    TL:DR There's no way any software vendors provide statically linked Python programs, ever.
  • ontouchstart 10y ago
    Here you go :-) https://hub.docker.com/r/ontouchstart/asciinema/ https://hub.docker.com/r/ontouchstart/asciinema/
  • spriggan3 10y ago
    I use Deluge bit torrent client which is written in Python & GTK+3 , never had a problem (Windows) it's perfectly possible to deliver self contained applications with Python,or anything else.
• bakery2k 10y ago
  It seems to me that Go has very useful runtime features (speed, concurrency & parallelism, easy deployment) but the language has significant drawbacks, including those listed in this article. 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 https://news.ycombinator.com/item?id=3746692
  • est 10y ago
    People need to stop beat the dead horse. GIL? Golang does not even support multi-threading.
    • virtuallynathan 10y ago
      Go has native support for both concurrency and parallelism (the later by default as of 1.5 - GOMAXPROCS set to NUMCPU).
  • niftich 10y ago
    It seems you're looking for a language/runtime that's 'extremely popular' and has very useful runtime features like 'speed, concurrency & parallelism'? 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 http://www.tiobe.com/tiobe_index [2] http://speed.pypy.org/ http://speed.pypy.org/
    • bakery2k 10y ago
      To clarify, I'm not necessarily looking for something "extremely popular". I was using the fact that so many people consider Python to be their favorite language as a proxy for the high quality of the language design. Perhaps "popular" was the wrong word? 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?
• yandrypozo 10y ago
  Each time I read a post like this I just think in a new name for it "Why I didn't understand Go and now I have to comeback to my previous programming language ..."
  • techolic 10y ago
    Yep I was wondering too why they switched to Go in the first place.
    • sickill 10y ago
      I updated the blog post with motivations for moving from Python to Go in the first place.
• m1keil 10y ago
  "If you’re building in-house software that has to run only on single platform then many of the above points may become non-issue for you." 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?
• blubb-fish 10y ago
  ... thought this is about converting clips into ASCII animations :(
• Halienja 10y ago
  Go is a solution looking for a problem!