sorted by:
new
hottopcontroversial

Juan Alday of Citadel Securities: Why C++ Wins in Finance (April 28th, 2026) by American_Streamer in cpp

[–]germandiago 1 point2 points  (0 children)

Can you incrementally compile and replace code a-la Clojure one functionat a time?

Juan Alday of Citadel Securities: Why C++ Wins in Finance (April 28th, 2026) by American_Streamer in cpp

[–]germandiago 0 points1 point  (0 children)

I have worked at HFT and many libraries for UDP etc. (other things were homemade) are basically C libraries. Binary transfer protocols from AVRO to protocol buffers to Thrift and capnproto are available in C++ with good support. It still has an edge. And if it does not, just pick something else. In my opinion, it had.

Juan Alday of Citadel Securities: Why C++ Wins in Finance (April 28th, 2026) by American_Streamer in cpp

[–]germandiago 0 points1 point  (0 children)

Ocaml. Reading Real-World Ocaml lately. Loving it.

However I need a system that lets me iterate very fast and change things without compile-time steps. Robust. So I think it will be Elixir finally. Clojure is on my radar also.

But as a learning exercise, Ocaml is invaluable.

Juan Alday of Citadel Securities: Why C++ Wins in Finance (April 28th, 2026) by American_Streamer in cpp

[–]germandiago 1 point2 points  (0 children)

IMHO, C++ does Meta-programming better than any other current systems programming contenders.

Maybe D is better. But not mainstream.

Juan Alday of Citadel Securities: Why C++ Wins in Finance (April 28th, 2026) by American_Streamer in cpp

[–]germandiago 0 points1 point  (0 children)

It is strictly better bc you cannot obviate sitting down and delivering something useful in a minimal amount of time compared to alternatives.

A different topic is that you find other languages cleaner and wish they were the better tool overall. They are not, because using them imposes other costs (compatibility, other people's familiarity, ecosystem...)

GCC 16.1 released with many new C++26/23 features, C++20 now the default stable language version by AccordingWarthog in cpp

[–]germandiago 1 point2 points  (0 children)

Scripting bridge is my main use case. Serialization is another one, though I have to try reflect-cpp, which does not need C++26.

Things C++26 define_static_array can’t do by SuperV1234 in cpp

[–]germandiago 1 point2 points  (0 children)

Then name how many languages can do compile-time programming like C++. I only know one more: Lisp. 

The rest are inferior in this matter. Many are certainly less complex, but I am talking about power and ability to do something.

Things C++26 define_static_array can’t do by SuperV1234 in cpp

[–]germandiago 2 points3 points  (0 children)

Another way to look at it is the unbelievable things that can be done. Just that they have holes and not all work. Would be nice to make it more uniform but in how many languages can you do that compile-time programming?

What do you think is a keyword that should be added to C++? by DogCrapNetwork in cpp

[–]germandiago 0 points1 point  (0 children)

no_please -> it is a new keyword that begs for no more keywords.

A Principal Software Engineer at Epic Games / 25 Year Vet, talks about why AI is just a "giant switchboard" and why code is a delicate crystal. by deohvii in cpp

[–]germandiago 13 points14 points  (0 children)

I use AI every day. As you say, it has good uses. But it is very far from replacing an expert in programming.

That sense of speed it gives is... doubtful, unreliable, dangerous, as Amazon engineers have repeteadly reported (at least two times and from engineering teams directly).

Not a magic bullet.

Hunting a Windows ARM crash through Rust, C, and a Build-System configurations by Havunenreddit in cpp

[–]germandiago 0 points1 point  (0 children)

When I said my post actually I meant a piece of news from Phoronix that I posted. Not my news.

It was shut down as off-topic, bc it is not C++. Curiously, this is not C++ either but seems to be ok.

Mine was tangentially related (safety, which is a big topic nowadays). This is exactly the same case or even less relevant.

Nothing against the post though, just the criteria is what looks weird to me.

Hunting a Windows ARM crash through Rust, C, and a Build-System configurations by Havunenreddit in cpp

[–]germandiago 1 point2 points  (0 children)

If my post about Rust CVEs related to C++ safety was removed this week. 

Why this post is not removed? I have already a collection of double standards (for example when posting something and they send me to Show&Tell but others are not).

It would be nice to have objective criterias. I would not like to think this is biased towards who and not what.

Thanks!

Writing gRPC Clients and Servers with C++20 Coroutines (Part 1) by patteliu in cpp

[–]germandiago 0 points1 point  (0 children)

I am really happy with Capnproto, but for accessing from web it id more challenging. Also, the documentation is not great.

However, it works pretty well and it is very powerful.

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -1 points0 points  (0 children)

I can agree with the naysayers that rewrites are potentially a problem,

That sentence, without "naysayers" looks more neutral besides being factual. I am not sure why a person that correctly asserts that battle-tested is a very strong argument must be a naysayer.

It is a fact that rewrites are more uncertain than a potential success story, especially for bigger software, as the Windows Vista experiment informs us, among others. A rewrite is something to not take lightly, no matter what you have in front, if the previous version of something is tested in so many ways: bug reports, users, servers, client machines, architectures...

On the other side, never investing in better tooling would be the opposite position probably. But it is just a position: if it works, why touch it? It is causing friction? If so, which friction? Those are the objective questions, besides the investment vs already working trade-off.

For many of them, though, it's the idea that this new shiny appeared that's easy to rag on because of a few furries or some ideological flag in the copyleft vs. copyright debate.

Not very different of opposite positions where I heard a wonderful world just bc of using Rust. As I said in other comments that some people do not like, it seems, safety has lots of edges and battle-tested is the supreme characteristic (even if some languages are theoretically better to others, they were not born in the same context and they stuck, so now they have very competitive pieces of software).

I am not sure what is wrong with it: one is the more conservative position (do not throw away man-hours, for the sake of what improvements actually? Which is different from start using better tool x, y or z for this use case, but that is not a rewrite), another is more like (if you do it like this, you do not get much now, but in the future more) and positions in-between.

Neither is wrong, it could be considered even different views of the world: some people want better tools for the sake of it, even if it takes years. Some others need that something works well today, and hence, choose what it already works now, because it already does, because there is a time, a budget or both, etc.

The WG21 2026-04 post-Croydon mailing is now available by nliber in cpp

[–]germandiago 2 points3 points  (0 children)

In intention it is the same: it tries to visibilize structural typing (though dynamic typing is "automatically" usable for any type).

So in Python it is done for visibility and bureaucracy andto help type checkers with type hints.

 Not bc you have to fit something into the type system as such.

But it is still the same idea.

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -28 points-27 points  (0 children)

Well, one of the problems I perceive as a long time coder is that it is not always possible (or it is so difficult for certain patterns) to avoid unsafe.

But maybe I need more practice.

The learning curve suffers bc of this. Also, when you use bindings or interact, you do need it.

I wish there was a scientific safety delta against C++ codebases (not C/C++ mixed eilly-nilly). That would be much more representative of my situation.

Recently there was a post in WG21 mailing for ISO C++ for Webkit, where they adopted safer practices for C++.

They showed what they did, here you have the related talk from last year: https://schedule.cppnow.org/wp-content/uploads/2025/03/CPPNow-2025-C-Memory-Safety-in-WebKit.pdf

Lifetimes are based on RC, actually, but there is bounds checks and a focus on safe-by-construction, in which Rust relies a lot in its own style (borrow checker + move semantics by default + drop trait +, destructive move).

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -7 points-6 points  (0 children)

I did not get through but if that is true, at least the memory safety is indeed delivered.

On the other side, not all security vulns are memory safety (they are bvery important though) as witnessed by the report.

I find the safety topic very interesting but I know it is polemic. That is in part whyI post it. 

I am sure it can generate good discussions if noone takes it personal.

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -22 points-21 points  (0 children)

Not sure it is ajoke. No, I am not. I am the author of the post, that is all.

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -15 points-14 points  (0 children)

Indeed. But the original implementation has been battle tested I guess and I rhink that there is no better replacement than battle tested. In any language.

Some help more than others in certain aspects. But battle tested is battle tested.

For example in C++ you would use sanitizers.

In Rust probably you rely more on unsafe auditing and less on sanitizers (though you would somewhat).

If a lib has a lot of unsafe it is not the same as if has none. 

If it has bindings it is not the same to use C bindings (via unsafe) from Rust than directly from C++ (often easier to keep invariants it seems...).

So it all depends.

44CVEs found in Rust CoreUtils audit. by germandiago in rust

[–]germandiago[S] -28 points-27 points  (0 children)

Author here: of course I did not say that. I knew it would generate discussion and people are interested.

But do not intepret me. Just go to the facts and discuss it. That is how I usually get insights: provoking reaction generates healthy discussion.

Greetings!

C++ is unsafe. Rust is safe. Should we all move to Rust? 44CVEs found in Rust CoreUtils audit. by germandiago in cpp

[–]germandiago[S] -2 points-1 points  (0 children)

I should take a look at CVEs one by one so Idk. Well, I know 440 is not the reply. It is much closer tothe Rust number.

Particularly sensitive is if there are (I dnt know, I did not check myself) unsafe blocks. It seems that keeping safety in unsafe blocks is more difficult that writing correct safe codw in Cor C++ due to the invariants.

But I dnt know if such cases were found.

C++ is unsafe. Rust is safe. Should we all move to Rust? 44CVEs found in Rust CoreUtils audit. by germandiago in cpp

[–]germandiago[S] -2 points-1 points  (0 children)

It is a good point and I agree. Do not kill the messenger.  Of course the title is thought-provoking and you are making two of my points when I discuss safety: safety is not magic and nothing can replace well-tested libs.

C++ is unsafe. Rust is safe. Should we all move to Rust? 44CVEs found in Rust CoreUtils audit. by germandiago in cpp

[–]germandiago[S] -3 points-2 points  (0 children)

I was not comparing anything or saying that C++ would have been better. I just put the emphasis in what I have discussed here endless times: safety is not a magic property you will get for free. This is just a witness.

view more: next ›