3 ms·

> I think you should read the M:N scheduling links. I'll leave it at that. Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up

by agentS 15y ago

> I think you should read the M:N scheduling links. I'll leave it at that. Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads, so Go isn't exactly alone in this regard. Even Twisted, and Node use a weaker form of this, where everything runs on one thread. > Read the comment at the top. Hardly trivial. First, the comment's meant for language implementors. You don't need to read this comment to be able to do C interop in Go. Second, this isn't even that complicated... did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript...

0xABADC0DA 15y ago
> Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. The links for Ingo and Ulrich worked, these are enough of an indictment of M:N threading. What's changed in the last decade? OS gurus tried M:N threading and it failed. Java tried 'green threads' and it failed, and now Google Go devs are trying the same thing. Guess what's going to happen? > Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads Erlang was written in Prolog and the desktop VM was single-process until several years ago. That's not a good example implementation to base a design on for a new language. Meanwhile the good things like separate heap/gc per 'thread' weren't copied. /forehead > did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. I don't think I know of another language that locks another thread, transfers control to it, and then finally calls the C function. That's crazy talk -- why they say "down the rabbit whole" in that comment. Most languages do some type checking (for instance error on passing a BigInteger > uint32_t to a function taking uint32_t) and marshall the arguments then call the C function. Maybe they need to pin an object or convert it to a C-friendly form (make a struct that describes properties of the object). But yeah in general the C interop is very simple in most languages. > And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript... I don't say "Google Dart" because Dart isn't an unsearchable, ambiguous name for a programming language. I do say "Apple Blocks" because 'blocks' is unsearchable in the context of programming languages. You can't blame me for Google choosing a terrible name. Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted?
- smeg 15y ago
  "What's changed in the last decade?" Uh...the need for highly scalable web servers handling tens/hundreds of thousands of lightweight, I/O bound, concurrent requests?
- cenuij 15y ago
  >Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted? I think neutral readers are smart enough to see your pervasive trolling and love of ignorant apples to oranges comparisons for what they are. My money is that you work for an organisation that competes with Google (you habitually troll almost any Google thread), you work on a competing language project, or perhaps both. In either case your trolling is really getting pretty desperate.
- agentS 15y ago
  > What's changed in the last decade? The nature of the problems we are trying to solve, and the hardware we are solving them on. > But yeah in general the C interop is very simple in most languages. You're not taking into account the fact that the C code cannot be allowed to block the main loop of the program; as is true in any event driven system. Yea, other programming languages might not have to deal with concurrency issues, either by ignoring threading, giving up on an asynchronous system, or giving up on C interop; none of which seem like a worthwhile sacrifice. What is your problem with this implementation technique? It's performant in practice, and its not in your face when actually writing code. This is not complexity you have to worry about. It happens "behind the scenes" as it were. Go might be challenging to search for, but you're not writing search queries, you're writing posts about programming. It's pretty unambiguous as far as I'm concerned. And fyi, I've never downvoted you. I think with the increasingly desperate tone in your writing, its not hard for people to realize that you're just hating on Go, and at least the responses to your misinformation are educational, and often interesting.
  - dmpk2k 15y ago
    > the hardware we are solving them on The increase in cores, NUMA now being pervasively inescapable, and context switching becoming cheaper, actually makes this problem worse for M:N threading. I don't have a problem with Go using M:N threading, but we must also be honest that something is being given up in order to gain something else; Go has a nicer programming model, but its performance envelope shrinks and becomes less predictable.

by agentS 15y ago

0xABADC0DA 15y ago

> Of the links in that list, 2 worked for me, and both were from 2002. Not exactly up to date information. The links for Ingo and Ulrich worked, these are enough of an indictment of M:N threading. What's changed in the last decade? OS gurus tried M:N threading and it failed. Java tried 'green threads' and it failed, and now Google Go devs are trying the same thing. Guess what's going to happen? > Also, Erlang, does something similar w.r.t. to multiplexing multiple processes onto fewer threads Erlang was written in Prolog and the desktop VM was single-process until several years ago. That's not a good example implementation to base a design on for a new language. Meanwhile the good things like separate heap/gc per 'thread' weren't copied. /forehead > did you imagine C interop with other languages is done in a nice, simple way? Any language needs a way to translate calling conventions from the source to the destination and back when doing interop. I don't think I know of another language that locks another thread, transfers control to it, and then finally calls the C function. That's crazy talk -- why they say "down the rabbit whole" in that comment. Most languages do some type checking (for instance error on passing a BigInteger > uint32_t to a function taking uint32_t) and marshall the arguments then call the C function. Maybe they need to pin an object or convert it to a C-friendly form (make a struct that describes properties of the object). But yeah in general the C interop is very simple in most languages. > And, yes, please stop calling it Google Go. People hardly ever say Microsoft C# or Sun Java or Apple Objective C, or Ericcson Erlang, or Netscape Javascript... I don't say "Google Dart" because Dart isn't an unsearchable, ambiguous name for a programming language. I do say "Apple Blocks" because 'blocks' is unsearchable in the context of programming languages. You can't blame me for Google choosing a terrible name. Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted?

smeg 15y ago
"What's changed in the last decade?" Uh...the need for highly scalable web servers handling tens/hundreds of thousands of lightweight, I/O bound, concurrent requests?
cenuij 15y ago
>Edit: What do you think it says to neutral readers when facts, reasons, links are downvoted? I think neutral readers are smart enough to see your pervasive trolling and love of ignorant apples to oranges comparisons for what they are. My money is that you work for an organisation that competes with Google (you habitually troll almost any Google thread), you work on a competing language project, or perhaps both. In either case your trolling is really getting pretty desperate.
agentS 15y ago
> What's changed in the last decade? The nature of the problems we are trying to solve, and the hardware we are solving them on. > But yeah in general the C interop is very simple in most languages. You're not taking into account the fact that the C code cannot be allowed to block the main loop of the program; as is true in any event driven system. Yea, other programming languages might not have to deal with concurrency issues, either by ignoring threading, giving up on an asynchronous system, or giving up on C interop; none of which seem like a worthwhile sacrifice. What is your problem with this implementation technique? It's performant in practice, and its not in your face when actually writing code. This is not complexity you have to worry about. It happens "behind the scenes" as it were. Go might be challenging to search for, but you're not writing search queries, you're writing posts about programming. It's pretty unambiguous as far as I'm concerned. And fyi, I've never downvoted you. I think with the increasingly desperate tone in your writing, its not hard for people to realize that you're just hating on Go, and at least the responses to your misinformation are educational, and often interesting.
- dmpk2k 15y ago
  > the hardware we are solving them on The increase in cores, NUMA now being pervasively inescapable, and context switching becoming cheaper, actually makes this problem worse for M:N threading. I don't have a problem with Go using M:N threading, but we must also be honest that something is being given up in order to gain something else; Go has a nicer programming model, but its performance envelope shrinks and becomes less predictable.