Though when we talk about JSON (5 bytes - 40 bits) the processing throughput is 20Gbps (this algorithm) vs 5Gbps (previous implementation, 4x slower).
I doubt CPU cycles are problem in that case.
3,506 karma · joined August 23, 2017
e-mail me: alexander (at) kaminski.se
I doubt CPU cycles are problem in that case.
Radio Yerevan: A listener asks: "Is it true that in Moscow, on Red Square, they are giving away cars?"
Our answer: "Yes, it is true. Except it isn't in Moscow, but in Leningrad. And it isn't on Red Square, but on Palace Square. And they aren't cars, but bicycles. And they aren't giving them away, they are stealing them."
I have a application that has actions and actions can happen pretty much in any order. By default all scenarios should be an error except for ones that are in the boundary of logical steps, e.g.
login -> ...[!logout]... -> logout
login -> ...[!logout]... -> dashboard
upload -> ... -> view_file
So I have ~50 actions, ~30 constraints which generate >200 scenarios which then are transformed into test suite.
Yet in short: Prolog is useful everywhere it's simple to express a rule but not that easy to implement it.
% Prolog
next_light(green, yellow).
next_light(yellow, red).
next_light(red, green).
% Erlang
next_light(green) -> yellow;
next_light(yellow) -> red;
next_light(red) -> green.
- `;` in Erlang indicates multi clause function
- In Prolog next_light is database, in Erlang it's just a function
Question: What's the light before green?
% Erlang
% Returns actual value
prev_light_search() ->
[State || State <- [green, yellow, red], next_light(State) == green].
% Prolog (?- means that it's in query mode)
?- next_light(Light, green).
In a nutshell Erlang is more like: "when I have X, then I can calculate Y" and Prolog like "If I want Y, what's the X".
It has 3 HIGH RISK issues because
- DNSSEC is not configured
- Few cookies are send and (ALERT!) Google marketing cookie
- Missing ROA
I get it, it's aggregator but showing red maps is at leals sensationalists
Seems that results are taken from internet.nl, which has WAY better UI than page posted.
Make alias called sdo that echoes sudo path and hash every time you use it to stderr.
That's security by obscurity though.
Upon initial request I have you "URPAY1". If you never check URPAY1 for status, we'll callback you and expect the result. If neither check nor callback succeeded rollback actions are ran (this is contractual agreement on partnership level).
You can verify your status with URPAY1. You need to provide your status check with check ID (URPAY1) and an unique request ID. You will receive a timestamped response. You won't get different responses for same CheckID + RequestID because it's a activity log and also procedure check (e.g. grossly simplifying success at 23:59:58 might be something different than success at 00:00:05 - these times can vary depending on partner, continent, so it's not only midnight etc.) If at any point you didn't get response you can retry and you will always get the same response.
Didn't get URPAY1 for the first time? No problem try againt second time. You'll get the same URPAY1. No new effects needed.
In this design you, as requester are in full power. You can make the same request 100 times which will cause only 1 effect. If networking is lost, something will crash you're still guaranteed to have effect AT MOST once.
In case you're curious for the full flows and handling edge cases Stripe has great documentation regarding how process looks like from merchant's customer's side (as this is their business and you can integrate with them).
It's not about trying again but about making sure you get consistent state.
Imagine request for payment. You made one and timeouted. Why did it timeout? Your network or payment service error?
You don't know, so you can't decide between retry and not retry.
Thus practice is: make request - ack request with status request id (idempotent, same request gives same status id) - status checks might or might not be idempotent but they usually are - each request need to have unique id to validate if caller even tried to check (idenpotency requires state registration).
If you want to try again you give new key and that's it.
There might of course be bug in implementation (naive example: idempotency key is uint8) but proper implementation should scope keys so they don't clash. (Example implementation: idempotency keys are reusable after 48h).
If same calls result in different responses (doesn't matter if you saw it or not) then API isn't idempotent.
If idempotent key was seen then send back response.
Clients intention is outside the scope. If contract says "idempotency on key" the idempotent response on key. If contract says "idempotent on body hash" then response on body hash (which might or might not include extra data).
APIs are contracts. Not the pinky promise of "I'll do my best guess"
I couldn't find any crate that would be ergonomic enough to use and provide features I deem essential, i.e. retryability, scheduling, poison job detection, barriers, backoff strategies etc.
it's an area I'm familiar with so after spending 2 days trying to integrate external libs I decided to roll my own and I'm quite happy how it turned out in 2 days of development.
I plan to open-source it in the near future but right now using it in my another project and it's running quite well.
- Someone likes tool X
- Figures, that they can vibe code alternative
- They take Rust for performance or FAVORITE_LANG for credentials
- Claude implements small subset of features
- Benchmark subset
- Claim win, profit on showcase
Note: this particular project doesn't have many visible tells, but there's pattern of overdocumentation (17% comment-to-code ratio, >1000 words in README, Claude-like comment patterns), so it might be a guided process.
I still think that the project follows the "subset is faster than set" trend.
I mean - I understand, some people have fun looking at new tech no matter the source, but my question is is there a person who would be designated to pick a GraphQL in language and would ignore all the LLM flags and put it in production.
One thing to keep in mind is that leetcode is testing (surprise) social anxiety. You can be a great engineer, terrific peer to have in the time when crisis hits but still fail at leetcode problem because someone is watching.
As they say, you can't see the light in the darkness and the difference between two is like between night and day.
Stable performance, consistent Remote Play to Steam Deck, quick bootup and no "hey want to play, that's a shame cause I got 20 minutes of patches to install".
Sure it's still a Linux with all consequences (had to switch from Wayland to Xorg for remote play and being returning user after couple years it wasn't straightforward) but it works much better.
I won't ever install Windows on my family computers. If I can afford to equip them with Macs I'll do so. If not - they'll get Linux instead.
So the take would be that 84% heavily Claude driven PRs are riddled with ~7.5 issues worthy bugs.
Not a great ad of agent based development quality.
On the other hand I think Rust is better by some margin. Type system is obviously a big gain but Rust is very fast moving. When API changes LLMs can't follow and it takes many tries to get it right so it kinda levels out. Code might compile but only on some god-forgotten crate version everybody (but LLM) forgot about.
From personal experience Haskell benefits the most. Not only it has more type system usage than Rust, but its APIs are moving on snail-like pace, which means it doesn't suffer from outdated Rust and code compilable will work just fine. Also I think that Haskell code in training sets is guaranteed to be safe because of language extension system.
As a huge fan of atomic commits I'd say that smallest logical piece should be a commit. I never seen "intention-in-a-commit", i.e. multiple changes with overarching goal influence reviews. There's usually some kind of ticket that can be linked to the code itself if needed.
Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).
I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.
Piece argued that in medieval times and small cities people knew each other well and gossiped heavily (due to lack of other form of entertainment) and thus noone was truly anonymous. Privacy was taken away through prying eyes looking. According to it the only age of anonymity came before age of information which made it possible to crossreference various source of information which make it a blip on a human history timeline.
And today I'd say we're in the age of hyperinformation where enormous bodies of knowledge are compressed into (relatively) tiny LLMs which make crossreferencing even easier than before.
Keeping mind that Erlang exists much longer than Elixir tooling for Erlang is more robust and mature. BUT its tooling revolves around advanced features e.g. hot updates. For webdev Elixir's tooling is capable enough.