3 ms·

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) l

by 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.
stcredzero 16y ago
Go, today, is a niche language by usage but is not niche by features. In their latest blog post, they've noted that it's not quite as niche by usage as they thought it would be. http://blog.golang.org/2010/11/go-one-year-ago-today.html http://blog.golang.org/2010/11/go-one-year-ago-today.html

by kjksf 16y ago

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.

stcredzero 16y ago

Go, today, is a niche language by usage but is not niche by features. In their latest blog post, they've noted that it's not quite as niche by usage as they thought it would be. http://blog.golang.org/2010/11/go-one-year-ago-today.html http://blog.golang.org/2010/11/go-one-year-ago-today.html