Hacker News Reader

Comment by fsloth | Hacker News Reader

"C++ in 2018? SURE (You masochist)"

I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

View on HN

C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices.

Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly.

But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision.

Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well.

Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.

I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects).

Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).

No one said that one needs to use LINQ with C# all the time.

Likewise no one is using C++ with MI and 9 level deep hierarchies for game engines anymore.

C++ is one of my toolbox languages, which I know since C++ARM days, yet I am also open minded that it shouldn't be the only way.

I am old enough to remember when C, Modula-2, Basic and Turbo Pascal, AMOS were the "Unity" of MS-DOS/Amiga, because for this kind of tasks there's nothing better than Assembly and everyone had a copy of Zen of Assembly Language.

Then the speech was updated to there's nothing better than C when compilers improved, and it took PS 2 with its C++ SDK to eventually force game devs to grudgingly accept C++.

Which now reigns on all things GPGPU, but it doesn't mean we should be happy with just one language.

And even though it is one of my favorite ones, I dislike the lack of modules (maybe C++23 with luck) and the copy-paste compatibility with C that endangers the software I use written with it, because on many teams static analyzers and guidelines are foreign words.

"things like Linq"

It's really easy to accidentally create a simple Linq query that underneath turns into O(N^2) and suddenly the production application crawls to a halt. Actually happened.

That's why you should know where to write code optimized for perfomance and where to write code optimized for readability.

It's the latter 95% of the time.

"It's the latter 95% of the time."

Still, that's no excuse to write readable code that for example runs in O(N^2) when there would be just as readable O(N) alternatives.

This is a true statement, which very rarely applies to actual Linq usage.

Well Unity engine itself is written in C++.

True, hence the HPC# effort to make it possible to port some C++ subsystems into a C# subset.

The effort is lead by two well known figures in the game scene.

https://blogs.unity3d.com/2017/11/08/were-joining-unity-to-h...

Specially relevant because their opinions regarding C, C++ and high performance game code are also well known.

There is a growing Rust game development community [0] but of course C++ still has the edge.

[0] https://www.reddit.com/r/rust_gamedev/

I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.

It's getting better. I've been starting to dig into Crow to see if it might be a worthwhile option as a C++ web app framework:

https://github.com/ipkn/crow

https://github.com/jolks/crow-template

(Relies on libboost https://www.boost.org/)

Seriously, it makes putting together a simple API a breeze. I haven't had the chance to try anything more complex yet.

People who don't know say these things. Try writing web applications in C/C++, it's a deluxe development situation. Where do you think web browsers come from? Everyone afraid of C/C++ are shooting themselves in the feet.

When I started to learn Rails, the intro was a Twitter-like messaging app. Somebody that knows what they are doing could turn that out in an hour.

Is the situation in C++ frameworks very far off?

The same. Using Restbed, a C++ embedded web server framework, a twitter messaging app is about an hour of work.

I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...

What C++ web server library/framework do you use? Or did you roll your own? For the database, are you using SQLite or something else?

Restbed is the C++ framework, and yes, we use SQlite.

I'm doing the same thing, and I've got a couple questions:

How do you handle redundancy, e.g. if your Intel Compute Stick goes offline for any reason? How do you handle crashes of your applications?

Is this for an art installation or does it have a more business-oriented purpose?

Government contracts; software is used by covert agencies.

Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.

> I'm not aware of any good alternatives.

Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†.

† depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.

"Vulkan/C? Metal/ObjC†/C? "

Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon.

If one deploys only to OS X/IOS, Metal and ObjC, sure.

"From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†."

With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including:

https://vulkan-tutorial.com/ https://learnopengl.com/

[0] http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html

For Rust, there's [1] for OpenGL and [2] for Vulkan.

I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API.

[1] https://github.com/glium/glium

[2] https://github.com/vulkano-rs/vulkano

The sentence in the top of the readme for the github repo is: "Glium is no longer actively developed by its original author."

Which links to: https://users.rust-lang.org/t/glium-post-mortem/7063

Which pretty much states that Glium is not a really long term viable solution at the moment.

I've toyed with cool open source libraries for 20 years. I'm too old to get caught up with something new and shiny only to find out it wasn't structurally sound.

That is why C++ is a good choice. It has huge traction. The ecosystem is basically bullet proof. It has lot of practical libraries that are so well used that while not bullet proof themselves, it is likely they will stay alive as long as you need to compile your code.

Immediately after that, it says: "That said, PRs are still welcome and maintenance is continued by the surrounding community."

> Which pretty much states that Glium is not a really long term viable solution at the moment.

Except what that post-mortem is _really_ saying is that OpenGL is not a long-term viable solution. The whole post-mortem is about the fact that OpenGL drivers are so buggy that you can't write portable code to target it.

"OpenGL drivers are so buggy that you can't write portable code to target it."

Sure, that's why generic non-platform specific OpenGL wrapper is a bad idea, unless you have an army of engineers to apply kludges and workarounds. I'm sorry the author had to find out this the hardest way. The quality of OpenGL drivers has always been like this.

One way of writing portable OpenGL is to look at what some popular game with open source is doing, and copy their approach, because the likelihood of a) the bugs that title triggered are mostly fixed and/or b) they managed to avoid the biggest potholes.

E.g. look at what Quake or Doom III does, etc.

For the several dozen EA games I worked on, in C++, all operator overloading was banned. Too many fools play dumb tricks with operator overloading, so it was declared illegal. I don't miss it, as it is a fool's tool.

There is a better word for this.. People who use operator overloading are a bunch of shmucks (Stupid fools), as my Jewish grandfather would say :)

EA should try banning fools instead . There are many other tools that have to be used appropriately, especially in C++.

Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...)

https://inductive.no/jai/

Any language with a FFI (i.e. ~all of them) can be used to interface with DLL:s with a C interface. That was really not the point...

Depending on what libraries you need, Nim and D seem like decent alternatives.

"Nim ... seem like decent alternatives."

Note that I specified real time graphics development as the focus area here for C++. While I don't want to get into platform wars, on that front Windows is a really strong contender, for various ecological reasons.

Nim does not seem to be well supported on windows [0]. The typical cyphers for poor windows support in open source projects, that seem to hold true for Nim, are that:

a) No mention of MSVC support as a compiler option b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves. c) Need to manually configure various paths

While these are not a technical blocks, they imply strongly that Windows support is not one of the key priorities for the project. "Here you go, have a nice language - and oops, good luck debugging our runtime". Whereas in industrial quality setups that have lot of users you can pretty much expect it to work out of the box.

[0] https://nim-lang.org/install_windows.html

Wow. We really need to fix our install page if people are reaching this conclusion.

Hey, Nim dev here. I can assure you that Windows is incredibly well supported by Nim.

> a) No mention of MSVC support as a compiler option

https://nim-lang.org/faq.html#how-do-i-use-a-different-c-com...

> b) Installer does not install the complete required language runtime, and the end user must hunt the missing DLL:s by themselves.

The DLLs are all included in the .zip file. Even if they weren't, you do not need to "hunt" them, there is a link for them at the bottom of the download page.

> Need to manually configure various paths

You don't. It's easy to think that when you only read the headings though :(

Here is an excerpt from under the heading:

> The zip file includes a simple application called finish.exe that can attempt to add the first directory into your PATH. This tool also checks for the presence of a C compiler and can install MingW, the GNU C compiler collection for Windows.

The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA). Despite this, you won't find many languages with Windows support that is as good as Nim's.

Hey! Cool to read you response.

My initial comment may have been a bit uncharitable, and I'm sorry - I chose clear communication instead of overt politeness. I might not resemble the core audience of the language in any way :)

I based my response to the first page mentioning windows install:

https://nim-lang.org/install_windows.html

This is the first page I end up from both https://nim-lang.org and Google.

My instinctive response was based on a pattern matching from trying to run various open source projects on Windows the past 20 years, and how the projects choose to communicate their install narrative. I.e. the "ciphers" I mentioned in my posting above.

Rust needs additional compiler as well, this is how they communicate it: https://www.rust-lang.org/en-US/install.html

"The installation isn't perfect, we did have an installer in the past but it proved more trouble than it was worth (NSIS is very archaic and INNO is a PITA)."

WIX toolset may be an option http://wixtoolset.org. Not having a Windows installer generally appears amateurish nowadays (I know a plain zip is just as good but that's what people do and is generally expected nowadays).

Even Latex which was an incredible mish-mash of various components you needed to... acquire, is now available through just clicking the installer: https://www.latex-tutorial.com/installation/

"...Despite this, you won't find many languages with Windows support that is as good as Nim's."

You could mention msvc in the initial install page since you need it. There was a specific time when projects had good economic and technical reasons not to depend on Visual Studio on windows. Not so much anymore, since it's free for individuals.

Installer landing pages for languages which don't signal my "fragile-not-well-supported" sense:

https://golang.org/dl/

https://www.python.org/downloads/windows/

https://www.erlang.org/downloads

https://www.haskell.org/platform/windows.html

The Ocaml Install page is on the edge, but, that is compensated by a pedigree of being well known and having credible industrial users (i.e. Jane street):

https://ocaml.org/docs/install.html

I know you are a small team and have other priorities than your web page... the installer and mentioning MSVC on the install page would go a long way in increasing the likelihood of at least trying the project for random people running Windows.

Thank you! I'll take your feedback on board :)

There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3.

The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?

If you're using a small subset why on earth is it the right language? I had the misfortune to try to mentor a new quant who felt they had to write C++ "for speed" . But refused to use the STL as they were going to use a subset. So they wrote Fortran-like C++, array as the only data structure, bad lookup algorithms and leaked like a sieve.

Things are in the language for a reason - if you've got the issue then you use the feature.

I hardly ever recommend C++ these days as it's not worth the slower dev time. There are a few cases where run-time really does trump everything else and it's still appropriate.

In that case the code will be templated to within an inch of its life, because that's how to write real C++.

Because with small subset you get pretty and understandable code with reasonably fast build time.

Although STL implementations are getting closer today (regarding underlying speed), unless you plan to lock to particular implementation, even version, you'd better use subset ;)

Are you a quant? What do you use instead of C++? Python/cython? I’m not convinced C++11/17/20 cannot be used in quant but I am not in the business (i’d Love to though).

Let's just be honest: today's dev's can't write in C/C++ because they don't have the formal training. They are primarily script language devs who can't work at the low level required by C/C++. The formally educated programmers who were taught low level large-scale systems programming are too few to create the programmer farms you all work it (which I left for scientific software development, where the devs are older and we all work in C/C++ or assembly.)

You don't need formal education to understand why some things are the way they are in C++, you need to understand how a CPU works. A small amount of assembly programming is sufficient for that - it is actually very simple to understand, just hard to write nontrivial programs...

I'm very interested in leaving the dev farms for something more interesting. I'm taking steps in that direction, but do you have any advice on how you escaped into scientific software dev?

Not OP, but worked in science before. What you want is not to work in science on software dev ;) Scientists usually write extremely ugly, messy code, just to make it working and finalize paper for publishing. Remember, their focus is paper not code nor properly workable program.

Things like testing, agile, tickets, code indentation, patterns - none of that you'll find there.

If you aim for serious environments like Wolfram Research or MathWorks, that could be different. If you aim for quantitative firms, usually you'll find there scientists writing prototype in mathematica/matlab/r/python (messy again) and devs who will re-write it in c/c++/java/asm.

Thanks for the suggestions! I hadn't thought about places like Wolfram Research or MathWorks. I'll keep my eye on those. I'm working on picking up more C++ since that seems to be what everything I'm interested in is using.

Keep in mind these are "conservative developers" - they work in C/C++ - meaning a preference towards C styled C++, a preference towards maintainability, and a preference away from the latest features of C++. That is being a developer, yet in a tech shop. There are lucrative alternatives too:

When one looks outside the traditional technology industries, there are a huge number of technology jobs as the tech person in a non-tech industry, being forced into the tech world. These tend to be C-Suite level jobs, so picking up an e-MBA is also be pretty good idea - to know how to talk and operate in their terms, how and why what you're doing for them is what you're paid to do. They have no idea, and very likely a history of being burned by low level tech consultants.

Thanks for the info. I'm kind of burned out on the shiny new things, so C and maintainability sound like a breath of fresh air. I think reading an OS paper from ~1983 that described what is effectively Kubernetes (with working prototype written in ML) really drove home how little the fundamentals of our industry change.

The way I describe my career goals now is: I want to work in a domain where quality and performance is the product.

I hadn't considered getting an MBA and using it in that way, that's something that I will take a hard look at. Thanks for the advice!

Great point. I used to use C++ a lot on Nintendo video games, government contracting, etc. I always used a subset. Three of my favorite current languages are Haskell, Common Lisp, Scala - and I use small subsets of those languages also. I think it makes sense to look at complex languages filtered by what your needs are and decide on a set of features you really need. For me, this makes my code easier for me to read and modify in the future.

It's widely noted that this "select what you want out of the language" works best if you're working by yourself or in a very small team, with no inclusion of third-party code, or no such code that doesn't conform to your restrictions.

It really is best if the language doesn't include the kitchen sink in the first place, if you want the code to be clean in the most general circumstances.

WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.

I suppose WebGL is okay for shader prototyping, for example using Shadertoy [0]. However, you can use it only within the context of a browser framework. That is still not the optimum deployment nor development platform for a variety of scenarios.

The original joke though, was that C++ was for masochists. I'm not sure developing a web application is any less painfull...

[0] https://www.shadertoy.com/

I used to think like that specially given how poorly many demos run on mobile devices that don't have any issues dealing with ES 3.x games.

However the demos one gets to see from production work at Siggraph are quite impressive when running on proper desktop cards.

Reply on news.ycombinator.com