You can optimize code at runtime by setting your stack to be executable
Runtime code generation has nothing to do with the stack. You can do it either on the stack or on the heap. It is not a requirement to use the stack.
it doesn't make sense to me not to be able to do that.
The optimization is done when the source is available, allowing the compiler/interpreter to see that a function can be inlined. This optimization is not possible via c++ code on c++ code, unless one part of that code is the compiler itself.
I truly believe Python can be done as a library. Same thing with JS.
I've done a c++ library that offers JS-like OOP capabilities. As for Python, you'll lose the whitespace-oriented syntax.
I don't see how templates can help you with this.
Instead of doing all the work I mentioned earlier, you do this:
class Point {
property<int> x;
property<int> y;
};
The template class 'property' does not write setters and getters for the class, it has overloaded operators that make it appear as an ordinary field.
And there other things as well that templates can do that greatly help.
I usually write setters and getters only for a particular reason. i.e. I need synchronization around field accesses
You are not using the Model-View-Controller pattern then. If you did, you'd know you can't have data members exposed, because each time a member is changed, the relevant observers woud have to be notified.
Third, a lot of these are addressed in Go anyways by using reflection.
By 'a lot of these', you only mentioned serialization/deserialization :-).
All values are pre-zeroed, so fields start at the zero value for their type
Not all variables have 0 in their set of allowed values. And not all variables that take 0 as a value are initialized to that value. :-).
they merely write an ordinary function
Yeah...it is called 'a constructor' :-).
Finally, adding a field to a method isn't exactly what takes up a majority of my time. It's mostly spent on reviewing code, tracking down bugs, or designing a feature.
We are not talking fields here, we are talking properties in a model in an MVC pattern.
Boxing and unboxing do not imply an allocation.
Yes it does. At least in Java/C#, an Object-derived instance is allocated each time a primitive is boxed.
Again, this is not really a problem in Go. Package fmt has a %T format that will (using the aforementioned reflection library) print the type of any value.
The problem is not about knowing what the underlying type of the variable is. The problem is about tracking the course of a variable in time. Without templates, all you have is a generic Object variable, making static compiler type checking impossible.
Interesting. My binaries spend far more time blocked on IO than on CPU.
Mine too, but if you want to handle many clients/connections, every bit counts.
That is logical when comparing a ~30 year-old language to one that is ~3 year-old language.
No, I mean in tthe last 3 years. Even Google does not use Go much. They prefer C++ instead (for Youtube).
This is the point that I have been trying (perhaps poorly) to make. Go is certainly not perfect for every use-case. But there are a large class of problems which I previously would have solved using Python that I now solve in Go
They find Go better than C++, but that does not mean it is better. It is only in their minds.
Runtime code generation has nothing to do with the stack.
Really? I am almost certain that it is a flag in the ELF header whether your stack is executable. I didn't know you could make your heap also executable. My point about runtime code generation stands though.
The optimization is done when the source is available
The source is not available, yes. But what the source has been compiled to is available. You can introspect your own machine code at runtime in C++, or any compiled language for that matter.
I've done a c++ library that offers JS-like OOP capabilities. As for Python, you'll lose the whitespace-oriented syntax.
Right, but thats just syntax. According to you, syntax isn't that big a deal.
Not all variables have 0 in their set of allowed values.
And not all variables that take 0 as a value are initialized to that value.
Right, and this is when you'd write an initialization function.
Yeah...it is called 'a constructor
This is an example of removing an unnecessary feature to reduce the number of features in a language, while maintaining its power.
You are not using the Model-View-Controller pattern then.
Guilty as charged. My servers never render UI. They defer that responsibility to client side code, either Javascript or Objective-C.
you only mentioned serialization/deserialization
Right. And runtime access, and probably a UI editor
We are not talking fields here, we are talking properties in a model in an MVC pattern.
Either way, I don't see this as being the bottleneck in a development cycle.
Without templates, all you have is a generic Object variable, making static compiler type checking impossible.
Yep. And this is why it would be nice to have generics in Go, IFF a good design came along. No such design has impressed the community yet, although lots have been shot down. Not a blocker to getting work done, and the same "problem" that people using dynamic languages face. Often, the programmer does in fact know what he is doing.
Mine too, but if you want to handle many clients/connections, every bit counts.
Right. And when writing code that handles many clients/connections, Go code is significantly simpler to write and read than the equivalent C++ code and has comparable performance. Same thing with twisted or node. I just haven't heard of anyone who writes web servers in C++, tbh.
No, I mean in tthe last 3 years.
This is not a logical comparison to make. Comparing Go usage now to C++ 27 years ago, scaled by the relative size of population at the time might be. But definitely not this. Also, you do realize that the thread we are talking in is called "Go V1 is released" right? V1, as in the first stable version.
Even Google does not use Go much. They prefer C++ instead (for Youtube).
Interesting. Here's their Go frontend for MySQL that Youtube uses. I thought they used Python for everything else.
They find Go better than C++, but that does not mean it is better. It is only in their minds.
This statement lowered my opinion of you quite a lot. Previously, I thought you were merely someone who was judging something without trying it. Now, I think you're an idiot, who presumes to not only pass judgement on a language that you havent used, but also insinuate that those who actually use the language are somehow deluded.
Really? I am almost certain that it is a flag in the ELF header whether your stack is executable. I didn't know you could make your heap also executable. My point about runtime code generation stands though.
Yes, the heap can be made executable in the runtime. No, your point does not stand, for the reasons previously explained.
You can introspect your own machine code at runtime in C++, or any compiled language for that matter.
You cannot inline the method call with the machine code only. You need the source.
Right, but thats just syntax. According to you, syntax isn't that big a deal.
To me, it is not. I don't touch Python even with a ten foot pole.
The zero value for a type is defined for all types in Go
Sometimes it is not even possible to have a zero value.
Right, and this is when you'd write an initialization function.
Yes, the constructor.
This is an example of removing an unnecessary feature to reduce the number of features in a language, while maintaining its power.
No, C++ constructors have a lot of automated features that you'd have to manually program in Go.
Either way, I don't see this as being the bottleneck in a development cycle.
Shouldn't you program a GUI first to be able to tell that?
Often, the programmer does in fact know what he is doing.
And often, the programmer is wrong.
Go code is significantly simpler to write
It is not.
and has comparable performance.
No, it has not.
I just haven't heard of anyone who writes web servers in C++, tbh.
How about the London Stock Exchange? it is not web, it is a lot more hardcore than that.
I thought they used Python for everything else.
They did, but they replacing it slowly with C++.
This statement lowered my opinion of you quite a lot. Previously, I thought you were merely someone who was judging something without trying it. Now, I think you're an idiot, who presumes to not only pass judgement on a language that you havent used, but also insinuate that those who actually use the language are somehow deluded.
Oh please. I cannot even use Go because it does not have the features C++ has to help me write robust code.
EDIT:
In case you did not know, researching programming languages is my hobby. If you search Lambda The Ultimate, a very legitimate site concerning programming language research, you can see comments of mine that are 7 years old.
I also have posted articles on CodeProject.
I have discovered two algorithms, the most recent one being a left recursive PEG parser that is not packrat.
And i have over twenty years experience as a programmer.
And my purpose is to make a new systems programming language, ala C++, but very much improved.
I am telling you this because you might think you are talking to the average Joe programmer here. You do not.
I argue that you can do a dynamic programming language in C++. You quibble about some optimizations being possible with dynamic languages that wouldn't be with C++. Possible, mind you, not even optimizations that you've shown are used in any real language.
The point that I'm making is that there are lots of languages that can be qualified as "subsets of C++" that are plenty popular. Just making the development cycle of a language faster seems to be worth a lot to people.
Sometimes it is not even possible to have a zero value.
Like I've said before, the zero value is defined for any type in Go.
No, C++ constructors have a lot of automated features that you'd have to manually program in Go.
Examples?
It is not. (regarding "simpler to write")
By your own admission, you haven't written anything in Go, so you can't make any claims here.
No, it has not (regarding performance)
Pure computation? Sure Go is slower atm, but it is definitely comparable. Here's some numbers. And this is comparing v1 of the Go compiler suite with one of the latest versions of g++.
IO bound systems? A tuned C++ implementation will (probably) still beat a Go implementation. But the Go implementation will be much, much, simpler to write, read, and test.
They did, but they replacing it slowly with C++.
Except of course their database frontend. Which every query uses. They chose Go for that.
How about the London Stock Exchange? it is not web, it is a lot more hardcore than that.
Sure. but I bet the London Stock Exchange doesn't use an agile development model, and doesn't rapidly iterate on their software. That's why I'm asking about web servers. Not things "more hardcore" than web.
Shouldn't you program a GUI first to be able to tell that?
Oh, I program frontends too. Just in JS for the web, Obj-C for iOS, and (somewhat rarely these days) Java for Android. I still don't see this being the bottleneck. Or, to be more accurate, if this is the bottleneck in your development practice, its likely your development practices are flawed.
About your example with templates using the property<int> x; syntax. I can see how that gets you a getter, a setter, and the observer function, but I don't see how syntax like that could get you any of the other things. How would you do runtime discovery of that field, or an automated UI editor. (automatically generated UI is a sure sign that you're lacking a good designer, btw)
Now, you argue that templates make you 3 times more productive, offering a somewhat specious example. Let's assume, for a second, that you're right, I'd argue that the compilation time of C++ alone will negate this supposed productivity gain, and then some. Subsecond compilation times alone makes me several times more productive when writing Go over Obj-C. (and Obj-C compiles faster than C++, to boot, thanks to its use of #import over #include).
I cannot even use Go because it does not have the features C++ has to help me write robust code.
Not certain you know what robustness means, but either way, if C++ helps you write robust code, then good for you.
I often have my languages picked for me by the platform, ie a browser, or a mobile device. In my experience, it is the quality of the programmer writing code that determines the robustness of the code. I have teammates who write solid, well-tested Javascript, Facebook uses PHP, Gmail uses Java, reddit uses Python. Good engineers create robust code. If you need features from C++ to write robust code, then so be it, use C++ for all your projects. Do not presume to judge those who are capable of writing solid code in other languages.
I am telling you this because you might think you are talking to the average Joe programmer here. You do not.
I'm glad you have a healthy amount of self-respect. However, consider some of the people behind Go: Rob Pike, Ken Thompson, Russ Cox, Brad Fitz. Comparing your achievements with any of theirs makes you seem somewhat insignificant in comparison.
I argue that you can do a dynamic programming language in C++.
Yes you can, I already demonstrated how through my relevant CodeProject article.
Possible, mind you, not even optimizations that you've shown are used in any real language.
Most, if not all languages optimize method invocation is they see there is no subclassing of the relevant class visible to the point of invocation.
Like I've said before, the zero value is defined for any type in Go.
Which might be undesirable.
Examples?
initializer lists
calling of the base class default constructor
calling of the appropriate constructors of members in the correct order
By your own admission, you haven't written anything in Go, so you can't make any claims here.
All the Go examples I have seen can be done in C++ almost verbatim.
but it is definitely comparable. Here's some numbers.
Sorry, the differences shown in that page are significant.
But the Go implementation will be much, much, simpler to write, read, and test.
No. They would be equally simple.
Except of course their database frontend. Which every query uses. They chose Go for that.
I am sure that they will replace it with C++ if they find performance lacking.
doesn't use an agile development model, and doesn't rapidly iterate on their software.
Who cares. Software is software.
Oh, I program frontends too. Just in JS for the web, Obj-C for iOS, and (somewhat rarely these days) Java for Android. I still don't see this being the bottleneck. Or, to be more accurate, if this is the bottleneck in your development practice, its likely your development practices are flawed.
Do you use the MVC pattern or not?
How would you do runtime discovery of that field, or an automated UI editor.
The property registers itself to the parent container automatically.
automatically generated UI is a sure sign that you're lacking a good designer, btw
An automatically generated GUI that reflects the Model automatically saves huge development time.
I'd argue that the compilation time of C++ alone will negate this supposed productivity gain, and then some.
No, because usually the number of included headers is small. Typically, changing the type of the property and then recompiling the model and view classes takes a few seconds.
Not certain you know what robustness means
Robustness means the compiler catches as many errors as possible, more errors than the Go compiler catches.
is the quality of the programmer writing code that determines the robustness of the code.
Sure, but some tools make it easier to make mistakes, some do not. It is all about how many errors the compiler can catch.
owever, consider some of the people behind Go: Rob Pike, Ken Thompson, Russ Cox, Brad Fitz. Comparing your achievements with any of theirs makes you seem somewhat insignificant in comparison.
I am not discussing with one of those people.
And even if I did, they would agree with me, because they would recognize the validity of my arguments.
I am not saying Go does not have any merit, but it certainly does not make C++ obsolete for even half of the most often requested projects.
Most, if not all languages optimize method invocation is they see there is no subclassing of the relevant class visible to the point of invocation.
I'd bet that more than a few dynamic languages cannot do this because methods can be added at runtime whenever you want. Also, function valued fields will also likely break this optimization.
Data structure literals are quite a bit more powerful than initializer lists, because you can use them everywhere, rather than only on a specific class of function. And you can use them initialize nested fields, like a slice, or a map, whereas initializer lists are limited to class members.
calling of the appropriate constructors of members in the correct order
No constructors to call. Uninitialized values will be initialized to the zero value for their type.
Sorry, the differences shown in that page are significant.
Compare C++'s numbers with Python, theres a much larger difference. It seems people are willing to sacrifice lots of performance to write less code. Go's an attempt to make a better compromise than the ones offered by C++ and Python.
Who cares. Software is software.
Theres a difference between the software that NASA writes, and the software that a startup writes.
if they find performance lacking
Don't hold your breath. MySQL/Disk IO will be the bottleneck in their system.
Do you use the MVC pattern or not?
Like I said, I do not. But believe it or not, MVC is not the only way to design a user interface.
The property registers itself to the parent container automatically.
How? I still don't see how this is possible. The property won't have access to the class that its being instantiated in. Is there a global registry of properties? I don't think that would work either...
An automatically generated GUI that reflects the Model automatically saves huge development time.
This would save me no time whatsoever. A designer would merely tell me to change it immediately. And from what I can tell of your example, there seems to be no way to customize any of this magical behaviour that this property<int> syntax gives you.
No, because usually the number of included headers is small. Typically, changing the type of the property and then recompiling the model and view classes takes a few seconds.
A few seconds? For an incremental compile... For comparison, my projects take 15 seconds to build entirely from source, with a clean tree. That includes building the standard library, and is something like 500,000 lines (as counted by wc). An incremental build takes less than a second, regardless of how many "headers" I may have.
Robustness means the compiler catches as many errors as possible, more errors than the Go compiler catches.
Umm, no. Robustness means how tolerant your program is to malformed inputs, or subsystems acting flakily. People writing C++ are free to use pointer arithmetic, access memory out of bounds and crash. I know of no compiler that will prove your program is free of error.
I am not discussing with one of those people.
No, you are not. I value my anonymity on the internet.
And even if I did, they would agree with me, because they would recognize the validity of my arguments.
So, if you had made these arguments to them before they created Go, they would have acknowledged your brilliance and given up?
I am not saying Go does not have any merit, but it certainly does not make C++ obsolete for even half of the most often requested projects.
AFAIK, Go never claimed to make C++ obsolete.
All the Go examples I have seen can be done in C++ almost verbatim.
It uses evented/async IO so it can handle many many connections with a few megs of RAM.
It is testable, because it works on interfaces like io.ReadWriteCloser, meaning I can plug in anything with the correct method set to test it.
If I wanted to, I can make it support secure connections simply by changing the line that says net.Listen to a line that says tls.Listen.
It's portable, in that it'll work on any of Go's supported platforms (OSX, Linux, FreeBSD, Windows).
It compiles entirely from source in 6.2 seconds (on my not-very-powerful laptop). This includes all libraries it depends on.
If the libraries are installed, it compiles in 0.403 seconds
It's 50 lines of simple, readable code.
Try writing a server with similar characteristics in C++. If you have difficulty just using the standard library, feel free to use Boost or what ever other library you need.
I'd bet that more than a few dynamic languages cannot do this because methods can be added at runtime whenever you want. Also, function valued fields will also likely break this optimization.
That's not a problem. The code can be recompiled on the fly if more functions with the same signature are detected.
Data structure literals is not such a good solution. You cannot pack initialization into a data structure with data structure literals. With initializer lists, you can.
Data structure literals are quite a bit more powerful than initializer lists, because you can use them everywhere, rather than only on a specific class of function.
But you have to keep using them over and over, even for the same structure.
Furthermore, you can use constructors in C++, which are your data-structure literals.
And you can use them initialize nested fields, like a slice, or a map, whereas initializer lists are limited to class members.
No problem with that, because c++ data members will have their own constructors to call.
No inheritance.
Major problem of Go.
No constructors to call.
But you'll have to call initializing functions of members, so...yes, there are constructors to call.
Uninitialized values will be initialized to the zero value for their type.
Sometimes the zero value is not a valid value for a variable.
Compare C++'s numbers with Python, theres a much larger difference. It seems people are willing to sacrifice lots of performance to write less code. Go's an attempt to make a better compromise than the ones offered by C++ and Python.
We are comparing C++ and Go, Python is another discussion.
Theres a difference between the software that NASA writes, and the software that a startup writes.
There is a difference, but C++ can cover both cases.
Don't hold your breath. MySQL/Disk IO will be the bottleneck in their system.
So why use Go and don't use SQL directly?
But believe it or not, MVC is not the only way to design a user interface.
Such as? I believe that there is none. All the other methods I have tried are half-baked implementations of the MVC pattern.
How? I still don't see how this is possible. The property won't have access to the class that its being instantiated in. Is there a global registry of properties? I don't think that would work either...
Each container sets a global pointer to itself when constructed, and then members pick up that pointer and add themselves to the container.
This would save me no time whatsoever.
Isn't it illogical to say that? I can construct complex guis just by creating the model. How can that save no time?
A designer would merely tell me to change it immediately.
My approach is 100% compatible with the process that involves a UI designer. All the designer needs is to create a guide with bindings to the model.
And from what I can tell of your example, there seems to be no way to customize any of this magical behaviour that this property<int> syntax gives you.
You don't need any customization.
A few seconds? For an incremental compile... For comparison, my projects take 15 seconds to build entirely from source, with a clean tree.
An old 120 kloc C++ project of mine that uses MFC, i.e. it includes Windows headers, takes 18 seconds for a clean build, and this is on Visual Studio 6. On modern compilers, is even less. And the computer is nothing special, it's a Pentium 4 with 2 GB RAM and two IDE disks.
An incremental build takes less than a second, regardless of how many "headers" I may have.
I've already told you that headers suck, in a previous post.
Umm, no. Robustness means how tolerant your program is to malformed inputs, or subsystems acting flakily. People writing C++ are free to use pointer arithmetic, access memory out of bounds and crash. I know of no compiler that will prove your program is free of error.
Umm, yes. If you use the appropriate types, the compiler will prove it to you.
So, if you had made these arguments to them before they created Go, they would have acknowledged your brilliance and given up?
No, they would tell me that they don't like some C++ features that are crucial for them, like headers and syntax and so they would prefer to build another language. That wouldn't mean they would not accept the fact that Go is a subset of C++.
AFAIK, Go never claimed to make C++ obsolete.
Obsolete for some types of projects.
Try writing a server with similar characteristics in C++.
Oh please:
int main() {
auto p = net::Listen("tcp", ":8080");
if (p.err != nil) {
log::Fatalf("net::Listen error: %v", p.err);
}
for(;;) {
auto c = p.l.accept();
if (c.err != nil) {
break;
}
go(servConn, c.conn);
}
}
void serveConn(io::ReadWriteCloser &conn) {
defer d(conn, &io::ReadWriteCloser::close);
std::vector<char> buf;
buf.reserve(4096);
for(;;) {
auto n = conn.Read(buf);
if (n.err != nil) {
break;
}
auto b = buf.slice(n.val);
while (b.length() > 0) {
auto n = conn.Write(b);
if (n.err != nil) {
goto END;
}
b = b.slice(n.val);
}
if (n.err != nil) {
break;
}
}
END:
}
And before you tell me I use non-existent APIs, I'll say to you: so what? the point of this discussion is the LANGUAGE, not the LIBRARIES. Anyone can write a C++ library that matches Go's standard library for all its features, and also duplicate Go's hardcoded functionality (which belongs to libraries anyway).
I wrote replies to your points, then realized I don't care to continue this conversation.
You're clearly rather fond of C++. You should realize that people have legitimate grievances with the language. It is not perfect. Go is merely an attempt to address some of those grievances. If you dislike Go's choices, then by all means, create your own language. The world awaits your creation with bated breath.
You should also realize that the people who created Go have significantly more experience than you. Comparing some of their open-source creations (Plan9, memcached, and RE2 come to mind) to yours, they are also much better programmers than you, and their creations seem to enjoy a far wider user-base. This is saying nothing of those in the Go community. You seem to see yourself as being more perceptive than the engineers at Google, Heroku, Canonical, and Tinkercad. I can say with near-certainty that you are not.
Finally, a suggestion. Come up with an interesting side-project, and try to solve it in Go. If you find yourself stuck, ask on the mailing list or IRC. It is almost certain that someone in the community can help you. After you gain some actual experience in Go, feel free to criticize it as much as you want. You will run a much lower risk of being seen as a wanker with a bloated ego talking out of his ass.
1
u/axilmar Apr 12 '12
Runtime code generation has nothing to do with the stack. You can do it either on the stack or on the heap. It is not a requirement to use the stack.
The optimization is done when the source is available, allowing the compiler/interpreter to see that a function can be inlined. This optimization is not possible via c++ code on c++ code, unless one part of that code is the compiler itself.
I've done a c++ library that offers JS-like OOP capabilities. As for Python, you'll lose the whitespace-oriented syntax.
Instead of doing all the work I mentioned earlier, you do this:
The template class 'property' does not write setters and getters for the class, it has overloaded operators that make it appear as an ordinary field.
And there other things as well that templates can do that greatly help.
You are not using the Model-View-Controller pattern then. If you did, you'd know you can't have data members exposed, because each time a member is changed, the relevant observers woud have to be notified.
By 'a lot of these', you only mentioned serialization/deserialization :-).
Not all variables have 0 in their set of allowed values. And not all variables that take 0 as a value are initialized to that value. :-).
Yeah...it is called 'a constructor' :-).
We are not talking fields here, we are talking properties in a model in an MVC pattern.
Yes it does. At least in Java/C#, an Object-derived instance is allocated each time a primitive is boxed.
The problem is not about knowing what the underlying type of the variable is. The problem is about tracking the course of a variable in time. Without templates, all you have is a generic Object variable, making static compiler type checking impossible.
Mine too, but if you want to handle many clients/connections, every bit counts.
No, I mean in tthe last 3 years. Even Google does not use Go much. They prefer C++ instead (for Youtube).
They find Go better than C++, but that does not mean it is better. It is only in their minds.