5 ms·

The only thing I could see myself leaving Python for is Haskell. Go seems to fall into a very small niche. The inclusion of a GC means it is not appropriate fo

The only thing I could see myself leaving Python for is Haskell. Go seems to fall into a very small niche. The inclusion of a GC means it is not appropriate for a lot tasks that C/C++ are suited for. Also, it is verbose enough where you can't bang out stuff as fast as in Python/Ruby.

tel 16y ago
It's really a big deal for Haskell to sit in that position now instead of "that weird language with Spacesuitmonads". I hear the sentiment a lot and every time I'm somewhat surprised and happy to realize it.
BarkMore 16y ago
I find that I can write working code with Go as fast as I can with Python. Although I need to type more with Go, the static typing helps me iterate faster to working code. With the exception of the library problem that I mention in another comment, Go can cover much of the space covered by Python.
- silentbicycle 16y ago
  Have you used OCaml or Haskell, beyond Fibonacci trivialities? How about J?
kjksf 16y ago
Go, today, is a niche language by usage but is not niche by features. It's designed as a server-oriented (i.e. aimed at a still growing programming category) language that is close in syntax to C/Java (i.e. already familiar to many), almost as easy to write in as Python/Ruby (both very successful, non-niche languages) but order of magnitude faster and much memory efficient that either. As a bonus it has much better concurrency support. It's designed for the same "niche" that Python/Ruby/Java serves on the server, with many important improvements over them. Having written code in Python and Go, Go seems to me an improvement over Python in many important areas (speed, memory efficiency, concurrency) and the parts that are not as good are both not as important and not significantly worse (static vs. dynamic typing is a toss (it's nice not to declare types but it's also nice if compiler tells you about a type mismatch typo that Python will only complain about at runtime), Python still has slightly cleaner syntax etc.). I didn't experience Go being more verbose than Python to a degree that it mattered. In some aspects the syntax is actually less verbose (Python class require more typing than Go interfaces). Go is still a young language and young implementation. On one hand it means it's anyone's guess whether it'll become non-niche at some point but at the same time I'm pretty sure at year one both Python and Ruby were much less polished and much less popular than Go is at the same stage. Personally, I'm bullish on Go and if I were writing server side code, I would use Go (even though at the moment I know Python better).
- alnayyir 16y ago
  >As a bonus much better aligned with today's multi-core reality than Python or Ruby. Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. > but order of magnitude faster and much memory efficient that Python or Ruby. So is my Radio Flyer Wagon. You still can't do systems programming, embedded, high performance, or real-time work with it. I know too much about C and the constraints it works well in to believe Go is anything but awkwardly crammed between two realms of programming. A language that forces its own GC upon you (note that you can have GC in C/C++, you merely have to choose one), and its own concurrency model upon you without giving you at least a couple choices is not a well designed language. Even Clojure gives you a couple ways to approach concurrency, and it doesn't even make the same claims as Go has. I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Not a single one.
  - lhnn 16y ago
    In all the year it's been out, I don't know one person who has devoted years of experience to Go.
  - kjksf 16y ago
    > Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. It's not true. I'm not sure what concurrency models you feel you need but let's go through the most popular ones. There's event based programming which is essentially single-threaded and predicated on structuring your code around poll/kqueue/whatever loop. You can do that in Go since you can call any OS syscall from Go. It just leads to awkward code. There's shared memory multithreading with locks to protect data structures. You can do that in Go (except you use goroutines, which are multiplexed into OS threads by Go scheduler, instead of using OS threads directly as in C). And then there's Go's prefferred (but not exclusive) solution of channels/goroutines and idea of sharing memory by communicating (as opposed to communicating by sharing memory as in threads/locks based model). What concurrency models are available in C or Python or Java that you can't do in Go? > So is my Radio Flyer Wagon. You still can't do systems programming, embedded, high performance, or real-time work with it. As a rebuttal (?), it doesn't follow. As to your point, your definition of systems programming is different from that used by Go designers, since they are very insistent on calling Go a systems programming language. Please clarify what kind of systems programming you can do in C/Java that you can't do in Go? As to high-performance: I don't follow. It's fast. What kind of high performance programming you can't do in Go that you can do in C or Java? As to embedded - sure that niche is owned by C. How is it different from Python or Java and how does that make Go a niche language? The same goes for real-time where real-time systems are even more niche and are as much a property of the OS as it is of the language. You can't do real-time in any language on stock Linux kernel given that kernel can pre-empt any application at any time for any period of time. You make a lot of statements but nothing concrete enough to support them. I've shown that in Go you can use 3 concurrency models, 2 of which are currently most popular in the C/Java worlds. As to systems programming - you don't provide a definition or examples of what kind of programs do you consider as systems programming so it's hard to argue at that level. Does a web server qualify? (you can write one Go). Would a distributed database like HBase qualify? Even though one hasn't been written, HBase is Java and there's nothing that you can write in Java that you can't write in Go, with potentially better performance due to compilation to native code and more efficient memory usage.
swannodette 16y ago
Python -> Haskell seems like a serious leap. Even to the point of not seeming all that realistic. Care to elaborate on why you think that's a natural progression for you? I like Python, but FP programming is a second-rate style there.
- megaman821 16y ago
  Well, Python does give you a little taste of the FP world with things like list comprehensions. Haskell has very good concurrency solutions like sparks(async), MVars and forkIO (threaded), and data parallelism. Writing a program for 128 cores doesn't look very different than writing a program for 2 cores. I think that this will become very important sometime in the next decade as computer will come with more and more cores.
silentbicycle 16y ago
I left Python for Lua years ago, haven't looked back. Even if you don't care about tail-call optimization, etc., LuaJIT (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=pypy http://shootout.alioth.debian.org/u32/benchmark.php?test=all...) is pretty compelling. (Also, OCaml, though I use Lua more day-to-day.)
- codexon 16y ago
  LuaJIT has a memory limit of 4gb. When it is compiled for x64, it has a limit of 1gb. You cannot use Lua lanes to bypass this, the Lua states must be in different processes. http://lua-users.org/lists/lua-l/2010-11/msg00241.html http://lua-users.org/lists/lua-l/2010-11/msg00241.html The lack of try/catch is also a nuisance.
  - silentbicycle 16y ago
    Lua has try/catch-like functionality, it's just called pcall ("protected call"), or xpcall (http://www.lua.org/manual/5.1/manual.html#pdf-xpcall http://www.lua.org/manual/5.1/manual.html#pdf-xpcall) if you want to run a callback before the stack unwinds. Running debug.debug inside xpcall's handler will drop into a shell on error, which is particularly handy. error("error tag") is comparable to raising an exception. I wasn't aware of LuaJIT's 1gb limit, but it's neither hard nor unusual to run several Lua states in multiple worker processes.
- rlander 16y ago
  I love lua (almost as much as I enjoy python and erlang), but how do you cope with the lack of libraries? Since last year I've been trying to use lua on personal projects, but I find the generally poor documentation and lack of libraries very annnoying (and unproductive).
  - silentbicycle 16y ago
    I haven't found libraries lacking, but we probably work on different things, and I don't have any problem with writing quick wrappers for existing C libraries. There's a fair bit of Lua libs that are insufficiently documented or tested, or have bit-rot (esp. due to changes in Lua itself), but the situation is getting better. For libs, I usually check http://lua-users.org/wiki/LibrariesAndBindings http://lua-users.org/wiki/LibrariesAndBindings and http://luarocks.org/repositories/rocks/ http://luarocks.org/repositories/rocks/ . I've written a couple libraries, as well. See e.g. lunatest (http://github.com/silentbicycle/lunatest http://github.com/silentbicycle/lunatest, an xUnit-like + randomized (QuickCheck-ish) testing library) and Tamale (http://github.com/silentbicycle/tamale http://github.com/silentbicycle/tamale, Erlang-style pattern-matching for Lua).

tel 16y ago

It's really a big deal for Haskell to sit in that position now instead of "that weird language with Spacesuitmonads". I hear the sentiment a lot and every time I'm somewhat surprised and happy to realize it.

BarkMore 16y ago

I find that I can write working code with Go as fast as I can with Python. Although I need to type more with Go, the static typing helps me iterate faster to working code. With the exception of the library problem that I mention in another comment, Go can cover much of the space covered by Python.

silentbicycle 16y ago
Have you used OCaml or Haskell, beyond Fibonacci trivialities? How about J?

kjksf 16y ago

Go, today, is a niche language by usage but is not niche by features. It's designed as a server-oriented (i.e. aimed at a still growing programming category) language that is close in syntax to C/Java (i.e. already familiar to many), almost as easy to write in as Python/Ruby (both very successful, non-niche languages) but order of magnitude faster and much memory efficient that either. As a bonus it has much better concurrency support. It's designed for the same "niche" that Python/Ruby/Java serves on the server, with many important improvements over them. Having written code in Python and Go, Go seems to me an improvement over Python in many important areas (speed, memory efficiency, concurrency) and the parts that are not as good are both not as important and not significantly worse (static vs. dynamic typing is a toss (it's nice not to declare types but it's also nice if compiler tells you about a type mismatch typo that Python will only complain about at runtime), Python still has slightly cleaner syntax etc.). I didn't experience Go being more verbose than Python to a degree that it mattered. In some aspects the syntax is actually less verbose (Python class require more typing than Go interfaces). Go is still a young language and young implementation. On one hand it means it's anyone's guess whether it'll become non-niche at some point but at the same time I'm pretty sure at year one both Python and Ruby were much less polished and much less popular than Go is at the same stage. Personally, I'm bullish on Go and if I were writing server side code, I would use Go (even though at the moment I know Python better).

alnayyir 16y ago
>As a bonus much better aligned with today's multi-core reality than Python or Ruby. Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. > but order of magnitude faster and much memory efficient that Python or Ruby. So is my Radio Flyer Wagon. You still can't do systems programming, embedded, high performance, or real-time work with it. I know too much about C and the constraints it works well in to believe Go is anything but awkwardly crammed between two realms of programming. A language that forces its own GC upon you (note that you can have GC in C/C++, you merely have to choose one), and its own concurrency model upon you without giving you at least a couple choices is not a well designed language. Even Clojure gives you a couple ways to approach concurrency, and it doesn't even make the same claims as Go has. I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Not a single one.
- lhnn 16y ago
  In all the year it's been out, I don't know one person who has devoted years of experience to Go.
- kjksf 16y ago
  > Not substantially. It made the concurrency decisions for you ahead of time, and if you need a different concurrency model, you're up shit creek. It's not true. I'm not sure what concurrency models you feel you need but let's go through the most popular ones. There's event based programming which is essentially single-threaded and predicated on structuring your code around poll/kqueue/whatever loop. You can do that in Go since you can call any OS syscall from Go. It just leads to awkward code. There's shared memory multithreading with locks to protect data structures. You can do that in Go (except you use goroutines, which are multiplexed into OS threads by Go scheduler, instead of using OS threads directly as in C). And then there's Go's prefferred (but not exclusive) solution of channels/goroutines and idea of sharing memory by communicating (as opposed to communicating by sharing memory as in threads/locks based model). What concurrency models are available in C or Python or Java that you can't do in Go? > So is my Radio Flyer Wagon. You still can't do systems programming, embedded, high performance, or real-time work with it. As a rebuttal (?), it doesn't follow. As to your point, your definition of systems programming is different from that used by Go designers, since they are very insistent on calling Go a systems programming language. Please clarify what kind of systems programming you can do in C/Java that you can't do in Go? As to high-performance: I don't follow. It's fast. What kind of high performance programming you can't do in Go that you can do in C or Java? As to embedded - sure that niche is owned by C. How is it different from Python or Java and how does that make Go a niche language? The same goes for real-time where real-time systems are even more niche and are as much a property of the OS as it is of the language. You can't do real-time in any language on stock Linux kernel given that kernel can pre-empt any application at any time for any period of time. You make a lot of statements but nothing concrete enough to support them. I've shown that in Go you can use 3 concurrency models, 2 of which are currently most popular in the C/Java worlds. As to systems programming - you don't provide a definition or examples of what kind of programs do you consider as systems programming so it's hard to argue at that level. Does a web server qualify? (you can write one Go). Would a distributed database like HBase qualify? Even though one hasn't been written, HBase is Java and there's nothing that you can write in Java that you can't write in Go, with potentially better performance due to compilation to native code and more efficient memory usage.

swannodette 16y ago

Python -> Haskell seems like a serious leap. Even to the point of not seeming all that realistic. Care to elaborate on why you think that's a natural progression for you? I like Python, but FP programming is a second-rate style there.

megaman821 16y ago
Well, Python does give you a little taste of the FP world with things like list comprehensions. Haskell has very good concurrency solutions like sparks(async), MVars and forkIO (threaded), and data parallelism. Writing a program for 128 cores doesn't look very different than writing a program for 2 cores. I think that this will become very important sometime in the next decade as computer will come with more and more cores.

silentbicycle 16y ago

I left Python for Lua years ago, haven't looked back. Even if you don't care about tail-call optimization, etc., LuaJIT (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=pypy http://shootout.alioth.debian.org/u32/benchmark.php?test=all...) is pretty compelling. (Also, OCaml, though I use Lua more day-to-day.)

codexon 16y ago
LuaJIT has a memory limit of 4gb. When it is compiled for x64, it has a limit of 1gb. You cannot use Lua lanes to bypass this, the Lua states must be in different processes. http://lua-users.org/lists/lua-l/2010-11/msg00241.html http://lua-users.org/lists/lua-l/2010-11/msg00241.html The lack of try/catch is also a nuisance.
- silentbicycle 16y ago
  Lua has try/catch-like functionality, it's just called pcall ("protected call"), or xpcall (http://www.lua.org/manual/5.1/manual.html#pdf-xpcall http://www.lua.org/manual/5.1/manual.html#pdf-xpcall) if you want to run a callback before the stack unwinds. Running debug.debug inside xpcall's handler will drop into a shell on error, which is particularly handy. error("error tag") is comparable to raising an exception. I wasn't aware of LuaJIT's 1gb limit, but it's neither hard nor unusual to run several Lua states in multiple worker processes.
rlander 16y ago
I love lua (almost as much as I enjoy python and erlang), but how do you cope with the lack of libraries? Since last year I've been trying to use lua on personal projects, but I find the generally poor documentation and lack of libraries very annnoying (and unproductive).
- silentbicycle 16y ago
  I haven't found libraries lacking, but we probably work on different things, and I don't have any problem with writing quick wrappers for existing C libraries. There's a fair bit of Lua libs that are insufficiently documented or tested, or have bit-rot (esp. due to changes in Lua itself), but the situation is getting better. For libs, I usually check http://lua-users.org/wiki/LibrariesAndBindings http://lua-users.org/wiki/LibrariesAndBindings and http://luarocks.org/repositories/rocks/ http://luarocks.org/repositories/rocks/ . I've written a couple libraries, as well. See e.g. lunatest (http://github.com/silentbicycle/lunatest http://github.com/silentbicycle/lunatest, an xUnit-like + randomized (QuickCheck-ish) testing library) and Tamale (http://github.com/silentbicycle/tamale http://github.com/silentbicycle/tamale, Erlang-style pattern-matching for Lua).