Attempting to kiss a preteen girl on the lips is beyond boorish, it is assault. But you are right about one thing: it is evidence, and could be used in a court of law in support of other allegations.
...It also shields them from the vagaries of the C++ standardization folks, which must be nice for them in any case.
Non-argument. If you don't like new features in C++ then don't use them. Your existing code will continue to work just fine. Personally, some of the recent additions are godsends. For example, have you ever tried to extend an STL container with a functor? Just disgusting. Lambdas (and std::function) are vastly superior.
...solving this would only solve the problem of build times, not the problem of existing concurrent code at Google being too hairy. At the very least, in addition to solving the build time problems, a replacement for Go's functionality would have to be developed on top of C++ and the C++ clients rewritten to use it.
So instead of making a sensible investment in extending C++ with concurrency support it was decided to create an entire new ecosystem. Given a sufficient quantity of energy drinks and powerpoint slides, I can see how that made sense to someone in control of more budget than they knew what to do with.
Everything you mentioned was already covered by Google's C++ style guidelines for years.
But they still do insane things with templates anyway, and most probably flagrantly ignore the other good practices above and basically everything else in the style book, except possibly the whitespace rules. Don't ask me how I know, I just know.
OK, I'll give you that if it's true. Has it been demonstrated? BTW, what's with the anon coward posts? If it's just because you don't normally post here then please bear in mind it's a bit like wearing nose glasses at a cocktail party.
NYT simply reported on Trump's financial disclosure... that in no way constitutes and endorsement from NYT that the disclosure is honest or complete. In fact, I have seen a professional opinion that the $550 valuation ascribed to golf courses is overstated by a factor of four. Where there is smoke, there is fire. I would not be the least surprised if it eventually comes out that his true net worth is negative as evidenced by a personal bankruptcy filing after failing to become POTUS. See, there has to be a reason why Trump nickel and dimes his little frauds, just look at the activity of his "charitable" foundation to see what I mean.
thanks for editing this out: "there are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse."
Ok, to wrap it up: goroutines are not OS threads like you originally suggested.
I did not, you are putting words in my mouth. I said: "there are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse." And I said that goroutines are just threads with syntactic sugar. I stand by that too.
There's not a a clone syscall associated with every goroutine;
There need not be, though it's fairly safe to say that it would work better than what Go actually has right now. What I think Go actually has right now is a crappy home-rolled scheduler along with a bunch of hacks to work around not knowing as much as it needs to know about processor load, memory affinity etc.
Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.
There you go: goroutines are threads. My point. Thank you.
And I know about Green Threads, I mentioned them in another post. I know what the issues are and why we now use native threads instead for Linux threading. Go guys need to rediscover all that, that's the everlasting thrill of NIH.
A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.
What is simple about that? Have you got any idea about the nature of the mechanism that is required to make code execute concurrently with other code on the same or different processor?
It is lightweight, costing little more than the allocation of stack space.
Oh, you mean like a Linux thread created by the clone syscall, with all resources shared.
And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.
Oh, you mean like a Linux thread created by the clone syscall, which only allocates a virtual address range for the stack and faults in actual memory as required.
Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.
Oh, you mean like green threads which used to be the threading scheme of choice on Linux until the native threading support exceeded it in scalability, efficiency and reliability long ago.
Their design hides many of the complexities of thread creation and management."
And calling them "goroutines" hides the inconvenience of calling them what they are: threads with syntactic sugar.
Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are. Emulating the clone syscall in user space may not necessarily be a win, quite the contrary. Note that the compiler does not need to call the syscall every time a new thread is needed, it can keep a pool, which would most likely be a way better design than unnecessarily emulating native OS threads in userspace.
Just to put things in perspective: to implement threads (aka goroutines) you need a scheduler, there is no way around it. Without even looking at the implementation I can tell you that the Go scheduler is naive and will be prone to undesired behavior compared to the native kernel scheduler.
...Basically Googles biggest problem with C++ was a large codebase of legacy code nobody wanted to touch and Go solved this by simply throwing everything away, starting from scratch. It means maintaining less since they can just chuck decades of work into the garbage bin everytime they hire a new Rob Pike.
Ding, you nailed it. With Go they can create a new, large codebase of legacy code that nobody wants to touch, with the added complication that you need to train each new hire for months in the new oddball language that wasn't in the curriculum.
Slashdot Mirror
Au contraire, it is you who fail to understand what the word evidence is. Video of the perp is treated as highly credible.
Attempting to kiss a preteen girl on the lips is beyond boorish, it is assault. But you are right about one thing: it is evidence, and could be used in a court of law in support of other allegations.
Show some actual evidence, or STFU.
Happy to oblige.
You mean Trump likes the ladies? Is that forbidden now?
In certain ways. Here is a 7-something year old girl that Trump tried to kiss on the lips at his rally the other day, on video.
...It also shields them from the vagaries of the C++ standardization folks, which must be nice for them in any case.
Non-argument. If you don't like new features in C++ then don't use them. Your existing code will continue to work just fine. Personally, some of the recent additions are godsends. For example, have you ever tried to extend an STL container with a functor? Just disgusting. Lambdas (and std::function) are vastly superior.
Given the scale of their code, they probably deemed it the better option for them.
Given the scale of their code, it's a safe bet that the vast majority of it will stay exactly as it is.
...solving this would only solve the problem of build times, not the problem of existing concurrent code at Google being too hairy. At the very least, in addition to solving the build time problems, a replacement for Go's functionality would have to be developed on top of C++ and the C++ clients rewritten to use it.
So instead of making a sensible investment in extending C++ with concurrency support it was decided to create an entire new ecosystem. Given a sufficient quantity of energy drinks and powerpoint slides, I can see how that made sense to someone in control of more budget than they knew what to do with.
Everything you mentioned was already covered by Google's C++ style guidelines for years.
But they still do insane things with templates anyway, and most probably flagrantly ignore the other good practices above and basically everything else in the style book, except possibly the whitespace rules. Don't ask me how I know, I just know.
So basically, yes Intel has lost the lead. TSMC will be ahead of everybody in 2018.
It's the sense I'm getting. And basically, it reflects the shift from a PC-centric market to phone-centric.
Worst thing is, they leave out the inb4.
Has Samsung actually leapfrogged Intel in fabrication technology?
Now that I think of it, Linux may well be able to handle 1,000,000 threads natively. There isn't any actual limit, except memory for stacks.
OK, I'll give you that if it's true. Has it been demonstrated? BTW, what's with the anon coward posts? If it's just because you don't normally post here then please bear in mind it's a bit like wearing nose glasses at a cocktail party.
The message I'm getting here is that there's a Go cult, and I'm being "messaged" by Go cultists.
NYT simply reported on Trump's financial disclosure... that in no way constitutes and endorsement from NYT that the disclosure is honest or complete. In fact, I have seen a professional opinion that the $550 valuation ascribed to golf courses is overstated by a factor of four. Where there is smoke, there is fire. I would not be the least surprised if it eventually comes out that his true net worth is negative as evidenced by a personal bankruptcy filing after failing to become POTUS. See, there has to be a reason why Trump nickel and dimes his little frauds, just look at the activity of his "charitable" foundation to see what I mean.
At least we all now understand that "goroutines" are just threads, with marketing. Right?
Go implements a M:N scheduler which is anything but 'naive'. https://morsmachine.dk/go-sche...
You are right, M:N is stupidly complex. And hard to get nice behaviour out of. The naive part is thinking that it's needed, at least on Linux.
thanks for editing this out: "there are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse."
Ok, to wrap it up: goroutines are not OS threads like you originally suggested.
I did not, you are putting words in my mouth. I said: "there are other ways to do threading involving userspace scheduling but they are generally no better than using the standard syscall and typically much worse." And I said that goroutines are just threads with syntactic sugar. I stand by that too.
There's not a a clone syscall associated with every goroutine;
There need not be, though it's fairly safe to say that it would work better than what Go actually has right now. What I think Go actually has right now is a crappy home-rolled scheduler along with a bunch of hacks to work around not knowing as much as it needs to know about processor load, memory affinity etc.
Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.
There you go: goroutines are threads. My point. Thank you.
And I know about Green Threads, I mentioned them in another post. I know what the issues are and why we now use native threads instead for Linux threading. Go guys need to rediscover all that, that's the everlasting thrill of NIH.
Especially SNL
A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.
What is simple about that? Have you got any idea about the nature of the mechanism that is required to make code execute concurrently with other code on the same or different processor?
It is lightweight, costing little more than the allocation of stack space.
Oh, you mean like a Linux thread created by the clone syscall, with all resources shared.
And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.
Oh, you mean like a Linux thread created by the clone syscall, which only allocates a virtual address range for the stack and faults in actual memory as required.
Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.
Oh, you mean like green threads which used to be the threading scheme of choice on Linux until the native threading support exceeded it in scalability, efficiency and reliability long ago.
Their design hides many of the complexities of thread creation and management."
And calling them "goroutines" hides the inconvenience of calling them what they are: threads with syntactic sugar.
You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter
Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are. Emulating the clone syscall in user space may not necessarily be a win, quite the contrary. Note that the compiler does not need to call the syscall every time a new thread is needed, it can keep a pool, which would most likely be a way better design than unnecessarily emulating native OS threads in userspace.
Just to put things in perspective: to implement threads (aka goroutines) you need a scheduler, there is no way around it. Without even looking at the implementation I can tell you that the Go scheduler is naive and will be prone to undesired behavior compared to the native kernel scheduler.
They're not making the language for you. They're making it for themselves...
Actually no, they're making it for a captive audience of Google employees who are paid to not complain about it.
...Basically Googles biggest problem with C++ was a large codebase of legacy code nobody wanted to touch and Go solved this by simply throwing everything away, starting from scratch. It means maintaining less since they can just chuck decades of work into the garbage bin everytime they hire a new Rob Pike.
Ding, you nailed it. With Go they can create a new, large codebase of legacy code that nobody wants to touch, with the added complication that you need to train each new hire for months in the new oddball language that wasn't in the curriculum.
Boy, those Google engineers sure are stupid!
I did not say stupid people, I said smart people. With ADHD. Don't believe me, do your own research.
You're wrong. Depending on the implementation, generics can indeed come with a performance hit; the main example is Java...
I was talking about C++, or did the reference to templates not make that clear?