Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

261–270 of 395 posts

Re: Modern C++ Won't Save Us

#261

Post by koffiezet »

ncmncm wrote: post #117
_bxg1 wrote: post #75

Earlier quoted context omitted.

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language , it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I…

That doesn't make C++ a good language. It just is one. Rust is also a good language. Trash-talking C++ does no one any good. Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful librarie…

I started came from a C background (mostly for embedded stuff, where on many platforms a C++ compiler wasn't an option) - and eventually moving to C++ for backend and library work was a pain in the ass. I got the hang of it, but never loved it, although for the goals we had to achieve, it was a sensible choice. I however moved into more of an ops/SRE role mainly due to to C++ not entirely being my thing while the dev that was always most in touch with the ops side of thing.

I do see many of the advantages of both Rust and C++, but one of the reasons I like C is its relative simplicity. I only did a single small thing in Rust to try it out, and while still quite complex, at least it felt more manageable than C++ once you understood the borrow checker. The big elephant in the room however is Go. Every time I started something and would consider Rust, it ended up being 'why not just Go?'.

At least for me, it was much better suited language to be moving to coming from a C background. The biggest initial hurdle was setting up the dev environment with the completely backward GOPATH and GODIR environment variables - which just feels absolutely wrong (although this now in the process of being addressed). The language itself however was an absolute breeze, I felt right at home. Simple, quick, straight-forward, with tons of libraries and tools for my current field of work, coupled with performance more than acceptable for 99% of the applications I need and static binaries which are easily deployed anywhere, also eliminating a ton of complexity. Is it perfect? No, but what language is? But if you want to convince C-programmers to ditch C for a memory-safe language - Go is imho in many cases a much better option to move to.

Re: Modern C++ Won't Save Us

#262

Post by w0utert »

ayosec wrote: post #219
noselasd wrote: post #212

Earlier quoted context omitted.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

How is that different to this? if (my_pointer != NULL) do_stuff(*my_pointer)

In terms of generated coded, it is exactly the same. But that's not the point of optional types.

The point of optional types is to force you to write checks for undefined values, otherwise your code will not compile at all. In the old-fashioned style of your example, you might forget to check for the possibility of a null pointer/otherwise undefined value, and use it as if it were valid.

Re: Modern C++ Won't Save Us

#263

Post by nicoburns »

ncmncm wrote: post #125
nradov wrote: post #108

Earlier quoted context omitted.

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

> Rust is still a niche language

Only just barely at this point. It has significant projects from a lot of the largest companies (Google, Microsoft, Amazon, etc). Firefox is using it, Dropbox is using it, Red Hat is using it.

Re: Modern C++ Won't Save Us

#265

Post by Althorion »

colanderman wrote: post #95
jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database…

> include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics

Can you, from the top of your head, tell me what irregular modified cylindrical Bessel functions are and the last time you needed to use one? And yet, they were included in the standard library in C++17: https://en.cppreference.com/w/cpp/numeric/special_math/cyl_b...

Re: Modern C++ Won't Save Us

#266

Post by humanrebar »

ayosec wrote: post #219
noselasd wrote: post #212

Earlier quoted context omitted.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

How is that different to this? if (my_pointer != NULL) do_stuff(*my_pointer)

Native pointers do a bunch of different things depending on the context. In contrast, optional has clear semantics.

For instance, the ++ operator doesn't work for std::optional. For a native pointer, you just have to know (how?) not to use it.

Re: Modern C++ Won't Save Us

#267

Post by machinecoffee »

ncmncm wrote: post #125
nradov wrote: post #108

Earlier quoted context omitted.

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

From what I can see, the whole point of C++ is to wrap existing C libraries and call them OO :-)

Re: Modern C++ Won't Save Us

#268

Post by humanrebar »

coldtea wrote: post #223
geezerjay wrote: post #146

Earlier quoted context omitted.

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…

> I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. It's not obvious to me at all. In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".

Third party modules would be a huge mess if there weren't at least common interface types like std::string_view and std::unique_ptr.

Re: Modern C++ Won't Save Us

#269

Post by humanrebar »

hak8or wrote: post #91
jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

Can you or others post such alternative standard libraries? The only ones that come to mind are boost (which is a nightmarefor compile times and I feel is a mishmash of old and new) and googles absiel which I haven't actually tried enough to make an opinion about.

ACE was an attempt that is basically dead.

There was some talk about an std2, but I gather support for it is too low to be pursued seriously.

Re: Modern C++ Won't Save Us

#270

Post by fetbaffe »

UsernameUsernam wrote: post #258
fetbaffe wrote: post #209

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++. Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages. The developer starts a new project, but in what language? web: Don't see any reason for this. Exist lots of great alternatives.…

Language VM: HotSpot, ART, V8, SpiderMonkey, Chakra, JSC, Dart, and CLR are all written in C++. Are there any modern serious language VMs that aren't written in C++?

Lua, LuaJIT, PHP, Python, PyPy, Erlang
Post reply on HN