I am using C++ for sioyek which is a PDF reader designed for reading research papers and textbooks: https://sioyek.info/
Other libraries used:
* MuPDF for PDF rendering
* Qt5 for UI
* sqlite for database
I also recently added a plugin system which is language neutral, but I wrote a python wrapper around it (see and example here: https://sioyek.info/#extensible).
This is the exact kind of tool I would have loved to have had during my math undergrad. And as a fellow developer, I applaud you for taking on the challenge of working with PDFs, especially in non-trivial ways, on arbitrary PDFs no-less. Anytime a client/employer mentions anything involving programmatic PDF manipulation/access, I try my best to convince them it's probably not a good idea, but if I have to, I do a little prayer that I can find a straightforward solution with an existing library - otherwise, lower level PDF munging quickly ventures into a flavor of tech-cowboy hell.
I almost exclusively use C++ for my projects. Especially modern C++. When it makes sense(especially for dev tools), I use Python since for those I'm not so worried about distribution and long-term robustness.
WebApp I JUST started working on(This will be a frontend for a YOCTO/FPGA project I'm working on; guitar pedals), and yes it uses good old C++ and runs on the browser:
C++ is still often the best or only way to write performant code on embedded platforms, while having a rich library ecosystem available. Hence, my first choice for a new embedded project is almost always C++.
I would love to be able to use something like Rust, but the RTOS options and library support are not quite there yet.
With more powerful embedded processors becoming available, Micropython is an option for some projects.
Came here to write pretty much exactly what you said.
I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun.
But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature.
Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.
You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it.
Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity).
Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper
The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.
Real question: You specifically wrote <<C++ is still often the best or only way to write performant code on embedded platforms>>. To be clear, I am not an embedded systems programmer (nor an HN troll!): Does C also qualify? I heard that sometimes embedded engineers are forced to choose C where the C++ compiler is poor or does not exist. Can you please also share your platform(s) and compiler(s)? I am curious to learn more from an industry insider!
Context: I write rust professionally I have no plan of coming back to cpp.
Cpp still has the (huge) advantage of maturity. Rust is great but still half-backed. Things like thread-local-storage, custom allocators and async are either unstable or incredibly rough around the edges.
Finally, my experience has been that third-party libraries in cpp are fewer but of greater quality than the ones in rust. There are many many libraries available in rust due to the amazing dependency system. But the average quality is quite poor.
In cpp you tend to be conservative when adding dependencies which means you have a much better understanding of the code you run. Or, you write your own code that’s usually custom made for your purpose, which generally end up as being more performant.
> There are many many libraries available in rust due to the amazing dependency system. But the average quality is quite poor.
The main problem with Rust is that it is thread safe, and that makes code and libraries very hard to write. Thread safety is a lot stricter than memory safety, and since it is easy to write single threaded memory safe modern C++ it gets hard to shift to Rust.
But if you want thread safety or mostly do data processing scripts then Rust is far superior, just that for many applications enforced thread safety is an anti feature since it makes your code way too hard to work with. If they could make ergonomic thread safe libraries for everything then great, but I really doubt it will ever happen as it is very hard to do.
I've started using C++ for the REST backend for a mobile app recently.
I'm using restinio for the REST layer (sadly deprecated a couple of months ago, but it still seemed like the best option in terms of clean interface) and sqlite for the DB layer.
I've architected it all so I have a purely insert-only and order-independent DB on the write-side, so litestream was seeming like a good fit for single-writer, multiple readers, but now that's been abandoned, I'll wait until litefs stabilises, or roll my own to do what I need.
I originally started the REST side in dart so I could share code with the flutter client app, but I soon realised that performance wasn't where I wanted it to be and that the backend queries were all very different to client side anyway, so it seemed easier just to create the REST side in C++. I should add that my normal work has been predominantly C++ for many years so it's more familiar to me than learning something else and also being able to hit the sqlite layer directly without another abstraction layer seems beneficial.
I was planning to use litestream to distribute the sqlite DB to multiple readers, but now that's deprecated, I'll probably look into doing my own in C++ later on if his new focus on litefs doesn't work out for me.
This year I wrote the latest compiler for jank[1] to be in C++. Originally, this new version was being written in Rust, which I prefer, but I ran into a serious limitation. In the C++ world, we have Cling[2], so I can easily JIT compile arbitrary C++ code and link it to my running process. This is exactly what I need for jank's REPL and JIT capabilities. In the Rust world, such a thing doesn't exist and trying to use rustc as a crate is not well supported at all, all on top of the ABI instability issues.
I model most the C++ code around Rust's semantics for things like option<T> and result<T, E>. Currently working on replacing my boost::intrusive_ptr usage with an equivalent which is non-nullable, to be combined with option<T>. Even with value semantics, RAII, and hefty TMP for type-rich APIs, C++ still bites in many ways. It's still so easy to have UB compile, including anything from iterator slip ups to interdependent static globals in different TUs with undefined ctor/dtor orders.
I'm using C++ for most of my projects, because I like it. It's also what I do for a living. The latest new open source project I initiated is a dns server, nsblast, using rocksdb for storage. https://github.com/jgaa/nsblast
The (side) project I have put most effort into in the last year is k8deployer, a helm like utility that can deploy simple and complex applications in kubernetes with minimal effort. https://github.com/jgaa/k8deployer
In these projects I don't use other languages. C++ is the only language where I easily get into "flow".
Just about any project you do in Unreal is a C++ project and Unreal is used all over the place - in games but also in industrial design and architecture for demos and visualization.
I started a project (https://github.com/tedmiddleton/mainframe) last year to make a dataframe in C++ because I was running into some performance limits in Pandas. I’m not sure how useful a C++ dataframe is - but I imagine it as being an alternative to going all the way to Hadoop and spark if you’ve outgrown pandas.
All our infrastructure technology, services, and almost all “applications” we have built are written in C++. That’s millions of lines of code and span everything from IR, distributed storage and computation, ads serving, relational and columnar datastores, caching and much more.
It’s about velocity and experience. Language rarely matters ( and when it does, you can use what’s appropriate ). For us, C++ checks all the boxes.
Above, you wrote <<velocity>>. Most people would say that C++ has lower velocity than other higher order languages, like C#, Java, Python, Ruby, etc. You also include the term <<experience>> which is a curious combination. In my professional experience, language "experience" dominates most discussions about what langauge to use for a new project. After all, programmers are humans who have biases from their (programming) langauge experience. (Zero trolling on the last sentence!)
Starting a new side project, no platform-specific functionality needed. Tried out a few relatively "new" languages (more like new to me) and experienced severe frustration from bugs and spotty documentation, lack of proper IDE/debugger support.
So, I figured, better the devil you know. And of course: choice of compilers, choice of FOSS libraries, my own libraries and workarounds to various well-known annoyances and, well, debuggers!
I'm using C++ for a minecraft clone that I've been tinkering on for the past year[0]. I also plan on using embedded lua for scripting, and I'm using RML UI for game HUDs, ImGui for development tools, and OpenGL for graphics. I use premake for my build system but plan on switching to CMake.
I'm also using it for an animation tool[1]. I've been using 3Blue1Brown's Manim (written in Python) which is amazing, but it lacks real-time editing and proper 3D blending. It also lacks audio synchronization, 3D texture support, and some more complex features that I'd like to add :)
Yeah, it's one of my two main languages for new projects.
I mostly write system tools and cloud-focused tools. For the former I use C++, for the latter it's Go.
The portability of C++ just can't be beat. At worst you have to restrict yourself to a certain earlier C++ version (e.g. C++14), but the pure "access" you get to the system is unbeatable.
E.g. you need to call exactly these low level functions in exactly this order? C or C++ is all there is.
And manual memory management is a terrible way to live your life, so C++ it is. (the modern kind, the one where you never write `new` or `delete`, basically ever)
Go seems like it tries to be a systems language, but it's failing at it. The portability is just fundamentally misdesigned. +build comments based on OS name are a known antipattern, and just are neither backwards nor forwards compatible.
Even the stdlib has different function signatures depending on the OS, so you can't a portable use of select(2).
Go is great for tying together parts, though. Read some stuff from GCS, stuff it into PostgreSQL, publish a message on Cloud PubSub, and update a load balancer certificate. I sure wouldn't want to do that in C++ for a small tool.
I should learn Rust. I hear good things. But in order to replace Go it'd need great Cloud support, and that seems to be lacking. And to replace C++ I'd need to actually be able to build and run stuff, even on my Debian oldstable. Too many modern languages require you to upgrade your entire OS in order to get a build environment, and that's a showstopper for me in some installations.
If I can't run my tool in that older environment, then it's not solving my problem.
But maybe it's fine. Like I said, I should learn Rust.
Learn Rust. Ignore the foamers who claim Rust is a gift from the divine. Rust is a harsh mistress, however, as it really forces you think about how your program uses memory. That's the "learning curve" everyone talks about, but if you're already steeped in C/C++ and understand how to use memory in those languages, the curve isn't so bad.
I'm doing a (free) backup system (just a hobby, won't be big and professional like dropbox) for PC, Mac and Linux. This has been brewing since april, and is starting to get ready.
To me the choice was between C# or C++, but I ultimately chose C++, because while C# is much faster to code in, when there is a problem, coding directly against the OS, I have much more control in what actually happens and in what dependencies I really have.
Edit:
I also must confess that I'm enamored with the idea of having a comparatively tiny executable without any other runtime dependencies than itself and the OS.
For build system I use meson, and cross compile the Windows targets. It works from Windows XP through Windows 10. (If you have any 32-bit version of Windows, you get the "32 bit XP" version. If you have 64 bit but it's older than Vista, you also get the "32 bit version".)
I assume this is a command-line application? c++ does have a cross-platform GUI problem, unless you pay for the Qt license that is, which is itself a heavy ecosystem to master.
Scientific simulations. Meson as the build system, vcpkg as package manager.
Also using it for hobby projects like a custom shell. Modern C++ is a great language and while I'm also using other languages like Rust for hobby projects I still feel the most comfortable writing C++.
If your memories of C++ are mostly wrangling null-terminated (you hope) char** or writing impenetrable iterator types, things have gotten a lot better!
I am (new as in 3-4 years old) - a shared library compiler for a text language, CLI for easy access to compiler and a visual editor for a graph/node-based representation of the text language, used for audio programming primarily in games - built on LLVM (For the compiler) and JUCE (for the graphics).
The shared library has few dependencies outside of LLVM so that it can be as portable as possible, and the runtime hooks are all C and only depend on c stdlib so maximum portability, even to embedded systems.
Video game stuff still frequently uses C++, and also to support consoles, handhelds, quest/etc, C++ just makes sense because it's supported EVERYWHERE (though the compiler doesn't need to run everywhere, so that's more a concern for the runtime).
We're using conan which is FANTASTIC and finally a good package manager for C++, and C++17 (will upgrade to C++19 soon, but still not quite stable/widely supported enough for my taste).
In my world, this whole "C++ is no longer a viable option" meme is just not true. We all hope that Rust or what google is working on might replace C++ but when we discuss it we're talking on the order of 10+ years.
If C++ is all you know you really should diversify a bit, learn something very different, like a lisp or Haskell. You probably won't come away doing everything in that new language, but it will certainly expand your way of looking at things.
We are using c++ mainly because Qt/QML exists. I guess if a Rust gui toolkit exists that is comparable to Qt/QML (looking at you https://slint-ui.com/), then future project would have to be re-evaluated.
My plan is to use Tauri in Rust likely with just the view in TypeScript (will probably move state into Rust). No, it isn't Qt/QML and HTML/JS/CSS aren't as snappy or memory efficient, but with work they can be made reasonable and bonus is styling is endless.
[+] [-] hexomancer|3 years ago|reply
Other libraries used:
* MuPDF for PDF rendering
* Qt5 for UI
* sqlite for database
I also recently added a plugin system which is language neutral, but I wrote a python wrapper around it (see and example here: https://sioyek.info/#extensible).
[+] [-] jmt_|3 years ago|reply
[+] [-] stevesimmons|3 years ago|reply
[+] [-] windock|3 years ago|reply
[+] [-] ajoseps|3 years ago|reply
[+] [-] creativeCak3|3 years ago|reply
Anyway here they are:
Qt desktop app written in C++:https://github.com/thebigG/Tasker
Simple GPIO front-end for linux GPIO driver(could definitely use some improvement) written in C++ and uses boost:https://github.com/thebigG/simple_gpio
WebApp I JUST started working on(This will be a frontend for a YOCTO/FPGA project I'm working on; guitar pedals), and yes it uses good old C++ and runs on the browser:
https://github.com/thebigG/wPedals
And while I'm at it, might as well mention my custom plugins for Godot Game Engine(C++):https://github.com/thebigG/godot-3.x-modules
I have found that C++ is the best compromise for me between performance and elegance ifI do say so myself.
[+] [-] osrec|3 years ago|reply
How difficult is it to manage updates etc?
What are the benefits in your opinion?
[+] [-] rufius|3 years ago|reply
[+] [-] deepspace|3 years ago|reply
I would love to be able to use something like Rust, but the RTOS options and library support are not quite there yet.
With more powerful embedded processors becoming available, Micropython is an option for some projects.
[+] [-] johnboiles|3 years ago|reply
I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun.
But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature.
Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.
[+] [-] bfrog|3 years ago|reply
[+] [-] elcritch|3 years ago|reply
Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity).
Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper
The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.
[+] [-] throwaway2037|3 years ago|reply
[+] [-] HippoBaro|3 years ago|reply
Cpp still has the (huge) advantage of maturity. Rust is great but still half-backed. Things like thread-local-storage, custom allocators and async are either unstable or incredibly rough around the edges.
Finally, my experience has been that third-party libraries in cpp are fewer but of greater quality than the ones in rust. There are many many libraries available in rust due to the amazing dependency system. But the average quality is quite poor.
In cpp you tend to be conservative when adding dependencies which means you have a much better understanding of the code you run. Or, you write your own code that’s usually custom made for your purpose, which generally end up as being more performant.
[+] [-] Jensson|3 years ago|reply
The main problem with Rust is that it is thread safe, and that makes code and libraries very hard to write. Thread safety is a lot stricter than memory safety, and since it is easy to write single threaded memory safe modern C++ it gets hard to shift to Rust.
But if you want thread safety or mostly do data processing scripts then Rust is far superior, just that for many applications enforced thread safety is an anti feature since it makes your code way too hard to work with. If they could make ergonomic thread safe libraries for everything then great, but I really doubt it will ever happen as it is very hard to do.
[+] [-] ralferoo|3 years ago|reply
I'm using restinio for the REST layer (sadly deprecated a couple of months ago, but it still seemed like the best option in terms of clean interface) and sqlite for the DB layer.
I've architected it all so I have a purely insert-only and order-independent DB on the write-side, so litestream was seeming like a good fit for single-writer, multiple readers, but now that's been abandoned, I'll wait until litefs stabilises, or roll my own to do what I need.
I originally started the REST side in dart so I could share code with the flutter client app, but I soon realised that performance wasn't where I wanted it to be and that the backend queries were all very different to client side anyway, so it seemed easier just to create the REST side in C++. I should add that my normal work has been predominantly C++ for many years so it's more familiar to me than learning something else and also being able to hit the sqlite layer directly without another abstraction layer seems beneficial.
I was planning to use litestream to distribute the sqlite DB to multiple readers, but now that's deprecated, I'll probably look into doing my own in C++ later on if his new focus on litefs doesn't work out for me.
[+] [-] quintussss|3 years ago|reply
[+] [-] davydog187|3 years ago|reply
[+] [-] pier25|3 years ago|reply
[+] [-] Jeaye|3 years ago|reply
I model most the C++ code around Rust's semantics for things like option<T> and result<T, E>. Currently working on replacing my boost::intrusive_ptr usage with an equivalent which is non-nullable, to be combined with option<T>. Even with value semantics, RAII, and hefty TMP for type-rich APIs, C++ still bites in many ways. It's still so easy to have UB compile, including anything from iterator slip ups to interdependent static globals in different TUs with undefined ctor/dtor orders.
1: https://jank-lang.org/ 2: https://root.cern/cling/
[+] [-] jgaa|3 years ago|reply
The (side) project I have put most effort into in the last year is k8deployer, a helm like utility that can deploy simple and complex applications in kubernetes with minimal effort. https://github.com/jgaa/k8deployer
In these projects I don't use other languages. C++ is the only language where I easily get into "flow".
[+] [-] speps|3 years ago|reply
[+] [-] unglaublich|3 years ago|reply
[+] [-] 0xf00ff00f|3 years ago|reply
https://github.com/0xf00ff00f/windmap
Uses CMake, Qt6, CUDA and OpenGL. Here's a short video showing how it currently looks like:
https://twitter.com/0xf00ff00f/status/1557920480564334594
[+] [-] loeg|3 years ago|reply
[+] [-] tedmid|3 years ago|reply
I started a project (https://github.com/tedmiddleton/mainframe) last year to make a dataframe in C++ because I was running into some performance limits in Pandas. I’m not sure how useful a C++ dataframe is - but I imagine it as being an alternative to going all the way to Hadoop and spark if you’ve outgrown pandas.
[+] [-] markpapadakis|3 years ago|reply
It’s about velocity and experience. Language rarely matters ( and when it does, you can use what’s appropriate ). For us, C++ checks all the boxes.
[+] [-] throwaway2037|3 years ago|reply
[+] [-] _wldu|3 years ago|reply
[+] [-] BruceEel|3 years ago|reply
So, I figured, better the devil you know. And of course: choice of compilers, choice of FOSS libraries, my own libraries and workarounds to various well-known annoyances and, well, debuggers!
[+] [-] motoboi|3 years ago|reply
[+] [-] LewisVerstappen|3 years ago|reply
[+] [-] _gabe_|3 years ago|reply
I'm also using it for an animation tool[1]. I've been using 3Blue1Brown's Manim (written in Python) which is amazing, but it lacks real-time editing and proper 3D blending. It also lacks audio synchronization, 3D texture support, and some more complex features that I'd like to add :)
[0]: https://youtu.be/UAUdIQZKV88
[1]: https://github.com/ambrosiogabe/MathAnimation
[+] [-] koshergweilo|3 years ago|reply
[+] [-] knorker|3 years ago|reply
I mostly write system tools and cloud-focused tools. For the former I use C++, for the latter it's Go.
The portability of C++ just can't be beat. At worst you have to restrict yourself to a certain earlier C++ version (e.g. C++14), but the pure "access" you get to the system is unbeatable.
E.g. you need to call exactly these low level functions in exactly this order? C or C++ is all there is.
And manual memory management is a terrible way to live your life, so C++ it is. (the modern kind, the one where you never write `new` or `delete`, basically ever)
Go seems like it tries to be a systems language, but it's failing at it. The portability is just fundamentally misdesigned. +build comments based on OS name are a known antipattern, and just are neither backwards nor forwards compatible.
Even the stdlib has different function signatures depending on the OS, so you can't a portable use of select(2).
Go is great for tying together parts, though. Read some stuff from GCS, stuff it into PostgreSQL, publish a message on Cloud PubSub, and update a load balancer certificate. I sure wouldn't want to do that in C++ for a small tool.
I should learn Rust. I hear good things. But in order to replace Go it'd need great Cloud support, and that seems to be lacking. And to replace C++ I'd need to actually be able to build and run stuff, even on my Debian oldstable. Too many modern languages require you to upgrade your entire OS in order to get a build environment, and that's a showstopper for me in some installations.
If I can't run my tool in that older environment, then it's not solving my problem.
But maybe it's fine. Like I said, I should learn Rust.
[+] [-] cbm-vic-20|3 years ago|reply
[+] [-] actionfromafar|3 years ago|reply
To me the choice was between C# or C++, but I ultimately chose C++, because while C# is much faster to code in, when there is a problem, coding directly against the OS, I have much more control in what actually happens and in what dependencies I really have.
Edit:
I also must confess that I'm enamored with the idea of having a comparatively tiny executable without any other runtime dependencies than itself and the OS.
For build system I use meson, and cross compile the Windows targets. It works from Windows XP through Windows 10. (If you have any 32-bit version of Windows, you get the "32 bit XP" version. If you have 64 bit but it's older than Vista, you also get the "32 bit version".)
[+] [-] synergy20|3 years ago|reply
[+] [-] jdrek1|3 years ago|reply
Also using it for hobby projects like a custom shell. Modern C++ is a great language and while I'm also using other languages like Rust for hobby projects I still feel the most comfortable writing C++.
[+] [-] mattkrause|3 years ago|reply
If your memories of C++ are mostly wrangling null-terminated (you hope) char** or writing impenetrable iterator types, things have gotten a lot better!
[+] [-] ellis0n|3 years ago|reply
Where is C++:
- the programming language
- core library
- media layer with ffmpeg
Then use new lang to build UI layer, IDE, tools and games
[+] [-] klik99|3 years ago|reply
The shared library has few dependencies outside of LLVM so that it can be as portable as possible, and the runtime hooks are all C and only depend on c stdlib so maximum portability, even to embedded systems.
Video game stuff still frequently uses C++, and also to support consoles, handhelds, quest/etc, C++ just makes sense because it's supported EVERYWHERE (though the compiler doesn't need to run everywhere, so that's more a concern for the runtime).
We're using conan which is FANTASTIC and finally a good package manager for C++, and C++17 (will upgrade to C++19 soon, but still not quite stable/widely supported enough for my taste).
In my world, this whole "C++ is no longer a viable option" meme is just not true. We all hope that Rust or what google is working on might replace C++ but when we discuss it we're talking on the order of 10+ years.
[+] [-] ncmncm|3 years ago|reply
[+] [-] flr03|3 years ago|reply
[+] [-] 3836293648|3 years ago|reply
[+] [-] Kelteseth|3 years ago|reply
[+] [-] nu11ptr|3 years ago|reply
[+] [-] aaaaaaaaata|3 years ago|reply