4 ms·

> In my opinion, there is nothing interesting in Go, and it doesn't seem like a language I would want to use. I take it you're a C/C++ developer ? As a ruby de

> In my opinion, there is nothing interesting in Go, and it doesn't seem like a language I would want to use. I take it you're a C/C++ developer ? As a ruby developer, go got my interest like other compiled languages could not, and the reason for that has be pointed out by Rob Pike in his keynote at gophercon[1] : productivity. I'm used to a certain pace of development with interpreted languages that compiled languages just can't match. And well, time is money, I'll use a "slower to write with" language only on critical piece of software where something else won't do. Go has been a perfect fit, here : it allows to do more heavy processing while still being acceptably fast to develop. Other than that, its main advantage is what it has been created for to begin with : concurrency. It's a core concept, meaning you can express it with simple syntax (with goroutines and channels) and that you don't have to fear hitting limits (goroutines are not threads exactly, go do its best to map them on available threads, as much as there are cores, and you can thus have ten of thousands of goroutines running concurrently with no problem). There are probably languages that go further on concurrency, like erlang, but go is just the perfect balance between ease of learning, speed to develop, ease of implementing concurrent code and speed of execution. [1] http://confreaks.com/videos/3419-gophercon2014-opening-day-keynote http://confreaks.com/videos/3419-gophercon2014-opening-day-k...

seanmcdirmid 12y ago
C#, which is faster than Go with better features (parametric polymorphism, classes, interfaces, the works). Go's support for concurrency is nothing very novel and has nothing to do with its language design. Green threads have been around forever, and many platforms support thread pools.
- deleted 12y ago
  [deleted]
- leaveyou 12y ago
  "C# is faster than Go" do you have some links to prove that statement ? I'm really interested because in all the benchmarks I saw, C# seemed much more slower.
  - seanmcdirmid 12y ago
    I haven't seen any head to head comparisons about Go, I just know that C# is generally faster than the JVM (on Windows at least, not Mono), while Go is known to be slower than Java. If you have something that says otherwise, it would be nice to see. Also, I think .NET can optimize generic class instantiations (one advantage in forgoing type erasure), but I'm not sure.
- NateDad 12y ago
  C# is a very good language. It's also ridiculously huge. There are so many language features, you could use a new one in every class and not run out until you'd rewritten Windows. I worked in C# for a decade, and I still have to go look up how some of the features work. Try getting new people up to speed in the language... you'll still be teaching them language features years into their careers.... I know because I did it. It's not a bad language, it's just that it suffers from feature bloat, like many things Microsoft does, and that makes for code that is very difficult to maintain.
pcwalton 12y ago
> ten of thousands of goroutines running concurrently with no problem You have been able to spawn tens of thousands of native threads (on Linux) no problem for a long time. (Though the memory management for stacks can be a pain, so the fact that Go automates this through stack growth is nice.)
- deleted 12y ago
  [deleted]
twic 12y ago
> I'm used to a certain pace of development with interpreted languages that compiled languages just can't match. You have never worked with an incremental compiler, have you? I mostly work in Java, using Eclipse. I make a change to the code, i hit control-R, the test runs immediately. The pace is no slower than with an interpreted language.
- danieldk 12y ago
  In fact, Java also offers hotswap (even more extensively with JRebel). So if you are running an app, changes you make can be live nearly immediately, in a running app.
- oelmekki 12y ago
  Yes, I was not thinking of java (nor any other jit compiler) saying that, but more specifically of C and C++. Also note, in those, it's not especially the building part that annoys me (running tests can just be as long, even in interpreted languages), but more the high verbosity of code you have to write (again, not speaking of java, here).
TheCoelacanth 12y ago
> I'm used to a certain pace of development with interpreted languages that compiled languages just can't match. Haskell using Yesod matches the workflow of interpreted languages. When the development server is running, anytime you save a file it instantly recompiles the file so that the change is immediately reflected.

seanmcdirmid 12y ago

C#, which is faster than Go with better features (parametric polymorphism, classes, interfaces, the works). Go's support for concurrency is nothing very novel and has nothing to do with its language design. Green threads have been around forever, and many platforms support thread pools.

deleted 12y ago
[deleted]
leaveyou 12y ago
"C# is faster than Go" do you have some links to prove that statement ? I'm really interested because in all the benchmarks I saw, C# seemed much more slower.
- seanmcdirmid 12y ago
  I haven't seen any head to head comparisons about Go, I just know that C# is generally faster than the JVM (on Windows at least, not Mono), while Go is known to be slower than Java. If you have something that says otherwise, it would be nice to see. Also, I think .NET can optimize generic class instantiations (one advantage in forgoing type erasure), but I'm not sure.
NateDad 12y ago
C# is a very good language. It's also ridiculously huge. There are so many language features, you could use a new one in every class and not run out until you'd rewritten Windows. I worked in C# for a decade, and I still have to go look up how some of the features work. Try getting new people up to speed in the language... you'll still be teaching them language features years into their careers.... I know because I did it. It's not a bad language, it's just that it suffers from feature bloat, like many things Microsoft does, and that makes for code that is very difficult to maintain.

pcwalton 12y ago

> ten of thousands of goroutines running concurrently with no problem You have been able to spawn tens of thousands of native threads (on Linux) no problem for a long time. (Though the memory management for stacks can be a pain, so the fact that Go automates this through stack growth is nice.)

deleted 12y ago
[deleted]

twic 12y ago

> I'm used to a certain pace of development with interpreted languages that compiled languages just can't match. You have never worked with an incremental compiler, have you? I mostly work in Java, using Eclipse. I make a change to the code, i hit control-R, the test runs immediately. The pace is no slower than with an interpreted language.

danieldk 12y ago
In fact, Java also offers hotswap (even more extensively with JRebel). So if you are running an app, changes you make can be live nearly immediately, in a running app.
oelmekki 12y ago
Yes, I was not thinking of java (nor any other jit compiler) saying that, but more specifically of C and C++. Also note, in those, it's not especially the building part that annoys me (running tests can just be as long, even in interpreted languages), but more the high verbosity of code you have to write (again, not speaking of java, here).

TheCoelacanth 12y ago

> I'm used to a certain pace of development with interpreted languages that compiled languages just can't match. Haskell using Yesod matches the workflow of interpreted languages. When the development server is running, anytime you save a file it instantly recompiles the file so that the change is immediately reflected.