Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


>Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.

I have used this library in the past and was actually pretty easy

https://github.com/nlohmann/json


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.


A mere 25k lines of self contained C++,…

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.


It took 30 minutes to cure you?!?

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 was teaching one of the local highschool kids how to program in C and they asked "So why does everybody use i,j, and k for their indexes in loops?"


i stands for index. j and k because we can't use i anymore, and maybe because they are close together on the keyboard


I only use 'j' and 'k', not 'i ' -- the rarely-used letters are easier to search for.


ii is also good.


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.


Let me carefully copy paste my personal stringutils.hpp file of string handling routines and I'll be right up to it!


Gotta have those "readfile()", "replace_substr()", "split()" etc! I do have a copy paste string util header. ..

I really wish there were more string util functions in Cpp. I mean C had strtok()!


strtok() is one of the most dangerous string handling functions in any language!


strtok() is like a hot art student, smoking a cigarette. I think I've got to it once.


In the C language, you do not get to strtok(3), strtok(3) gets to you.


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.


If you have any problem that isn't vector math, it's absolutely awful. Even IO is unpleasant


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


I guess the scarcity of cheap labour contributed to the demise of C++ in the applications world.


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++.


I still tinker on a game engine personal project just to scratch the C++ itch. I really like using C++, despite all the hate it gets.


I just wish to _not_ work with Python.


Why is that? I'm genuinely curious. Also, what languages / environments do you prefer?


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


The idea of using Rust for scripting is bizaar.

I can understand not wanting to use Python for everything, but I see the problem being the 'use it for everything' not the language choice.

Use the tool that excels at the job. There is no language that is good at everything.


Incidentally, this thing comes up a lot: Python vs Rust for scripts. I wrote a comparison four years ago:

https://news.ycombinator.com/item?id=22712441

And updated it six months later:

https://news.ycombinator.com/item?id=24595081

That's still how I'd do this task today.

Anyway, I don't think that Rust is always a great choice for scripting, but if you already know Rust, it's totally fine at it.


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.


cargo -Zscript is in nightly


> The idea of using Rust for scripting is bizaar.

Not at all, I do the same.


Rust is cool now. Python is not cool anymore.


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.


I think Python fell victim to the Peter Principle. It got promoted beyond its competence.


Python does well for several reasons.

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.


The way you define the entry point function is so bizarre I assume scripting was the original use case.


Could be. But it also gives you the flexibility to set tests inside the module files.


Having to use the wrong tool is not cool, ever. So I don't care how cool Rust is right now, I still am not going to use it for scripting.


Have you tried it? How would you know that Rust is the wrong tool.

I'm indifferent when it comes to Python vs Rust for scripting, but I'd take Rust over a shell script (of any variety) any day.


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...)


For a single file script, you can avoid managing environments by using a nix shebang: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f...


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.


Pixi.sh has been great for me so far, it’s a single binary install that can install Python, conda packages and PyPi packages, maybe give it try!


Looks nice but I can't really require the whole team of like 100 people to use this quite niche tool.

Python needs an official solution.


poetry with poetry2nix with nix flakes will do magic in terms of setup.

if stick with pyright(inference) it is as modern as rust.

python speed increases heavily in all directions.


> 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.


Any non-trivial python is indistinguishable from magic.


Often I think that I'm lucky, still working on C++ desktop applications.


Where I am, we still do!


What libraries are you using? Qt? Do you use anything for database access and rest API (or protobufs like we did) or just custom code?


Qt for everything UI-related, yes. SQLite for databases, though looking again that code is actually Python. Nothing networked, so REST isn't relevant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: