Imagine, you have a process like this:
1. tries to withdraw money
2. updates database
and after successfull withdraw, let's say we get an error from database and our transaction will be rolled back. So, what can we do?
solution 1: send an event to message broker and update database again or give back money to client
but, what if our message broker will also fail? will we lose our state and can not give back money to client? So this solution also will not work well.
solution 2: create a background worker and check all payment statuses. It will work and we will have a proper state
Maybe there are also edge cases, but more reliable than first one
1. tries to withdraw money
2. updates database
and after successfull withdraw, let's say we get an error from database and our transaction will be rolled back. So, what can we do?
solution 1: send an event to message broker and update database again or give back money to client
but, what if our message broker will also fail? will we lose our state and can not give back money to client? So this solution also will not work well.
solution 2: create a background worker and check all payment statuses. It will work and we will have a proper state
Maybe there are also edge cases, but more reliable than first one
Believe or not, nix is the best packaging tool ever made for me. It is so crazy.
Here is an example of using custom golangci-lint with
https://gist.github.com/abdivasiyev/eec72445c494f5e4712b627baf5506ce
Here is an example of using custom golangci-lint with
nilaway plugin:https://gist.github.com/abdivasiyev/eec72445c494f5e4712b627baf5506ce
Gist
Nilaway enabled golangci-lint for pre-commit hooks
Nilaway enabled golangci-lint for pre-commit hooks - 0001-feat-Add-nilaway-plugin.patch
👍2
https://injuly.in/blog/phantom-types/index.html
Parse, Don't Validate in action
I really like this approach to write anything, because it will handle all unnecessary security and misusing issues with my source code. And also I do my best to avoid using naked strings or integers in my work
Parse, Don't Validate in action
I really like this approach to write anything, because it will handle all unnecessary security and misusing issues with my source code. And also I do my best to avoid using naked strings or integers in my work
InJuly
Of Phantoms, witches, and type driven design in Haskell
Type driven design with Phantom types in Haskell
👍1
-- >>> parseSrc "λx.x - -1"
-- Right (EAbs "x" (EApp (EApp (EVar "x") (EVar "-")) (EVar "-1")))
EVar "-1" 😭😁2
λ
-- >>> parseSrc "λx.x - -1" -- Right (EAbs "x" (EApp (EApp (EVar "x") (EVar "-")) (EVar "-1"))) EVar "-1" 😭
@@
- lexSymbol,
lexLambda,
lexString,
lexBool,
lexChar,
- lexInt
+ try lexInt,
+ lexSymbol
When you don’t understand how something works, just do experiments.
For example, code works but how? Do experiments with different values or codes.
In this example try changing anything and compile. If you get a new error which have never seen yet, you just learn something new. It is so easy, don’t afraid from mistakes or reddish error messages. They are here to guide you in this fucking crazy world.
FYI: if you are an experienced developer, just ignore this message 🙃
For example, code works but how? Do experiments with different values or codes.
module Main where
main :: IO ()
main = putStrLn $ "hello, world"
In this example try changing anything and compile. If you get a new error which have never seen yet, you just learn something new. It is so easy, don’t afraid from mistakes or reddish error messages. They are here to guide you in this fucking crazy world.
FYI: if you are an experienced developer, just ignore this message 🙃
👍2🔥1
λ
Github is going on the wrong waaay🤢
I have started to use them. Actually they are good as junior developer and if you give straight follow-up, they can do. I've encountered only conflict resolution problem with AI agents. They just fucked up everything and created tons of changes.
λ
I have started to use them. Actually they are good as junior developer and if you give straight follow-up, they can do. I've encountered only conflict resolution problem with AI agents. They just fucked up everything and created tons of changes.
btw, merged pull requests without any overhead. they did very well their work. Only left me to write proper prompt and doing review😕
Time to learn another profession which AI can not do
Proposal to extend JSON with sum types (variants)
Chris Done's Blog - Mon, 2 Feb 2026 00:00:00 GMT
https://chrisdone.com/posts/json-with-sum-types
Proposal to extend JSON with sum types (variants)
A small syntactical addition that I propose to add to JSON is variants. It looks like this:
I trust that the syntax is intuitive and follows norms that a hashtag is a way of labelling something.
The grammar is simply:
It would be more convenient without the quotes, but JSON is primarily a transfer format and secondarily a human readable format. The latter is what JSON5 is for. Additionally, it’s faster to crunch through JSON’s explicitly delimited string literals than more elaborate rules.
I think this syntax gives a good balance of intention and practicality. Sum types exist nicely in XML and static languages (Rust, Haskell), and this is always covered by convention in JSON. It seems about the right time to make this concept first-class.
[TABLE]
➤ @haskell_cast 98cda278a249
Chris Done's Blog - Mon, 2 Feb 2026 00:00:00 GMT
https://chrisdone.com/posts/json-with-sum-types
Proposal to extend JSON with sum types (variants)
A small syntactical addition that I propose to add to JSON is variants. It looks like this:
#"succeeded"
#"failed"("Problem flerbing the fobnicator.")
#"loading"({ "remaining": 3, "completed": 7 })
[ #"foo", #"bar"(1), #"boz"("Ok!") ]
I trust that the syntax is intuitive and follows norms that a hashtag is a way of labelling something.
The grammar is simply:
root ::= string | number | ... | object | variant
variant ::= "#" string variant-arg?
variant-arg ::= "(" root ")"
It would be more convenient without the quotes, but JSON is primarily a transfer format and secondarily a human readable format. The latter is what JSON5 is for. Additionally, it’s faster to crunch through JSON’s explicitly delimited string literals than more elaborate rules.
I think this syntax gives a good balance of intention and practicality. Sum types exist nicely in XML and static languages (Rust, Haskell), and this is always covered by convention in JSON. It seems about the right time to make this concept first-class.
[TABLE]
➤ @haskell_cast 98cda278a249