Operating system these days are not so much about the kernel, but about what abstractions the kernel offers. The Unix abstraction, i.e. everything is a file, is a good one, and if we think about it in modern terms, it's nothing more than object orientation: a specific class behind each file does specific things with the data it accepts. The same data can be sent to the same file, but the executed code would be different.
So why not make everything object oriented? forget processes and files, think objects. What files lack is retrospection, i.e. what messages accept and what format is the data they accept. That's the next logical progression from processes and files. With the appropriate object-oriented facilities, an O/S would become much more programmable and flexible.
For example, I wait for the day that you will be able to change window decoration color by 'right-click/select color'. Right now, no UI does that, simply because the system is not object-oriented enough.
Another example is searching. Filesystems have to support metadata in order to allow the user to store information in them. With object orientation + retrospection, each object has a nice set of properties discoverable at run-time, and hence no support for metadata exists. And the search can be extended to everything that is an object.
I've recently finished a 95,000 lines of code app for the company I work and there isn't a single delete statement in all the project. I've used shared and weak pointers.
People complain about C++ manual memory management all the time, but they just not use the language right.
But Michelle Obama was turned to a monkey because she is black, not because she has any other attribute that make her resemble a monkey. The people you mention (Bush, Ballmer, etc) all had something that made us think of a monkey, unlike Michelle Obama.
It's clearly racism and it's good for Google that censored the picture.
The American culture is the antithesis of science. The American culture is materialistic and centers around accumulation of wealth. In this environment, parents, teachers and politicians are not interested very much in science.
The only way for America to get people to choose science over something else is to make science profitable enough so as that people choose it over other disciplines. Unfortunately, this is not really possible. Science doesn't pay much.
The media tycoons do not want stuff that makes people think. The average Joe has been trained to accept shit like the latest Star Trek movie as wonderful pieces of SF. Real SF has no chance.
Africans are in tribal wars for centuries, while the rest of the world has progressed far enough to be able to exchange ideas worldwide by the speed of light. I do not see why should we care about their problems, since they clearly do not.
The.NET Micro framework is even tinier than the.NET Compact Framework! The.NET Micro Framework is for embedded devices with high constraints. It's useless for desktop applications.
I wouldn't hurry to declare victory of Open Source against Microsoft.
You can not, with C++, add functions to classes at runtime like you can with Objective-C.
Yes, you can do that as well. In fact, you can do the exact same object-oriented in C++ as in Objective-C. See this for more details.
You can not, with C++, change the access properties of a particular class instantiation (ie change a method from public to private) at runtime like you can with Java.
Besides being stupid, you can do that in C++ as well. If you have the header of the class, you can change the function access by hacking the header. Or you can write a binary compatible class with the class you want and use that. But, as I said, it's stupid.
You're clearly a C++-centric programmer who fails to understand that the more tools in your belt, the better. Every language has its use. C++ is an awesome language, for specific purposes, just like Java is (for specific purposes), same with Python, and Ruby, and many other languages.
I don't disagree with that. I am a Java and.NET programmer as well. But the point here is that Go offers nothing that cannot be done with C++.
That doesn't mean anything. Neither is Java. And neither is obj-c. Yet they're both languages that can be compiled to machine code, are dynamically bound, and are capable of providing runtime reflection. It's all about how it's implemented and the runtime.
It does. It is said that Go enhances productivity. I say it does not, because it's not an interpreted language. The edit-compile-run cycle still exists. Productivity is enhanced when I can pause the program, modify it and rerun it from the point it was, not from fast compile times (which helps, but not so much).
Your queue class is of no relation to Gochannels whatsoever. You're omitting the Goroutines, which you simply can not ignore. They do not equate to simple threads. Take a look at the Go channel source and you'll understand better what they're actually doing.
It's a green thread implementation, i.e. software threads. I don't want to reinvent the wheel. Not only pthreads is more than enough, but there are pthreads green threads implementations as well. By using my class (or any other Queue class) and pthreads (any implementation), the same thing as goroutines can be achieved.
Runtime reflection
Not enough to justify changing programming environments from Java and C# that also offer reflection.
true closures (something not offered any very many other compiled languages)
C++0x has closures.
array slices
Easily emulated with C++ templates.
and a built in parallel programming paradigm
Why does it matter if parallel/concurrent functionality is built-in or not? what it matters is what I can do with a specific programming language. Right now, I can do much more in C++/C#/Java than in Go, including parallel programming.
certainly justify at least giving it a thought for a very select category of problems.
It has a long way to go until it is a candidate for real projects (open source or commercial).
I should also mention that I'm no Google or Go fanboy. I'm actually a C++ compiler developer by trade so I've no beef with C++ either. In fact I love C++. I love many languages. My thesis was written in D, for example. I've also written commercial applications in Python, Ruby, Erlang, etc, etc.
Good for you. What compiler have you implemented? can I download it from somewhere? Are you interested in making a C++ successor? (yes I am interested in it, I'm fed up with C++'s problems all these year
This isn't quite true - JIT-generated code is mostly shared for reference types, with additional hidden method argument used to pass in missing info (such as type handle for RTTI, and instance/array factory for new) at runtime.
Well, if there is no difference in handling separate types, then C# will not produce the same code twice. But the general principle is the same as in C++: if the types are different enough, then different code is created.
In any case, it is an implementation detail. On language level, C# generics are not at all like templates, because C++ templates are glorified text substitution macros. Heck, you can write a template such that it's not possible to tell whether a particular line of code within it is a variable declaration or an operator application! This certainly isn't true of C# generics, which are really just a form of type generalization ("for all X,...").
Templates and generics have differences, but when it comes to type safety, they do the exact same thing: they make sure the underlying variables are handled correctly. Go's lack of templates makes writing typesafe reusable code impossible.
I know templates is not another name for generics. For example, in Java, types are erased and everything is converted to Object. Not so in C#, where the run-time compiler produces different instantiations of the code, in order to have the most optimized code. This is similar to C++'s templates, the only difference being that C++ does this at compile time.
Now, YouAreDumb() accesses various resources that may or may not be locked at any given time. Go detects these locks, and instead of spinning on it like an idiot (consuming resources for no good reason).. Go will go ahead and pause it, and start up another GoRoutine or continue one that has been paused previously.
Well, if YouAreDumb() accesses a mutex and the mutex is locked, the O/S puts the thread in the waiting thread list. Basic O/S theory.
And it can do this for hundreds of thousands of GoRoutines, *without* a thread created for each of them.
So can the O/S do, if you make each thread's stack minimal.
How sir, are you going to do that in C++ in only 100 lines of code?
I don't, that's what I am trying to tell you. The O/S will do that.
I'm pretty sure your fucked when you start pausing these routines that lock up resources and then get paused themselves. Its called deadlock and newbs who have never done concurrent programming don't have a clue about this shit and seem to think that things are "easy" and can be done in "100 lines of code"
I'm pretty sure you are dumb and have never done any real threaded code.
If the routine you have threaded is making special calls to a thread manager after checking to see if something it needs is blocked, then you have completely missed the point of Go. I am strongly suspecting that you have never done any concurrent programming, but instead have only threaded a couple independent routines (IF THAT.)
No, the Queue::get() method is a blocking call. Obviously, you have not understood anything.
That makes Go a C derivative. Being a derivative does not mean a language can't borrow ideas from other languages. So you are the one that's wrong.
Go supports hundreds of thousands of GoRoutines in the same address space. Good luck getting pthreads to support hundreds of thousands of threads.
You can actually create as many threads as there is space for the task structure and for the stacks. If you make a thread's stack sufficiently small, you can create millions of threads.
If you don't like that, you can make, let's say, 8 threads, and dispatch functions on those threads.
Still, no need for a new language.
Go also automatically pauses blocked GoRoutines and begins work on other unblocked ones, but I guess you think a simple queue can do that in 30 lines of code. How exactly are you going to be managing that queue from the blocked thread? Insert code into each routine you want to thread manually?
I don't have to pause anything. A queue's get operation is blocking: if you wait for a value, then the thread blocks on the queue's semaphore.
You are the one that is wrong. C# has generics, which are the same with C++ templates: different code is produced for each different template instantiation. The only difference is that in C++ the template instantiation happens at compile time, whereas in C# the template instantiation happens at run time.
it's also true that this offers some design flexibility that you can't get in C++.
Wrong. I can do with C++ the same design flexibility, including "dynamic" programming ala Java (that's what C++ was before templates) or dynamic programming ala Objective-C.
it seems like they're aiming more for convenience and rapid development speed.
Go is not interpreted.
Python or Ruby mode (languages even more dynamic and less type safe than Go), you can still write safe code.
You can even write safe code in raw assembly. So? not a point.
The type safety C++ gives you increases the development speed. If Go was interpreted, you may had a point. Since it's not, I don't see any advantage over C++.
I just want to point out that there are positives there too
Yes, there are. The imports and the garbage collection. But they are not enough to justify a shift to Go.
As for your 30 LOC Gochannel... don't forget that a Goroutine is not just a thread. Multiple Goroutines are multiplexed across many threads and the Gochannel.
I have just posted a Queue C++ class here. It can be used from as many threads as you like. It's totally thread safe. It's 36 lines of code.
Wrong. Seriously wrong. Very seriously wrong. Extremely very seriously wrong. Did I mention that this is wrong?
No, you are wrong. Type safety means that the program does not stop its execution due to a type mismatch error. So it's either that type mismatch errors are caught in compile time or that they are prevented at run time. The 'Any' type of Go does not guarantee prevention of type mismatch at run time. And Any is only for classes, not primitives.
Plenty of very popular languages put type names after the variable name, nor require parentheses for if's and for's. The most used programming language on the planet (VBA) for instance. Also "missing" in many languages are semicolons and curly braces.
But this is supposed to be a C derivative. What's the point of not using parentheses in 'if' and 'for', for example? Why maintain the curly brackets then?
No it can't. C++ doesn't even have portable threading yet. I have determined that you are smoking the my-language-is-better-than-yours crack pipe, while basking in the myopic kool-aid of a one compiler and one operating system universe of blindfolded ignorance.
Oh please. A Go channel is nothing more than a queue. A synchronized queue in C++ is no more than 30 lines of code, using pthreads.
Go provides an "Any" container, which "may be used to implement generic programming similar to templates in C++".
I can do the same in C++, using boost::any or rolling my own variant type. Still, it's not templates. It's not type safe.
It's worth noting though that this is a dynamically bound language feature, which means it is checked and enforced at runtime rather than compile time -- both a positive and a negative depending on how you look at it.
Certainly negative from a performance standpoint.
It provides for some more interesting programs to be written that do fun things at runtime, but on the down side it means you lose a lot of the compile time type-checking that C++ provides and can save a lot of debugging time later on.
Definitely negative, then.
I also challenge you to come up with a solution that equates to Go's built in Channel's in less than 100 lines of C++. What you're actually saying is you "can implement Go's Goroutine's AND Channels in less than 100 lines of code in portable, cross platform, C++". But, let's give you the benefit of the doubt and say that you've already go some mechanism for emulating a Goroutine (which by the way allows one to "mutiplex independently executing functions onto a set of threads"). I think _just_ the thread safe code that would implement all the necessary locks and barriers for a _single_ platform would probably be more than 100 lines, and would not be portable (ie, it would be pthreads, or win32 specific).
Bullshit. The channel class in c++ is about 30 lines of code, using pthreads. It includes a semaphore for notifying the receiver, a container of data and a mutex to serializes access to the container. It contains two methods (put and get). If you want a bidirectional channel, you just put two channels in one.
For example your assertion that "in Go, a List class would have to use void* types, throwing type safety out of the window" is just plain wrong.
It still throws type safety out of the window, by using 'any'.
Templates is one of C++'s advantage over any other language (except D that implements them). Without templates, type safe containers and reusable algorithms cannot be implemented. For example, in Go, a List class would have to use void* types, throwing type safety out of the window.
The syntax is also not that good. That the type goes after the variable name, the missing parentheses in 'if' and 'for' statements are syntactic changes that offer no better readability over C.
Finally, the built-in channel mechanism is something that can be done in C++ in less than 100 lines of code.
Slashdot Mirror
Operating system these days are not so much about the kernel, but about what abstractions the kernel offers. The Unix abstraction, i.e. everything is a file, is a good one, and if we think about it in modern terms, it's nothing more than object orientation: a specific class behind each file does specific things with the data it accepts. The same data can be sent to the same file, but the executed code would be different.
So why not make everything object oriented? forget processes and files, think objects. What files lack is retrospection, i.e. what messages accept and what format is the data they accept. That's the next logical progression from processes and files. With the appropriate object-oriented facilities, an O/S would become much more programmable and flexible.
For example, I wait for the day that you will be able to change window decoration color by 'right-click/select color'. Right now, no UI does that, simply because the system is not object-oriented enough.
Another example is searching. Filesystems have to support metadata in order to allow the user to store information in them. With object orientation + retrospection, each object has a nice set of properties discoverable at run-time, and hence no support for metadata exists. And the search can be extended to everything that is an object.
I've recently finished a 95,000 lines of code app for the company I work and there isn't a single delete statement in all the project. I've used shared and weak pointers.
People complain about C++ manual memory management all the time, but they just not use the language right.
But Michelle Obama was turned to a monkey because she is black, not because she has any other attribute that make her resemble a monkey. The people you mention (Bush, Ballmer, etc) all had something that made us think of a monkey, unlike Michelle Obama.
It's clearly racism and it's good for Google that censored the picture.
Can it; I think not. It's incredibly cool to write qsort in just 2 lines of code, but it's incredibly slow.
Have you ever seen backup systems in Star Trek, for example? you haven't. The future requires no backups.
...always on the forefront of exploration!!! ;-)
The American culture is the antithesis of science. The American culture is materialistic and centers around accumulation of wealth. In this environment, parents, teachers and politicians are not interested very much in science.
The only way for America to get people to choose science over something else is to make science profitable enough so as that people choose it over other disciplines. Unfortunately, this is not really possible. Science doesn't pay much.
The media tycoons do not want stuff that makes people think. The average Joe has been trained to accept shit like the latest Star Trek movie as wonderful pieces of SF. Real SF has no chance.
Africans are in tribal wars for centuries, while the rest of the world has progressed far enough to be able to exchange ideas worldwide by the speed of light. I do not see why should we care about their problems, since they clearly do not.
The .NET Micro framework is even tinier than the .NET Compact Framework! The .NET Micro Framework is for embedded devices with high constraints. It's useless for desktop applications.
I wouldn't hurry to declare victory of Open Source against Microsoft.
If the Vatican insists, Chuck will kill the Pope with a roundhouse kick.
Only if Chuck Norris lets him.
Yes, you can do that as well. In fact, you can do the exact same object-oriented in C++ as in Objective-C. See this for more details.
Besides being stupid, you can do that in C++ as well. If you have the header of the class, you can change the function access by hacking the header. Or you can write a binary compatible class with the class you want and use that. But, as I said, it's stupid.
I don't disagree with that. I am a Java and .NET programmer as well. But the point here is that Go offers nothing that cannot be done with C++.
It does. It is said that Go enhances productivity. I say it does not, because it's not an interpreted language. The edit-compile-run cycle still exists. Productivity is enhanced when I can pause the program, modify it and rerun it from the point it was, not from fast compile times (which helps, but not so much).
It's a green thread implementation, i.e. software threads. I don't want to reinvent the wheel. Not only pthreads is more than enough, but there are pthreads green threads implementations as well. By using my class (or any other Queue class) and pthreads (any implementation), the same thing as goroutines can be achieved.
Not enough to justify changing programming environments from Java and C# that also offer reflection.
C++0x has closures.
Easily emulated with C++ templates.
Why does it matter if parallel/concurrent functionality is built-in or not? what it matters is what I can do with a specific programming language. Right now, I can do much more in C++/C#/Java than in Go, including parallel programming.
It has a long way to go until it is a candidate for real projects (open source or commercial).
Good for you. What compiler have you implemented? can I download it from somewhere? Are you interested in making a C++ successor? (yes I am interested in it, I'm fed up with C++'s problems all these year
Well, if there is no difference in handling separate types, then C# will not produce the same code twice. But the general principle is the same as in C++: if the types are different enough, then different code is created.
Templates and generics have differences, but when it comes to type safety, they do the exact same thing: they make sure the underlying variables are handled correctly. Go's lack of templates makes writing typesafe reusable code impossible.
I know templates is not another name for generics. For example, in Java, types are erased and everything is converted to Object. Not so in C#, where the run-time compiler produces different instantiations of the code, in order to have the most optimized code. This is similar to C++'s templates, the only difference being that C++ does this at compile time.
Well, if YouAreDumb() accesses a mutex and the mutex is locked, the O/S puts the thread in the waiting thread list. Basic O/S theory.
So can the O/S do, if you make each thread's stack minimal.
I don't, that's what I am trying to tell you. The O/S will do that.
I'm pretty sure you are dumb and have never done any real threaded code.
No, the Queue::get() method is a blocking call. Obviously, you have not understood anything.
That makes Go a C derivative. Being a derivative does not mean a language can't borrow ideas from other languages. So you are the one that's wrong.
You can actually create as many threads as there is space for the task structure and for the stacks. If you make a thread's stack sufficiently small, you can create millions of threads.
If you don't like that, you can make, let's say, 8 threads, and dispatch functions on those threads.
Still, no need for a new language.
I don't have to pause anything. A queue's get operation is blocking: if you wait for a value, then the thread blocks on the queue's semaphore.
You are. It's no shame in admitting it.
You are the one that is wrong. C# has generics, which are the same with C++ templates: different code is produced for each different template instantiation. The only difference is that in C++ the template instantiation happens at compile time, whereas in C# the template instantiation happens at run time.
Wrong. I can do with C++ the same design flexibility, including "dynamic" programming ala Java (that's what C++ was before templates) or dynamic programming ala Objective-C.
Go is not interpreted.
You can even write safe code in raw assembly. So? not a point. The type safety C++ gives you increases the development speed. If Go was interpreted, you may had a point. Since it's not, I don't see any advantage over C++.
Yes, there are. The imports and the garbage collection. But they are not enough to justify a shift to Go.
I have just posted a Queue C++ class here. It can be used from as many threads as you like. It's totally thread safe. It's 36 lines of code.
Please. Typesafe containers without templates can not be done. Period.
No, you are wrong. Type safety means that the program does not stop its execution due to a type mismatch error. So it's either that type mismatch errors are caught in compile time or that they are prevented at run time. The 'Any' type of Go does not guarantee prevention of type mismatch at run time. And Any is only for classes, not primitives.
But this is supposed to be a C derivative. What's the point of not using parentheses in 'if' and 'for', for example? Why maintain the curly brackets then?
Oh please. A Go channel is nothing more than a queue. A synchronized queue in C++ is no more than 30 lines of code, using pthreads.
You can always set the min stack of a thread using pthreads.
I can do the same in C++, using boost::any or rolling my own variant type. Still, it's not templates. It's not type safe.
Certainly negative from a performance standpoint.
Definitely negative, then.
Bullshit. The channel class in c++ is about 30 lines of code, using pthreads. It includes a semaphore for notifying the receiver, a container of data and a mutex to serializes access to the container. It contains two methods (put and get). If you want a bidirectional channel, you just put two channels in one.
It still throws type safety out of the window, by using 'any'.
Templates is one of C++'s advantage over any other language (except D that implements them). Without templates, type safe containers and reusable algorithms cannot be implemented. For example, in Go, a List class would have to use void* types, throwing type safety out of the window.
The syntax is also not that good. That the type goes after the variable name, the missing parentheses in 'if' and 'for' statements are syntactic changes that offer no better readability over C.
Finally, the built-in channel mechanism is something that can be done in C++ in less than 100 lines of code.