4 ms·

> Go’s performance isn’t a big win for Java developers since they’re already doing pretty well. But for us dynamic language refugees, Go’s performance is libera

by adamors 12y ago

> Go’s performance isn’t a big win for Java developers since they’re already doing pretty well. But for us dynamic language refugees, Go’s performance is liberating. No dealing with reverse proxies to send things to multiple processes. Real threading and the ability to take advantage of every core. Async IO, but without all the callbacks. Jesus, are people really this excited about features that existed for at least 15 years in other languages? This one language for everything mentality is ushering in a huge NIH cycle.

demallien 12y ago
Async IO without the callbacks? How does that work???
- jey 12y ago
  Coroutines. Er, I mean, "goroutines".
  - kitd 12y ago
    You can even do it in C (if you REALLY want) http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
- exDM69 12y ago
  Green threads in Haskell do this too. You can write code in typical imperative fashion but all blocking IO statements will cause a co-operative green thread switch. Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads.
  - M2Ys4U 12y ago
    >Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads. I'm pretty sure that I/O is only task-blocking in Rust, and tasks can be 1:1 or M:N with native threads.
    - Jweb_Guru 12y ago
      That's correct, but there's not much reason to use green threads in Rust--they don't have the advantages that green threads in Go do, besides the lack of context switching (they aren't "lightweight" because they are just as resource-intensive as threads).
  - masklinn 12y ago
    > Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads. tasks can be either 1:1[0] or m:n[1]. The default is 1:1, but m:n should be equally supported by force-booting with libgreen[2]. [0] http://doc.rust-lang.org/native/index.html http://doc.rust-lang.org/native/index.html [1] http://doc.rust-lang.org/green/ http://doc.rust-lang.org/green/ [2] http://doc.rust-lang.org/guide-runtime.html#force-booting-with-libgreen http://doc.rust-lang.org/guide-runtime.html#force-booting-wi...
- thu 12y ago
  Lightweight threads in Haskell (using the excellent GHC runtime).
- coldtea 12y ago
  The way async is supposed to. From coroutines to await etc.
Shish2k 12y ago
People are excited that the features which already existed are now tied together in a pleasant to use way, free from most of the drawbacks that are typically associated with low-level languages
- adamors 12y ago
  I don't understand why you would need one language for everything. Thanks to messaging queues (or just HTTP) interop between languages/technologies has never been easier. Even if Go ties these features together, it won't be best in every domain.
- waps 12y ago
  No people are exited about the plain and simple standard library, which is 2 years old, and thus currently relatively free of compromises (though more and more are coming to light like you'd expect, like recently on the mailing list the complaint that logging can't be stubbed out, and this can't be changed due to backwards compatibility ... that's the arguments that will break the language). People were exited about the fresh compromise-less nature of the C++ standard library in the 80s, even in the 90s. About the fresh no-compromise approach of the java ones at the end of the 90s, and again right after java introduced generics. Go is no different. It's standard library is not that far from the cruft-level of the python standard library, and the next language change (which they absolutely need : generics) will bring it to the level of the java standard library, due to the need for backward compatibility with pre-generics go programs. Come on people, I realize at 16 I too thought that language X is forever (C++ in my case, on the plus side: it fared better than most. Some people, mostly the academics later switching to java, actually picked modula-2/oberon, which is/are a lot like Go. A lot went for visual basic, object pascal, and some for objective-C). But we're not 16 anymore ... When it comes to 15+ year old languages, I'd actually say C++ is the most cruft-free easily usable language. Depends, a lot, on what libraries you use though.
  - Shish2k 12y ago
    No, I'm pretty sure it's the language. Coming from Python, Go's tiny and sparse standard library is one of the things I don't like about it :P
threeseed 12y ago
Java has a very strong presence in HFT, Betting, FX and Stock Exchanges companies. Pretty sure they know a thing or two about "real threading".
- waps 12y ago
  I thoroughly agree with that. Go's channels are great for multiplexing (but not as great as real continuations), but for computation, promises beat the crap out of Go's channels. And data structures in Go, that's just plain painful.
viraptor 12y ago
Near-C performance, static/strong types, async io without callbacks, well integrated multithreading... maybe I'm missing something obvious, but which (not obscure) 15-yo language provides this set of features?
- verroq 12y ago
  C++
  - NateDad 12y ago
    ...that you'd actually want to program in and doesn't have footguns the size of the deathstar?
  - viraptor 12y ago
    Well integrated multithreading? It only just started getting integrated in the latest standard. The typing is also not that strong... you can get silly implicit stuff happening in many places.
- threeseed 12y ago
  Java has a few projects that get you pretty close: http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ https://github.com/Netflix/RxJava https://github.com/Netflix/RxJava
- spion 12y ago
  Performance - not really that near to C Static types - of the worst kind that get in the way of creating any significant abstractions (no parametric polymorphism or generics) and don't provide much safety (no nil safety). For a new modern language, this is just weird. Well integrated multithreading - yes. 40-year-old error handling strategy: also yes. Haskell, Scala, F#, C# are all much better choices that I think fulfill all your criteria (Well, one might argue that functional languages are obscure, but that's increasingly not the case these days) I find the popularity of Go rather depressing. If Go becomes the next Java, the inventors of C would set the programming world decades back in the past for the second time.

by adamors 12y ago

demallien 12y ago

Async IO without the callbacks? How does that work???

jey 12y ago
Coroutines. Er, I mean, "goroutines".
- kitd 12y ago
  You can even do it in C (if you REALLY want) http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
exDM69 12y ago
Green threads in Haskell do this too. You can write code in typical imperative fashion but all blocking IO statements will cause a co-operative green thread switch. Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads.
- M2Ys4U 12y ago
  >Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads. I'm pretty sure that I/O is only task-blocking in Rust, and tasks can be 1:1 or M:N with native threads.
  - Jweb_Guru 12y ago
    That's correct, but there's not much reason to use green threads in Rust--they don't have the advantages that green threads in Go do, besides the lack of context switching (they aren't "lightweight" because they are just as resource-intensive as threads).
- masklinn 12y ago
  > Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads. tasks can be either 1:1[0] or m:n[1]. The default is 1:1, but m:n should be equally supported by force-booting with libgreen[2]. [0] http://doc.rust-lang.org/native/index.html http://doc.rust-lang.org/native/index.html [1] http://doc.rust-lang.org/green/ http://doc.rust-lang.org/green/ [2] http://doc.rust-lang.org/guide-runtime.html#force-booting-with-libgreen http://doc.rust-lang.org/guide-runtime.html#force-booting-wi...
thu 12y ago
Lightweight threads in Haskell (using the excellent GHC runtime).
coldtea 12y ago
The way async is supposed to. From coroutines to await etc.

Shish2k 12y ago

People are excited that the features which already existed are now tied together in a pleasant to use way, free from most of the drawbacks that are typically associated with low-level languages

adamors 12y ago
I don't understand why you would need one language for everything. Thanks to messaging queues (or just HTTP) interop between languages/technologies has never been easier. Even if Go ties these features together, it won't be best in every domain.
waps 12y ago
No people are exited about the plain and simple standard library, which is 2 years old, and thus currently relatively free of compromises (though more and more are coming to light like you'd expect, like recently on the mailing list the complaint that logging can't be stubbed out, and this can't be changed due to backwards compatibility ... that's the arguments that will break the language). People were exited about the fresh compromise-less nature of the C++ standard library in the 80s, even in the 90s. About the fresh no-compromise approach of the java ones at the end of the 90s, and again right after java introduced generics. Go is no different. It's standard library is not that far from the cruft-level of the python standard library, and the next language change (which they absolutely need : generics) will bring it to the level of the java standard library, due to the need for backward compatibility with pre-generics go programs. Come on people, I realize at 16 I too thought that language X is forever (C++ in my case, on the plus side: it fared better than most. Some people, mostly the academics later switching to java, actually picked modula-2/oberon, which is/are a lot like Go. A lot went for visual basic, object pascal, and some for objective-C). But we're not 16 anymore ... When it comes to 15+ year old languages, I'd actually say C++ is the most cruft-free easily usable language. Depends, a lot, on what libraries you use though.
- Shish2k 12y ago
  No, I'm pretty sure it's the language. Coming from Python, Go's tiny and sparse standard library is one of the things I don't like about it :P

threeseed 12y ago

Java has a very strong presence in HFT, Betting, FX and Stock Exchanges companies. Pretty sure they know a thing or two about "real threading".

waps 12y ago
I thoroughly agree with that. Go's channels are great for multiplexing (but not as great as real continuations), but for computation, promises beat the crap out of Go's channels. And data structures in Go, that's just plain painful.

viraptor 12y ago

Near-C performance, static/strong types, async io without callbacks, well integrated multithreading... maybe I'm missing something obvious, but which (not obscure) 15-yo language provides this set of features?

verroq 12y ago
C++
- NateDad 12y ago
  ...that you'd actually want to program in and doesn't have footguns the size of the deathstar?
- viraptor 12y ago
  Well integrated multithreading? It only just started getting integrated in the latest standard. The typing is also not that strong... you can get silly implicit stuff happening in many places.
threeseed 12y ago
Java has a few projects that get you pretty close: http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ https://github.com/Netflix/RxJava https://github.com/Netflix/RxJava
spion 12y ago
Performance - not really that near to C Static types - of the worst kind that get in the way of creating any significant abstractions (no parametric polymorphism or generics) and don't provide much safety (no nil safety). For a new modern language, this is just weird. Well integrated multithreading - yes. 40-year-old error handling strategy: also yes. Haskell, Scala, F#, C# are all much better choices that I think fulfill all your criteria (Well, one might argue that functional languages are obscure, but that's increasingly not the case these days) I find the popularity of Go rather depressing. If Go becomes the next Java, the inventors of C would set the programming world decades back in the past for the second time.