5 ms·

>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

>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
  goroutines sound a lot like private queues in Apple's GCD. In their documentation they are quite clear stating that in performance critical code ... surprise ... they might be a bad fit.
- alnayyir 16y ago
  >Does a web server qualify? (you can write one Go). Being able to write something in Go is besides the point. It being turing complete and having the essential faculties and libraries for a basic subset of tasks, yes, you can write a web server in Go. Doesn't mean you should. In any realm where real-time is a concern, where performance is the utmost concern, or where you need real control over the hardware, Go is inappropriate. It's also inappropriate for Rapid Dev. >I've shown that in Go you can use 3 concurrency models, 2 of which are currently most popular in the C/Java worlds. No. C and Java aren't the same world, and your idea of popular is absurd. I'm out of this conversation, sorry.
papaf 16y ago
I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Rob Pike? Ken Thompson?
- alnayyir 16y ago
  I admired Pike and Ken when I was younger, but I can't speak to why they came up with Go and I strongly suspect its design wasn't actually their first choice. You overestimate the power they have in a company as highly political as Google.
supersillyus 16y ago
> I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Not surprising, since it is a very young language. However, as a counterpoint, I do.
- alnayyir 16y ago
  It's possible to critique things based on design, just as much as you can critique a project based on architecture if you know the goals/objectives it aims for. That's the basis upon which I choose to dismiss Go for a selection of uses unless they make some fundamental changes.

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
goroutines sound a lot like private queues in Apple's GCD. In their documentation they are quite clear stating that in performance critical code ... surprise ... they might be a bad fit.
alnayyir 16y ago
>Does a web server qualify? (you can write one Go). Being able to write something in Go is besides the point. It being turing complete and having the essential faculties and libraries for a basic subset of tasks, yes, you can write a web server in Go. Doesn't mean you should. In any realm where real-time is a concern, where performance is the utmost concern, or where you need real control over the hardware, Go is inappropriate. It's also inappropriate for Rapid Dev. >I've shown that in Go you can use 3 concurrency models, 2 of which are currently most popular in the C/Java worlds. No. C and Java aren't the same world, and your idea of popular is absurd. I'm out of this conversation, sorry.

papaf 16y ago

I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Rob Pike? Ken Thompson?

alnayyir 16y ago
I admired Pike and Ken when I was younger, but I can't speak to why they came up with Go and I strongly suspect its design wasn't actually their first choice. You overestimate the power they have in a company as highly political as Google.

supersillyus 16y ago

> I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Not surprising, since it is a very young language. However, as a counterpoint, I do.

alnayyir 16y ago
It's possible to critique things based on design, just as much as you can critique a project based on architecture if you know the goals/objectives it aims for. That's the basis upon which I choose to dismiss Go for a selection of uses unless they make some fundamental changes.