Originally posted by msotirov
View Post
Announcement
Collapse
No announcement yet.
C++20 Making Progress On Modules, Memory Model Updates
Collapse
X
-
- Likes 1
-
cl333r - Go is not interpreted, it does AoT compilation just like C++. It just has a built in garbage collector - maybe that's what confused you?
You said you did ten years of java development. When? And what were you using it for? Yes, it starts slower than C++ and it uses a few hundred MB of RAM at startup. If you're running a server application for hours at a time, that doesn't matter. If you're writing CLI tools, or applications for a Raspberry Pi, it does matter.
Originally posted by bug77 View Post
Go is not JITted. Java is also working on adding AoT compilation (through GraalVM, I think). Even in its current form, Java usually starts in server mode and does most of the JITting upfront.
So if you need relatively small self-contained binaries, less memory overhead at startup (but not necessarily less memory overhead if you run the application for a few minutes), or startup just 2-3ms slower than C++ for something like a fast-launching desktop application or a CLI tool, then GraalVM is the way to go. The binaries, at least on my machine, start at 7MB and go up in size from there. But again, you can run them on any x86_64 Linux machine and it doesn't use any existing JVM. The AoT compilation process is also very slow.
If you care more about total throughput and can live with the 80 ms JVM startup overhead on my five year old desktop (less on newer, faster hardware) and the slower performance for the first few seconds while the JIT starts, then regular Java is the way to go.
Comment
-
Michael_S Yeah, I said it's _working on_ adding AoT, I know it's not there just yet. I don't think it even works on enough architectures just yet, but I could be wrong about that, I don't monitor it closely.
If I want to squeeze a little more performance, Go would be my go to solution (see what I did there?). Cross-compiling Go is as simple as can be. But like you pointed out, the go to solution can vary based on specifics of you need done.
Comment
-
Originally posted by bug77 View PostIf I want to squeeze a little more performance, Go would be my go to solution (see what I did there?). Cross-compiling Go is as simple as can be. But like you pointed out, the go to solution can vary based on specifics of you need done.
I need to add a slightly modified version of a feature to our product without changing the existing feature. If I rewrite the existing feature to use composition, we have to do thorough testing of the existing feature to make sure I didn't break anything. That testing is on top of the testing of my new feature. If I just subclass the existing feature code in key places and override the behavior I want, existing behavior is guaranteed not to change. Then we only need to test my new feature. Less work!
And that approach is working as designed in tiny, tightly-constrained cases. But for a lot of large Java applications I've looked through, at jobs and for open source projects, there are three or four levels of inheritance all over from this design, and you have to look up and down two or three (or four or five) inheritance hierarchies to track what is happening. It becomes a hideous mess, difficult to understand, difficult to debug, difficult to refactor.
So the Go language designers saved us from ourselves, really.
Now, you might be thinking, "I'm too smart to ever make that design mistake, so the Go designers just hurt my ability to get useful things done!" But that's only true if you work alone on projects you control completely. On a shared project, Go still protects you from the rest of your team.
Comment
-
Originally posted by Michael_S View Post
Well, when you say "it's not there just yet" - I mean, it works today. I've been playing with it for fun. The performance may not be good enough yet, but the feature is fully implemented.
Originally posted by Michael_S View PostGo is on my to-learn list. When the language launched, I thought, "No inheritance? Composition only? Are they insane?" But since then I've decided it was brilliant. I think the problem with inheritance is that it pushes you to spaghetti code. I've seen this same pattern quite seriously hundreds of times:
I need to add a slightly modified version of a feature to our product without changing the existing feature. If I rewrite the existing feature to use composition, we have to do thorough testing of the existing feature to make sure I didn't break anything. That testing is on top of the testing of my new feature. If I just subclass the existing feature code in key places and override the behavior I want, existing behavior is guaranteed not to change. Then we only need to test my new feature. Less work!
And that approach is working as designed in tiny, tightly-constrained cases. But for a lot of large Java applications I've looked through, at jobs and for open source projects, there are three or four levels of inheritance all over from this design, and you have to look up and down two or three (or four or five) inheritance hierarchies to track what is happening. It becomes a hideous mess, difficult to understand, difficult to debug, difficult to refactor.
So the Go language designers saved us from ourselves, really.
Now, you might be thinking, "I'm too smart to ever make that design mistake, so the Go designers just hurt my ability to get useful things done!" But that's only true if you work alone on projects you control completely. On a shared project, Go still protects you from the rest of your team.
Comment
-
Originally posted by peppercats View Post
C compatibility has nothing to do with C++'s popularity. If you think ridding C++ of its C compatibility would make it just like Java/C#/Python
As Stroustrup suggested in the design of C++, a close compatibility with C is a must.
Originally posted by peppercats View Postthen you don't understand C++ at all.
Just the default, value and zero initialization rules alone trip me up. There was a great post from John Carmack (who I imagine is quite an experienced C and C++ developer by now) that suggested that he had to reset his counter on days without undefined initialization bugs back to zero.
We need more safety and less complexity. Which is why I personally find C++ 20 quite a big disappointment personally.Last edited by kpedersen; 14 November 2018, 10:23 AM.
Comment
-
Originally posted by Ananace View PostI personally don't quite agree with the hate for header files, though I would love to see a slight change in how they're used. The separation between definition and declaration is one of the things that - to me - really makes C/C++ nice to use, as I don't have to trawl through implementation code - or use a tags system / object browser, just to learn what an application or library allows me to do.
But don't worry, header files are not going anywhere, even though modules do support that use case, it is not recommended.
Comment
-
Originally posted by brrrrttttt View PostGood luck writing cross-platform code without preprocessor. What's the replacement for #if 0ing a block of code? Please don't say /* */.
-e- P.S. Replacing simple text processing with something vastly more complicated, with inferior functionality is brain dead.
Other languages do it better - they still have your #if statements but that's it, that's all you need to give yourself flexibility and configuration. For everything else, use constexpr.
Comment
-
Originally posted by bpetty View PostI would natively compile C# and call it a day. C++ is basically trying to add all of the things that C# has but without looking like they are copying. Might as well go straight to the source.
- Likes 2
Comment
Comment