5 ms·

I hope this is a fruitful endeavor but I can't help but feeling the pressure to "Not have another Py2 -> 3" situation will win out and the GIL will remain. Whic

• smegel 10y ago
  Ideally Golang. No other language really does it right like Go - unifying event based and traditional multi-threading paradigms in a way that transparently utilizes all the cores on your system, while allowing you to write plain old iterative, blocking code. Go may be less than ideal in many other regards (i.e. the rest of the language), but it gets this right.
  • rubiquity 10y ago
    > No other language really does it right like Go Not trying to start a war but... Erlang, Haskell, F#, and a few others abstracted Evented IO and parallelism before Go even existed.
    • smegel 10y ago
      I should have added mainstream, non-functional, compiled language.
      • InclinedPlane 10y ago
        Rust? I would never consider Go mainstream myself though. Erlang is practically more mainstream.
        • smegel 10y ago
          Rust may well be, but it is not out yet? Erlang is mainstream, but being functional probably not open to consideration for 99% of developers.
          • dalke 10y ago
            Rust, version 1.0.0, was released in May 2015, so over a year ago. 1.9 came out 10 days ago. Is that not out enough for you?
            • smegel 10y ago
              I have no idea. Is the language spec fully implemented by a robust and stable compiler/runtime? If so, I'll use it today!
              • deleted 10y ago
                [deleted]
              • geofft 10y ago
                Yes, the compiler has fully implemented everything the language is intended to do since the 1.0 release a bit over a year ago. (Work focuses on the compiler and standard library itself; there isn't a separate spec doc that is updated to do things that aren't yet implemented or being implemented, so it's more like Python or GHC than R6RS or C++.) The compiler and the language are both stable; there's been no "runtime" in a strict sense since a few months 1.0, but there's a standard library which is usually statically linked in, and both the language and the standard library are covered by a very strong stability guarantee (more-or-less, code that works today and isn't deliberately doing something stupid will work indefinitely, as there are no plans for a Rust 2.0). Plenty of people are using it in production. So I'd go with "Yes."
            • foota 10y ago
              @smegel, yes it is.
            • nzjrs 10y ago
              I worry about the bus factor of rust. I was at the fosdem rust meet up / devroom and it was 95% Mozilla folk
              • majewsky 10y ago
        • lelandbatey 10y ago
          Rust offers almost everything that Go does, but with a (much) nicer compiler, tooling that makes me drool, memory safety, and all with zero-cost abstractions that keep Rust as fast or faster than the naive C++ equivalent. So even though I work in a majority Go company, and I feel like Go is quite mainstream, I firmly believe that Rust is the future! Btw, sorry if this Rust enthusiasm comes across as a bit over the top, I'm quite tired. I just really like it is all.
          • ngrilly 10y ago
            Rust is a great and powerful language, probably the best alternative to C++ nowadays, but I think you're overselling it. Rust definitely does things Go doesn't, but Go also offers things Rust doesn't: builtin concurrency and parallelism with goroutines and channels, garbage collection (which is useful when your app can tolerate its moderate overhead), very fast compilation, and great tooling.
            • kibwen 10y ago
              Rust has builtin concurrency and parallelism in the standard library via threads, channels, and more, it just doesn't have green threads in the stdlib. As well, Rust also comes bundled with great tooling.
              • nemothekid 10y ago
                >it just doesn't have green threads in the stdlib Green Threads is one of the most important features in golang - to pretend that "Rust offers almost everything that Go does", but ignore the number 1 feature is dishonest.
                • kibwen 10y ago
                  I'm not the one who claimed that "Rust offers almost everything that Go does", but to say that concurrency and tooling aren't things that Rust excels at is equally dishonest. :P
      • whateveracct 10y ago
        Moving the goalposts a bit there, aren't you?
        • smegel 10y ago
          No, I think they are common assumptions.
          • chrisseaton 10y ago
            They obviously aren't - this whole thread is about Python, which is not a compiled language. So clearly nobody moving from Python to Go already had a requirement for it to be compiled.
            • smegel 10y ago
              I was talking about the points "mainstream, non-functional" which excluded all the previous counter-examples. I only added "compiled" as it is a notable feature of Go that may be seen as beneficial for performance and other reasons.
      • rdtsc 10y ago
        If Erlang breaks there is a 50% you won't be able to see cat pictures on your smart phone anymore. It might not be cool with the startup crowd or the Google-following one, but is a an industrially used langauge for many products (RabbitMQ, CouchDB, Riak, Ejabberd, WhatsApp messaging, payment systems in Europe, and others). It is cool you like Go, it is a nice language. But before you claim "it is the only language that does X", you should learn about other langues as well.
        • smegel 10y ago
          I know about Erlang and what it can do, and I maintain Go is the only mainstream, non-functional language that does abstraction of event based/threaded programming well, or at all. I'm not even sure Rust does...the best I can find is it was planned to, but it didn't make it in. And I don't consider any functional language as a viable choice for the vast majority of mainstream users.
          • deleted 10y ago
            [deleted]
          • rubiquity 10y ago
            Outside of HackerNews and Google I wouldn't consider Go to be very mainstream at all.
    • Pxtl 10y ago
      Even good old c# with async/await does async I/O pretty well.
      • ngrilly 10y ago
        C# with async/await is a different approach: it's a kind of cooperative multitasking where "yield points" are explicit. Go uses a kind of preemptive multitasking, in which goroutines don't have to explicitly "yield" control to the scheduler.
• fatbird 10y ago
  Hastings proposed avoiding the breaking changes issues by having separate extension integration points for python with the GIL and without. In other words, cpython would be compilable without the GIL, and extensions wanting true threaded parallelism would implement additional integration points to take advantage of that if run in a GIL-less python. So numpy, for example, would continue to work with the GILled python, but a data scientist would also have the GIL-less python available, set up a virtualenv for it, install numpy, and see all those benefits, without ever causing breaking changes for extension authors. Dunno if that'll work in practice, but it seems like the best possible plan going forward to get the change without causing strife.
• IndianAstronaut 10y ago
  >If I know multi-core performance is going to be an issue up front, I would pick another language. This is why I have shifted most of my code (I work in data warehousing) to Go. Python is handy for little scripts and data mining.
• IndianAstronaut 10y ago
  >If I know multi-core performance is going to be an issue up front, I would pick another language. This is why I have shifted most of my code (I work in data warehousing) to Go. Python is handy for little scripts and data mining.