811–820 of 869 posts
Earlier quoted context omitted.
Yes. So what?
Then it is not a replacement for C++. It's going to be slow.
Earlier quoted context omitted.
Julia is solving many of the same problems as C++. GPU compute, HPC, high performance algebra kernels are all well within Julia's purview. It's not (at least yet) good for things like writing OS kernels but there is a large amount of overlap with C++.
While being written in C++, so it can't make C++ go away in those domains.
Earlier quoted context omitted.
While being written in C++, so it can't make C++ go away in those domains.
llvm is c++ but almost all of Julia is written in Julia. codegen and the subtyping algorithm are the two main things written in C/C++.
Earlier quoted context omitted.
Yes, the embedded space pays terrible, and the employers don't seem great on the whole. When I was at Google I got to work on embedded stuff and really liked it; but I was getting a Google salary. When I left Google I pursued IoT and embedded jobs a bit and while I was not expecting Google level compensation at all, I was astounded at what was going on there, pay wise. General software eng back end jobs pay better. T…
> Yes, the embedded space pays terrible, and the employers don't seem great on the whole. in europe c++ pay is in general ridiculously bad, I got some job ads this morning. Senior job in real-time trading in C++ in Paris, multithreading and linux knowledge, english first: 55-75k. Embedded senior C++ FPGA engineer in paris: 45k-65k. No bonus in either position. thanks but no thanks
Earlier quoted context omitted.
> And what can be used instead of C++? For most use cases Java is a better option. Very fast, without any of the pain. If you truly must not have a VM (rare), there's still C. Perhaps rust.
Java is not very fast compared to c++, or you'd see it in embedded systems all over.
Those are quite different domains, with only minimal overlap.
Embedded systems more often that not are not seeking maximum performance. What matters is smaller code size and running on mimimal hardware. Java doesn't do so well there since you have the overhead of the VM. Java is rarely a sensible choice for embedded code. Just use simple C, or rust if it works for the use case.
(Yes I know project green was originally about embedded set-top boxes! But times changed.)
Performance critical systems are usually large servers for either high througput (web or other server traffic) or low latency (HFT) applications. The opposite end of the spectrum from embedded. That's where Java shines. You might be able to beat Java with carefully hand-tuned C++ but just as likely the JIT might beat you. So for maximum performance server code combined with a more sane developer productivity, Java cannot be beat.
Earlier quoted context omitted.
I think this is probably the most salient point. C/Rust then Java. I don't know why people hate on Java so much. And I think C lives fine along side Rust.
Java forces OOP and it's verbosity is worse than COBOL.
Java doesn't force OOP in any meaningful way. I mean it does, in that you need to wrap all code in a class, but that's a non-issue (one line of code at the top and a closing bracket). You can write Java code where all functions are static and do nothing is object-oriented, when that's the best match for your needs.
On verbosity, you can latch on to the ConstructorAccessorMapFieldGetterFactorySingleton nonsense if you want but that's on you. Nothing in the Java language forces that on anyone. Having been writing Java code since 1996 I've never written such code.
Earlier quoted context omitted.
But sheiks and oligarchs are buying all the real estate, so the cost of living is pretty similar.
if you live in the fucking shard, maybe. london is expensive but let's not exaggerate: a £150k earner is not worried about the cost of living.
Earlier quoted context omitted.
As someone who has been writing C++ at Google, this exactly. Despite all the tooling, guidelines and "internal magic", C++ is still an abomination. And no it has nothing to do with memory management, I actually do like C. I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific…
> C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason) Too bold statement. There are still lots of reasons to keep using C++. LOTS.
Earlier quoted context omitted.
I've been there? It's very doable and far easier than understanding C++ in my opinion.
> Mid-six digits Do you mean $500k? On levels.fyi for San Francisco you're talking about the 95% percentile of people who upload their salaries (which tends to the higher range anyway), and that's mostly stocks. So in the highest paying part of North America, at the highest paying companies where employees put their salaries on levels.fyi, a small minority can reach $500k. North America as a whole? Nope.
Look, I don't really care about money after a certain point. So I'm not trying to encourage people to do stuff for money. What I'm trying to say is that there is a world of software development renumeration that is achievable if you keep developing skill and it is far less challenging than dealing with a C++ codebase.
Earlier quoted context omitted.
It’s even worse if you don’t size the burner to the pan. My wife always uses the largest burner with an 8 inch pan, probably 70% of the heat goes around and over it. Really made me want to switch to induction but I noticed the same thing that most induction cooktops have stupid, unreliable touch controls.
I think efficiency of a hob is pretty low on the priority list right? Certainly when framed in cost terms (gas being cheaper than electric). The total amounts are too small relative to hot water / home heating to make much difference. Especially if you go out of your way to find an induction cooker with a decent interface (there is at least one out there with knobs). For most things which would need cooked on a hob f…
At an optimistic 40% efficiency for a stovetop vs 90% for an induction cooktop the breakeven is 25c/kWh which is well above average US electricity prices. Worse that 40% assumes properly sized cookware in contact with the burner, no pilot light, and ignores the cost of venting air outside.
As to total costs, at full blast a propane burner only costs around 1$/hour but some people do a lot of cooking.