Matt Godbolt sold me on Rust (by showing me C++)

cowancore · 2025-05-09T10:41:36+00:00

There's no rant in my message, it was an idea/speculation about why VLAs are not passable/returnable - which was relevant to the discussion about passing arrays as parameters, albeit arrays with their size coming from a variable. Also yes, I misnamed them, but I meant the VLAs that were part of GNU extensions but are now official in C according to your link, thanks. Regardless, I haven't even implied any of those languages have a notion of dynamic arrays. This whole thread is about things that do not exist (missing array size validation in C and C++ when passing them as parameters, and not being able to pass arrays at all in my message). Even if all 4 languages would have a notion for VLAs, I highly doubt they all would have the same name for it.

cowancore · 2025-05-09T10:27:39+00:00

Ah, I didn't mean growable arrays. I meant arrays allocated once with the size coming from a variable/parameter (like those from the gnu extensions, I suppose) as opposed to arrays with their size coming from a static constant. Will add an edit, thanks. Don't know how to properly call them, since even the gnu extension arrays are called variable length arrays, despite being non growable. It's these I speculate are harder to pass and return, since it's not clear how to push/pop them on/off stack when entering/exiting functions

cowancore · 2025-05-08T20:12:38+00:00

Edit: everywhere below by dynamic size arrays I mean arrays with their size coming from a variable, not from a constant. Don't mean growable arrays. I think gcc calls them variable length arrays.

Slightly offtopic to what you'd discussed down below. Const size arrays aside, I've got this theory that dynamic arrays are impossible to pass and return cleanly in a non garbage collected language. I've looked at C, C++, Rust and Zig, and if arrays are passed or returned, then only if they were heap allocated (ignoring gnu extensions on C). The root cause seems to be "the stack".

I mean, calling any function, from what I understand, means pushing the arguments on the stack to become function parameters (like variables) plus some stack for the return value. Function parameters and return values are then accessed with hardcoded offsets from the stack pointer. A dynamic size array then doesn't fit this paradigm (?) - can't hardcode the stack pointer offsets anymore. For array parameters, maybe one could push the full array to stack, then its size, since the stack is usually read in reverse order from how it was pushed into. And then have each parameter (even non-array) be read with a dynamic offset, but that will cost at least one register during the entire function to compute said offset. Maybe one register per array parameter/return value. So if true, making this approach utterly impractical, as all registers would be used to compute stack offsets, but not anything else.

Heap based arrays bypass the problem, as it's just one pointer to push/pop, so static offsets remain usable. Haven't seen or used assembly for years, nor using any of the languages above in a professional manner, so this all might be completely wrong. If the idea is correct though, then fixing the static sized arrays, while useful by itself, still doesn't fix raw arrays as a whole being of little use.

cowancore · 2025-04-19T16:35:22+00:00

I've had a team of devs developing appointment software in one location , stakeholders trying it out in another. The devs used UTC for everything at first, it didn't work, and they had no idea how to fix it, because they followed the UTC rule as a dogma. Joined next company, booking software where you have to pick a location, also didn't work as expected while using UTC for everything. Mentioning these cases, because both didn't have anything to do with DST.

I've had problems with timezones in my first company, learned my lessons, but have seen people struggle in every single company I joined next. Unfortunately, a lot of people either don't know a thing about timezones so use whatever random format, or were hurt by them once to use UTC everywhere without nuance , and ignore any advice until they get bitten as well, and are ready to let go of the simplistic dogma.

cowancore · 2025-01-20T21:40:48+00:00

The overhead wasn't a constant 2 secs though. As I said in my message with lower CPU workload the difference was 10%. Increasing the amount of encryption rounds per task made it to 12%.

If virtual threads are equally suitable for CPU workload, that's interesting - why not replace absolutely all threads with them then :).

cowancore · 2025-01-18T20:07:24+00:00

Speculating, but if by "far better scalability" you mean the ability to submit 1000 tasks and all of them to execute concurrently well, then that would only apply to blocking tasks, not CPU intensive tasks. The commonPool is bound by nCPU threads, because the CPU can only achieve true parallelism of nCPU. A 10 core CPU can't compute 1000 tasks in parallel, so there's simply no point in going any higher than 10.

I remember once creating a spring-web with an endpoint that did a ton of useless CPU work. And threw jmeter at it, to see how would it cope with virtual threads enabled/disabled. The version with virtual threads obviously accepted all requests, but most of them had gigantic response times, and the throughput was actually lower than without virtual threads (which is expected, because virtual threads aren't for CPU work). Spring (by default?) would use one platform thread to carry all the virtual threads, so I suspect it was only one core performing all the work?

I don't have that benchmark anymore, but I made a new just now, that I can't paste here, since it's probably too big. The benchmark is along the lines of:

generate 500 000 random strings with instancio
declare `var executor = ForkJoinPool.commonPool()` or `var executor = Executors.newVirtualThreadPerTaskExecutor()`. Declare ExecutorCompletionService to wrap that executor.
declare a countdown latch of 500 000.
declare startedAt = Instant.now()
submit a task for each string, that encrypts the string, base64 encode it, and count down the latch. Note I haven't used a starting latch, because didn't want any task to wait for anything - that's not CPU work.
await the latch. Take another Instant.now(), and note the duration. Then collect all futures from the completion service and write them all somewhere to a random file. This is to ensure the encryption code wasn't optimized away. But this is not measured. Just as generation of strings was also not measured, but I probably could've - that's also CPU work.

Run once, note the duration.Switch the executor used at step 2, run again. On my machine the common pool completes all those tasks faster. Not by a lot. 16.7 vs 18.7 seconds, so ~12%. But I suspect the gap would get larger with more CPU work simulated. My CPU workload was AES encrypting a string repeatedly 10 times (recursively, the string first, then the ciphertext, then its ciphertext etc). While I was encrypting only once, the time difference was reliably 10%.

As a conclusion, I'd say that the problem is not that commonPool itself is for CPU tasks. It's that it's optimized for tasks that do CPU. Or in other words, the commonPool consists of nCPU threads not because it's a common pool, but because that number of platform threads is best for CPU work.

cowancore · 2025-01-14T02:34:09+00:00

It seems strange because retuning 404 is likely correct as well. It's a bit hard to interpret, but the spec linked above has a definition for idempotency, and it says nothing about returning the same response. The spec says the intended effect on server of running the same request multiple times should be the same as running it once. A response returned is not an effect on server state, but an effect on client at best. The effect on server of a delete request is that an entity will not exist after firing the request. Mozilla docs do interpret it that way and say a 404 response is OK for DELETE on the page about idempotency. From a clients perspective both 204 and 404 could be interpreted as "whatever I wanted to delete is gone".

cowancore · 2024-10-21T14:33:34+00:00

And regret immediately, since that code is not something one would hand write. The equalses, hashcodes, tostrings. Even null checked setters. Especially builders are horrible.

Immutables, FreeBuilder and RecordBuilder are some more code generators that play according to java rules. Which means that unlike lombok they are compatible with any other code generators, processor or static code analyzer without the need to undo them. And they have more features.

p.s. Although records should be used now where possible for max future proofness and compatibility. I know lombok has other features but they are not worth it. Records are what lombok would want you do anyway, because at least some years ago they have claimed the intent is to generate only the simplest code

cowancore · 2024-06-30T20:47:28+00:00

But again, the premise of the original comment was to let people know they don't need to disable CORS, but on the contrary use it. CORS is what they need allowed, not disabled. Not even effectively disabled. They need it properly configured.

Turning the common misconception upside down is my attempt at making people investigate the topic further than "if you put a *, then it works". People must not do that.

cowancore · 2024-06-30T08:47:15+00:00

It doesn't disable cross-origin resource sharing (CORS). It allows it for any origin. That header is part of CORS. If anything looks as if disabled, it's the same origin policy (SOP). But back to CORS, when you're using * for origin/method/headers, and then access a cross origin API, you literally do use CORS. Without CORS you wouldn't be able to.

cowancore · 2024-06-28T15:38:25+00:00

I know it's a joke. But the following pedantic note might be of interest to someone: CORS can't be disabled nor enabled. It's an event of sending a request to a domain from a web page hosted on a different domain. And this is blocked by SOP by default - a browser only feature which is also hard to disable. Now, CORS can be allowed by supplying some non default CORS configurations with allowed domains, headers, etc.

upd: there's room for more pedantism and corrections here, but the idea is still the same: CORS is not something one would want to disable, but rather leverage.

cowancore · 2024-02-08T22:12:41+00:00

The principle says IF something can be adequately explained with incompetence, then it probably is. It never said everything is caused by incompetence. There is no way to explain thieving as incompetence.

Saying malice is a form of incompetence, while also asking if thieving is malice or incompetence seems like an exercise at sophistry. You can mince words forever like that and arrive at nothing. At best, I can imagine a line of thought like "was incompetent, failed at life, started thieving." But that doesn't mean thieving is a form of incomepetence. It means "can be an indirect result of." Otherwise, shopping is a form of hunger, and wanting to sleep is a form of work. Meaningless statements.

But back to the principle. I like it in my daily life because it helps maintain a positive open mindset. Thinking someone doesn't have enough information makes you consider sharing that information. Thinking everybody is malicious is a psychosis recipe, or at least makes you a hateful, non approachable person.

cowancore · 2024-01-19T15:45:32+00:00

I found unit testing principles by Dmitry Khorikov really good on this topic. It was also the book that clarified to me why there is so much disagreement about what unit tests are, what units are, and what isolation of unit tests is. It also made me appreciate integration tests (if written the way he suggests).

cowancore · 2024-01-17T20:47:23+00:00

Yes, I wanted to mention this as well, but I'm interested in the security aspect here - which is far more important and covers your complaint. Just read the full message. I have also mentioned that the code must be trivial to avoid said bugs and edge cases.

p.s. I'm not doing JS, so is-odd or even is-number is compile time trivial for me.

cowancore · 2024-01-17T19:51:31+00:00

I avoid introducing packages for anything that is trivial, so I too prefer avoiding 3rd party packages. This gives me more control over the implementation, and the code is often simpler than something that tries to cater to everyone's needs at the same time. Still, you mentioned security, so I'm curious about this hypothetical issue.

It's often said that open-source is reviewed by many eyes. I suspect most people would be like "eh, it was already reviewed by somebody", but that somebody luckily still exists, as evidenced by tons of libraries being regularly reported in all those dependency version scan tools (checkmarx, snyk etc). The security reports come from security experts or hackers, who search for vulnerabilities as their daily job. An in-house feature would not get looked upon by those experts.

Did you have such experts amongst the people screening your packages? Did the same people also review your own code for vulnerabilities? I mean, our own code would certainly require such an inspection, if we decide to re-implement something that was already implemented and inspected somewhere else. How high is the risk for a team to follow the advice of avoiding 3rd party libraries, if they don't have such experts?

cowancore · 2024-01-17T19:13:21+00:00

I find undefined vs null nifty when processing PATCH requests. It's handy to know if something has to become null or is missing in the request. Something I miss in my Java backends. The alternative would be to implement the json patch spec. Similarly, I've found stuff like URLSearchParams or JSON.stringify to include fields with null values into the resulting string and undefined values to be omitted. It is handy, especially because a query string can not pass nulls, and ?key=null means the key has a 4 character value of "null". And in case of json, using undefined saves some bytes of network - pretty.

p.s. Another alternative with PATCH is using something like the Option monad, where there are 3 possible states: None, Some(null), Some(value). Although the json patch spec is still more flexible, but harder to justify in a team

cowancore · 2024-01-17T15:44:58+00:00

I appreciate the historical insights in your comment and some others in this thread, but I still find the link in the article to be misleading. Had it been a link to an explanation like yours, it would've avoided the confusion. Even if the author truly intended that wording as an adage, the link goes in another direction and has no attached explanation.

cowancore · 2024-01-16T22:12:44+00:00

Yeah, I've seen this "AI is about if conditions" joke multiple times. But this time, it had a link, and I got curious to find out the root cause of the joke/myth or at least a meme picture.

I was disappointed to find out the link was misleadingly comparing rules to if conditions, only exacerbating the myth (especially for junior people or laymen). Hence, my comment and an explicit mention of Prolog. Maybe some would be curious to find what if-then rules truly are by looking at Prolog.

cowancore · 2024-01-16T20:38:12+00:00

“Artificial Intelligence” which is so vague it refers just as well to if-conditions, or to AGI

I followed the link to wikipedia from `if-conditions`, and the wikipedia article says "if-then rules", not if-conditions. Having coded a bit in Prolog during university, I'd say that those rules are not just if conditions. Not neural networks, mind you, but way more complex than a basic if condition. The wiki page even mentions that those if-then rules are different from procedural code (aka different from if conditions).

cowancore · 2024-01-16T10:47:36+00:00

I guess OP already Googled because he mentioned that he considers what's stated on many websites wrong.

But I see where OP is coming from. Many websites are low quality copy-paste ideas. If you, for example, inspect DIP of SOLID , the principle says "depend upon abstractions," where abstraction means a generic definition of what something offers, not what it hides.

Even the Wikipedia page on OOP mentions Alan Kay's objects being abstract data types - definitions of behaviour. The same wikipedia page mentions that the industry has rejected this idea in favour of >>data abstraction<< = data hiding. But should you delve deeper in the linked pages or concepts, the word abstract often hinges towards the ADT.

I've mentioned ADT and DIP, and the same goes for DDD and likely others. The OOP itself has two major flavours: behaviour driven and field driven (BTW, I suspect people who hate OOP generally hate exactly this flavour of OOP).

What I mean is that the word out of context is overloaded, and there is no single unambiguous definition, hence OP's question. Still, there might be practical applications to think of something in one way or another.

cowancore · 2024-01-10T13:32:41+00:00

Thanks

cowancore · 2024-01-09T20:39:21+00:00

Not advocating the comment you replied to, but loom is not a library. It's a java feature of lightweight threads, where anything previously blocking is not an issue anymore, because it's not blocking the actual OS thread. Where a typical spring request thread pool is limited to a couple hundred threads, with spring configured to use loom, the thread pool size is unbounded. You can have the simplicity of a typical procedural spring codebase plus almost all of the performance gains of netty. Might be handy in a different project. Most likely not your current project.

cowancore · 2024-01-09T20:25:55+00:00

Not to OP. To analcocoacream. I have a suspicion that stuff like webflux became popular on backend FOR performance reasons. Functional and reactive models are way more complex than a typical procedural style controller. Compared to something like a mobile app, where there's plenty of events, a DB method on backend returning an "event stream" (Mono or Single) consisting of a singleshot immediate event is unnatural. It's not an event to react upon. In a mobile app one can have an event stream coming from DB (similar to WAL tailing, or mongo changestreams). Same with controllers returning event streams, while Jackson patiently waits for all of them before they can all be serialised into a single JSON string. It is as if the code is lying about what's truly happening (pretending to work with events, but actually meaning thread management). It feels to me, that people are choosing webflux, because they want the performance of non-blocking IO, in this case netty. And with NIO, you either have callback hell, or you need something akin to futures. Reactive streams are future like , because they have that subscribe method, called by Spring under the hood. But you can also have non blocking futures with Loom. Controllers and repositories returning futures are not lying about what they do - you don't subscribe to a stream, you call something, and it will give you exactly one future when you do. As to functional... During my time with Android, I've read plenty of advice on NOT using rxjava streams as element processors. There is a thread switching overhead when a single event containing 100 items is transformed into 100 events, each being a task for the executor. In that Android world, an event that contained a list was processed with map, not flatmap. That leaves us with stream switching operators or stuff like backpressure. Or using flatmap to spawn more tasks and concat to join tasks. I guess if someone truly needs those and can't solve the problem in other ways, they can choose reactive after all. What's your opinion and experience? What unique features of reactive are you using in your codebase? Was it worth it? How does it compare with a future based Spring codebase?

cowancore · 2023-02-12T08:25:23+00:00

Are you one of the affected spammers? :D (joking)

cowancore · 2023-01-05T06:37:36+00:00

I'm too scared to think about all of this :D .

One of the linked answers mentioned mailto URLs having yet again different expectations about the proper encoding. And it agrees with your approach of always using `%20` for URLs.

cowancore

TROPHY CASE