I miss my days working with C++. It's moved further down the development stack than where it used to be. We used to handle UI, API parsing, and pretty much everything using C++.
I felt some nostalgia for Fortran a while ago. Spent half an hour programming in it, cured. Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.
A mere 25k lines of self contained C++, bundled in a single header as the one true distribution format. I note the CI cmake script at a thousand lines of cmake. That's a very idiomatic representation of a C++ library, thank you for the example.
Oh come on now, about 7.5k of those lines are comments and/or blank lines. Furthermore, a good chunk of the code is devoted to type checking, thorough error handling, compiler compatibility and/or workarounds, etc, all within the restrictions of C++11.
… bundled in a single header as the one true distribution format.
Yes, build systems are a significant pain point for C++ and C. Many users prefer to largely avoid the issue and use header-only libraries. That said, Conan and vcpkg are making genuine strides at improving the issue.
I note the CI cmake script at a thousand lines of cmake.
This is ridiculous. It’s a CI script running multiple test suites over dozens of compiler versions, of course it’s going to be a lot. Would it make you feel better if that CI script didn’t exist? If not, then what’s the “correct” size for CI script?
That's a very idiomatic representation of a C++ library, thank you for the example.
The library is genuinely good. It’s portable, well tested, user friendly, and widely supported. Your snark is unwarranted.
Your recommended json solution was also my first thought but if you do not have the ability to easily introduce a new dependency then the op is correct.
If I have an existing JSON file that I want to quickly parse for a demo project there is almost zero chance I would pick C++. In comparison, Python is already installed in many environments and has built-in json parsing.
One of the first things I did when I got my PiDP-11 which can run RSX-11M and the DEC fortran compiler. I spent many many hours programming in Fortran when I was in college and thought wow I could relive some of that, about 5 minutes in I was "okay, step slowly away from the console." :-)
There's a fun stream where tsoding decides to learn Fortran, and the instructions he's working from say to turn off implicit typing (ie write "implicit none"). He's familiar with modern languages with type inference and with C++ type deduction which is a similar idea to full blown inference - and so he has no reason to even guess what Fortran is going to do without that admonition and you can see he's not happy when he finds out.
I don't get that at all. Old FORTRAN has a mildly confusing feature that is easy to disable. He then got upset about the mildly confusing feature that everybody now disables. If one wants to bitch about Fortran, at least complain about the modern language (which is still a horror show of poorly defined and often unportable features), not the stuff that has been made obsolete.
I recently had to port an existing C++ JSON parser into a new project, and even though it was complete in terms of what we needed it to do right now, adding any kind of additional functionality to it would've been a nightmare.
Vector math on raw floating point that is. If you want to wrap that float in a type to force (physical) dimensional consistency, you are going to have a bad time.
Same. I really miss it. Not terribly long ago we had an app that has a client and server, both in c++. UI, API, everything was c++. It really felt like the universal language had arrived. I won't pretend everything was perfect as it wasn't, but work was fun and the high caliber of people who could work in that stack was a joy to work with. I've never had a more exciting lunch than when we got distcc running on our blades so we could execute builds way faster. It was also a joy not being the only Linux zealot :-D
At my work pretty much everything but the UI is in C++. I suspect the only reason the UI isn't C++ is so we have a portion of the cosebase that recent grads can work on right away without having to train them up in C++.
Because Python falls all over itself in larger projects, and is poor at utilizing resources efficiently. It's fine for smaller things that don't care about cpu cycles. I would much rather use Rust in a large project.
Not gp but I prefer rust to python and I'm itching to try that "just write your build scripts and stuff in rust too"
Sure the builds are slow and Python _kinda_ has static typing, but rust just has a lot of stuff I like and it's practical to install and use natively without learning all the jargon like venvs and eggs and wheels and which package manager and package manager manager (rye?) to use this year
I tried Python years ago and never got the motivation to push through that learning curve. I've used c++ a lot but it always required me to "keep my hands inside the ride at all times". Rust feels like it actually wants to be easy to use
Same for C++ with a good options library and std::filesystem IMHO. You can kind of script with that. I did it and was surprised it did well for some of my engine tooling.
The current project I’m working on has tons of resource caches (for performance), with tons of non-owning pointers sharing cache references. I’d hate to do this in opinionated languages like Rust.
Some that come to my mind: its versatility binding native code and its easy-to-fit in your brain mental model for many tasks. The fact that you can script with Python without a compilation step also helped a lot to spread its popularity I think.
There are many things I have not tried, ranging from Rust to heroin. "You don't know because you haven't tried it" is really bad epistemology.
It's also totally impractical. Rust isn't the only language I haven't tried; there are more than a thousand of them. I'm not using JOVIAL for scripting, or Fortran, or a bunch of others. No, I haven't tried any of those either. No, I'm not going to.
Turning specifically to Rust, I don't use it for scripting because it's not what I look for in a scripting language. It's compiled; I look for a language that doesn't have that extra step. It has the borrow checker; I don't write scripting code that needs that level of discipline and care.
In fact, most of my scripting is of the form "pick some bits out of a text file". For that, Perl is my tool of choice. Sure, other languages have regexes. None of them do it as cleanly and simply as Perl. (Note well: "clean" does not apply to the Perl syntax...)
Same for me. Mainly due to the packaging fiasco (and to a lesser extent, imports).
The actual language is not awful. Some features are even nice, like infinite precision integers by default, and separate / and // operators.
Language is ok. Setting everything up is atrocious.
The other quite annoying thing is that the docs are extremely badly organised so Google rarely points you directly at what you want. Instead you get stuff like w3schools which is trash, but much better organised. Also annoying that the docs still don't include types.
I would use Typescript (via Deno), Go or Rust instead. There are some other Python replacement languages I haven't tried yet that might be an option like Mojo, Lobster, Nim. Probably still too niche for production; I'd stick with Typescript.
> poetry with poetry2nix with nix flakes will do magic in terms of setup.
I'm sure, but it also sounds like it will take about 2 weeks of reading manuals and learning Nix before I'll get to the same point as Rust and Go start at.
And that's not really an option for big teams, which is the only situation where I'm forced to use Python anyway.