5 ms·

Eh what? That's not right, that's not even wrong... The style one can program in and the style it is implemented isn't connected the way you think it is. And

Eh what? That's not right, that's not even wrong... The style one can program in and the style it is implemented isn't connected the way you think it is. And no, Scala "doesn't have" loop/react. Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library.

smegel 13y ago
> The style one can program in and the style it is implemented isn't connected the way you think it is. The implementation determines what happens when synchronous, blocking code, well blocks. In Go it yields to another green thread (Goroutine). In any language implemented on the JVM (including Scala) you block an OS level thread. The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. > Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library. I'm not sure why that is relevant (Actors seem a pretty core part of Scala), but I guess it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads.
- happy_dino 13y ago
  > In any language implemented on the JVM (including Scala) you block an OS level thread. Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. > The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. > I'm not sure why that is relevant (Actors seem a pretty core part of Scala) Actors are a library, just like Scala's async/await, the Future/Promises library, the continuation library, Java's Fork/Join library. Actually, Scala just replaced its “official” Actor library in the last release. Go will be stuck forever with its ad-hoc stuff which has been hard-coded into the language. > it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads LOOOOOOOOOOOL. Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload.
  - smegel 13y ago
    > Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. Obviously it is an implementation detail, and for any JVMs that support green threads (none of the major ones do), then it would be a different matter entirely. > You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. Java was created in the mid-90s before every man and his dog was trying to solve the c10k problem on a $5/month VPS. Hardly surprising. > Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. But it does allow for it, or make it easy. Why do you think Scala has both blocking, and "event based" (loop/react) API's? > Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? Quite possibly, you must have been living under a rock if you haven't heard of callback hell in Node.js. Funny because Node was the coolest thing ever a couple of years back, how times change. > You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload. Java has great MT concurrency. It's light-weight concurrency (NIO) is about as good or bad as any other event-based systems out there. What is lacks (my original comment) is the ability to write event-based code using a synchronous, blocking style (without callbacks). The only contenders there are Go, Haskell, and possibly some of the scripting language extensions (Python/Gevent, Perl/Coro). And if by "broken scheduler" you mean it's lack of preemption...then I would say rethink your design, you should be handing long-running jobs to a work queue anyhow.
    - anonymoushn 13y ago
      If solutions with manual scheduling like Python's greenlet are acceptable, Lua and basically any LISP should also fit the bill.
    - happy_dino 13y ago
      > [...] then it would be a different matter entirely Have fun moving the goal posts around. > Java was created in the mid-90s before every man and his dog was trying to solve the c10k problem on a $5/month VPS. Hardly surprising. So what? C10k isn't a hard thing to do on the JVM and it probably beats Go by a large margin in terms of latency and performance. > Why do you think Scala has both blocking, and "event based" (loop/react) API's? Your point is ...? There are plenty of different libraries, because concurrency can be tackled in different ways. Use the right tool for the job. Unlike in Go, where you pretty much have to shoe-horn everything into “goroutines” or channels. The lack of developers which run around and try to tell everyone that they found the silver bullet for solving concurrency in Scala is a sign of a mature community which has experience and expertise and doesn't just repeat whatever Rob Pike says like Go users seem to do all day long. > Quite possibly, you must have been living under a rock if you haven't heard of callback hell in Node.js. Eh ... so what? It's not like Node's terrible approach is the only alternative to Go's approach. Claiming “A is the best, because B is even worse” just shows a complete lack of knowledge of existing solutions. > What is lacks (my original comment) is the ability to write event-based code using a synchronous, blocking style (without callbacks). Again: No it doesn't. Do your research instead of claiming blatantly false things.
anonymoushn 13y ago
This, and your replies below, read like trolling written by someone who hasn't used the features he is claiming are unnecessary. They repeatedly fail to address the point: you actually can't begin in Scala with no notion of lightweight threads, coroutines, or continuations, and simply make a library that does one of those things. "The style one can program in and the style it is implemented isn't connected the way you think it is." The above might be alluding to techniques for pretending to have these language features when one does not. You can write CPS manually, and you might even be able to make a machine apply the CPS transformation automatically to your procedural code. Neither of these things sound particularly fun, compared to the alternative of writing procedural code and then debugging the code that you've actually written. It's little help that you have to return every once in a while to avoid a StackOverflow due to the language's embarrassing lack of TCO. Edit: Apparently if you use Squawk you can have green threads. Can you have OS threads as well?
- happy_dino 13y ago
  > due to the language's embarrassing lack of TCO TCO is a runtime property, not a language property. Anyway, you have clearly not been doing your research and its not my job to do it for you. Bye.
  - anonymoushn 13y ago
    This comment is hilarious. I guess I can now spend the rest of my life searching for the super-performant yet somehow extremely obscure JVM implementation with OS threads, green threads, and TCO. Edit: I am still seeking the legendary JVM implementation with TCO. I guess the argument is something like, oh well at some point in the future some JVM could conceivably have that feature, therefor it is wrong to say that Scala does not have it! Rather than writing code that assumes Scala is a complete joke of a functional language, one could simply write the code the natural way, verify that it compiles, and then wait until a JVM with TCO exists, so that it will stop crashing! In the mean time, one can enjoy the entertainment provided by Scala's inability to compile shift in an if statement without an else clause. Truly I am writing code exactly as I would if(it_was_synchronous) else { cpsunit }. I feel as though you told me reset and shift, although you did not. So thanks for that!

smegel 13y ago

> The style one can program in and the style it is implemented isn't connected the way you think it is. The implementation determines what happens when synchronous, blocking code, well blocks. In Go it yields to another green thread (Goroutine). In any language implemented on the JVM (including Scala) you block an OS level thread. The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. > Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library. I'm not sure why that is relevant (Actors seem a pretty core part of Scala), but I guess it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads.

happy_dino 13y ago
> In any language implemented on the JVM (including Scala) you block an OS level thread. Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. > The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. > I'm not sure why that is relevant (Actors seem a pretty core part of Scala) Actors are a library, just like Scala's async/await, the Future/Promises library, the continuation library, Java's Fork/Join library. Actually, Scala just replaced its “official” Actor library in the last release. Go will be stuck forever with its ad-hoc stuff which has been hard-coded into the language. > it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads LOOOOOOOOOOOL. Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload.
- smegel 13y ago
  > Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. Obviously it is an implementation detail, and for any JVMs that support green threads (none of the major ones do), then it would be a different matter entirely. > You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. Java was created in the mid-90s before every man and his dog was trying to solve the c10k problem on a $5/month VPS. Hardly surprising. > Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. But it does allow for it, or make it easy. Why do you think Scala has both blocking, and "event based" (loop/react) API's? > Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? Quite possibly, you must have been living under a rock if you haven't heard of callback hell in Node.js. Funny because Node was the coolest thing ever a couple of years back, how times change. > You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload. Java has great MT concurrency. It's light-weight concurrency (NIO) is about as good or bad as any other event-based systems out there. What is lacks (my original comment) is the ability to write event-based code using a synchronous, blocking style (without callbacks). The only contenders there are Go, Haskell, and possibly some of the scripting language extensions (Python/Gevent, Perl/Coro). And if by "broken scheduler" you mean it's lack of preemption...then I would say rethink your design, you should be handing long-running jobs to a work queue anyhow.
  - anonymoushn 13y ago
    If solutions with manual scheduling like Python's greenlet are acceptable, Lua and basically any LISP should also fit the bill.
  - happy_dino 13y ago
    > [...] then it would be a different matter entirely Have fun moving the goal posts around. > Java was created in the mid-90s before every man and his dog was trying to solve the c10k problem on a $5/month VPS. Hardly surprising. So what? C10k isn't a hard thing to do on the JVM and it probably beats Go by a large margin in terms of latency and performance. > Why do you think Scala has both blocking, and "event based" (loop/react) API's? Your point is ...? There are plenty of different libraries, because concurrency can be tackled in different ways. Use the right tool for the job. Unlike in Go, where you pretty much have to shoe-horn everything into “goroutines” or channels. The lack of developers which run around and try to tell everyone that they found the silver bullet for solving concurrency in Scala is a sign of a mature community which has experience and expertise and doesn't just repeat whatever Rob Pike says like Go users seem to do all day long. > Quite possibly, you must have been living under a rock if you haven't heard of callback hell in Node.js. Eh ... so what? It's not like Node's terrible approach is the only alternative to Go's approach. Claiming “A is the best, because B is even worse” just shows a complete lack of knowledge of existing solutions. > What is lacks (my original comment) is the ability to write event-based code using a synchronous, blocking style (without callbacks). Again: No it doesn't. Do your research instead of claiming blatantly false things.

anonymoushn 13y ago

This, and your replies below, read like trolling written by someone who hasn't used the features he is claiming are unnecessary. They repeatedly fail to address the point: you actually can't begin in Scala with no notion of lightweight threads, coroutines, or continuations, and simply make a library that does one of those things. "The style one can program in and the style it is implemented isn't connected the way you think it is." The above might be alluding to techniques for pretending to have these language features when one does not. You can write CPS manually, and you might even be able to make a machine apply the CPS transformation automatically to your procedural code. Neither of these things sound particularly fun, compared to the alternative of writing procedural code and then debugging the code that you've actually written. It's little help that you have to return every once in a while to avoid a StackOverflow due to the language's embarrassing lack of TCO. Edit: Apparently if you use Squawk you can have green threads. Can you have OS threads as well?

happy_dino 13y ago
> due to the language's embarrassing lack of TCO TCO is a runtime property, not a language property. Anyway, you have clearly not been doing your research and its not my job to do it for you. Bye.
- anonymoushn 13y ago
  This comment is hilarious. I guess I can now spend the rest of my life searching for the super-performant yet somehow extremely obscure JVM implementation with OS threads, green threads, and TCO. Edit: I am still seeking the legendary JVM implementation with TCO. I guess the argument is something like, oh well at some point in the future some JVM could conceivably have that feature, therefor it is wrong to say that Scala does not have it! Rather than writing code that assumes Scala is a complete joke of a functional language, one could simply write the code the natural way, verify that it compiles, and then wait until a JVM with TCO exists, so that it will stop crashing! In the mean time, one can enjoy the entertainment provided by Scala's inability to compile shift in an if statement without an else clause. Truly I am writing code exactly as I would if(it_was_synchronous) else { cpsunit }. I feel as though you told me reset and shift, although you did not. So thanks for that!