It’s much better with uv, but nothing beats the ergonomics of running go mod tidy && go run script.go.
I wish Python had a native way to build self-contained executables like Go. The binary would be larger since it’s a dynamically interpreted language, but as long as it’s self-contained, I wouldn’t mind.
I mean... at first blush it seems like `./scriptname` which is what the `uv` shebang provides beats having to remember two commands and && them together.
It’s easier to do in some languages than in others. I write all my scripts in Python for Python projects and in Go for Go projects. Then, the scripts are called from Make targets.
But doing it in Kotlin is pushing it too far in my book. Kotlin compilation is slow, and running the scripts is nowhere near as ergonomic as running python -m script or go run script.go.
I prefer using a Makefile over creating a CLI. Adding and removing Make targets is trivial and doesn’t require me to fiddle with CLI entry point code. But Make syntax is fugly, so I keep the targets lean, and they mostly just invoke the scripts.
This is all good, but will it be able to penetrate the 12-inch German walls in my apartment effortlessly? WiFi reception was pretty good when I used to live in cardboard houses. But now 5GHz struggles a lot with the thick concrete walls at my place.
2.4Ghz should penetrate your walls better, but maybe not enough better to matter? Wifi 6 and 7 run on 2.4, 5, and 6 Ghz (wifi 6e), as opposed to wifi 5 (ac) which was 5ghz only, so if 2.4ghz is viable for you, you'll get some help from an upgrade.
Some of the coordination stuff might help you run multiple APs, but with strong attenuation from walls, you might not have much overlap anyway.
pros and cons of very thick walls i guess…it’s difficult to make changes to your home.
Wifi 7 (6ghz) barely penetrates a single “drywall” wall (in U.S.). It will have a very hard time penetrating thick concrete / brick walls.
in your case if you wanted good wifi 7 signal in all rooms you’d probably need to run wired backhaul and install an access point per room. Probably not worth it. It might make sense to have wifi 7 in your living / dining space though. Especially if you have an open kitchen.
Why the scare quotes around drywall? It's just gypsum board. If you have plastered walls it's the same thing. But it needs far less skill to install correctly since the sheets are manufactured, smooth, and you just have to hang them.
depends on the user. The short answer is it’s worth it if your wifi airspace is very congested or if you have a use case for wifi 7 speeds, such as moving large files around your LAN often.
The 6ghz band has poor range but this can be a benefit actually. It means your neighbors 6ghz signal can’t flood your home like their 2.4ghz and 5ghz can. So there’s very little interference on the 6ghz band. This also means a more stable connection and a little lower latency.
If your wifi works well today i wouldn’t bother upgrading. Unless it’s a fun hobby purchase.
Any benefit of thick concrete walls other than weird flex?
AFAIK modern building materials are better for environment, insulation, repairs, build time and cost.
Source: dad was a builder and inspector for 50 years in eastern europe. I’ve grown up in german house from 1890. He’s helping to work on my “cardboard” house in NZ now. Big aspect of course is - houses are built to the local conditions and market, but he loathes block/concrete houses back home. They are being replaced by cardboard homes too.
And I'm not entirely sure what part of the house they're calling cardboard. It's typically concrete foundation, wood framing, and drywall (i.e. gypsum i.e. stone) walls.
Drywall doesn't deserve the hate, it's fantastic. Flame resistant, cheap to repair and replace, easy to cut and penetrate to install drops run wires. Wiring my whole house with ethernet was a single day affair because of it.
Thermal insulation is usually better in concrete apartments. Also, when I was working in the US, the places I lived were mostly "cardboard" houses by default. In Germany, I don't have much choice. So in my case, it's not even weird flex.
"cardboard" houses have insulation in the walls. Meanwhile I can't imagine how solid (?) concrete would have better insulating properties than fiberglass insulation sandwiched between two "cardboard" walls.
Blogging pushes me to explore things I probably wouldn’t otherwise. That’s been the main reason I’ve stuck with it pretty consistently[1] for the past five years.
Getting attention was never the goal, so the rise of LLMs has mostly been background noise to me. There have been plenty of times when I’ve searched for something on Google, only to land on my own page.
Over the years, though, things picked up. Now, I’m seeing around 30k monthly readers—way more than I ever expected. More than once, I’ve written about something I barely understood, only for the post to hit the front page. Then people corrected me, and I learned a ton in the process. That’s something I wouldn’t trade for anything.
Me too! These last two posts blogging about blogging are unusual for me. I'm working through a book (Sebastian Raschka's "Build an LLM from scratch") and posting about that at the moment. It's likely not a coincidence that I'm procrastination-posting before going through the trickiest bit...
Thank you. One reason I wrote it was to demonstrate how easy it is to spin up a blog where everything is automated and you never have to worry about the infra.
I’ve tried building a static react blog and hosting it on vercel and while it was easy to set up there was just too much styling and configuration to sort through that by the time it came to writing i was pretty much unmotivated. Markdown seems to be the key here, going to try spinning one up tomorrow. Cheers.
It’s probably geared toward someone like me. JVM and parens are one angle.
Another is that I get paid to work with distributed systems and databases, and Clojure isn’t even part of the discussion in that sphere. Go, Rust, and the usual Python and Node dominate there, so it’s hard for me to care.
However, I dislike language monoculture and am curious about why people like the things I might not care about. This blog is for those.
> distributed systems and databases, and Clojure isn’t even part of the discussion in that sphere
I'm not sure what a programming language has to do with distributed systems and databases, but as another data point, I happily work with distributed systems and databases, using Clojure :-)
(see also https://jepsen.io which I would very much call a "part of the discussion in that sphere", written in Clojure)
I thought distributed system is exactly one of the things that got Clojure going to begin with. Remember Storm?
As to databases, there are a fountain of databases emerging from the Clojure ecosystem: Datomic, Datascript, Datalevin, XTDB, and friends aside, there is Rama, which is a distributed database (or to replace database?)
It’s great, and I learned a ton from Rich Hickey, despite not fully grokking Clojure or FP in general. I briefly worked at a small Clojure shop with an extremely talented crew. People were excited about FP and writing real business logic with it. My stack was different there.
The problem started when the honeymoon phase ended, and the codebase grew as the business gained traction. Dynamic typing became a burden, and once the key people moved on, they struggled to hire developers who wanted to write Clojure.
Also, JVM juju shooed many away. After I left, a coworker told me they had started rewriting part of it in Go, and that was going alright. Now, their stack mostly consists of Python for LLM stuff and Go for the main backend. There’s still some Clojure running legacy systems that haven’t yet been migrated over.
Well you're typically not thinking of a compilation step with Clojure.. so I found the original question a bit not-applicable
The goal isn't to introduce .. a compilation step? but to have the program blow up in the spot where there is an type mismatch. If you don't use a protocol you may not blow up, you may generate a nil, and you may blow up much further down the line (or not at all)
In the rare instances where dynamic types cause problems, they're virtually always something convoluted like that. The protocol design pattern describes the interface and protects you from hard to debug situations
In my experience (mainly when trying to understand the implementation of core.logic), the problem with protocols is that the code inspection tools choke on them.
It was in alpha stage and changing rapidly when they were considering it. But it’s similar to Python’s type hints and isn’t enforced by the compiler. However, that’s better than nothing.
Coming from a love of strong typing (scala) clojure dynamic typing was a real adjustment.
One thing I grew to really love is how small my changes were when I’m just adjusting a decidedly brownfield chain of functions that operate on data. With go in place at work, I added a couple fields to a core data type in my business and I ended up with thousands of lines of changes to pipe them everywhere. Doing the corresponding change in clojure would be <100 lines. I do miss the feeling I get with Haskell that if it type checks, I’m (maybe) good, but like Rich says “List[A] -> List[A] tells me almost nothing about the reverse function.”
The Haskell type `[x] -> [x]` (the equivalent of `List[A] -> List[A]`) tells you an incredible amount about the function. It tells you that the function must calculate a subset of a permutation of the input list. The function cannot be anything else (or else it will crash or hang). In a language with stricter requirements you can omit even the crash/hang caveat.
Don't underestimate the amount of information even simple type signatures contain!
Yeah, Hickey was just wrong about this. For me, watching his talks goes like this:
Hickey: I value X, Y, Z
Me: Yeah man!
Hickey: We get great consequences A, B, C
Me: Ah yeah, I love programming like that. That's why I love Haskell!
Hickey: That's why Haskell is bad.
Me: err, what!?
> It tells you that the function must calculate a subset of a permutation of the input list
As tromp pointed out, "permutation" is technically incorrect. You mean something like "a list formed only from elements of the elements of the input list, and the particular arrangement is independent of the values of the input list"!
I think what he’s saying is the type signature alone isn’t enough, but in some languages like Haskell, people do imagine if the program type checks, it’s good. But that isn’t necessarily true, you need a ton of other context to actually have a proper functioning program, and the reverse function is an example of this.
I didn’t say Haskell was bad though. I love Haskell in a different way from clojure.
Rich’s point is the type signature actually tells you little about what the function does. You need the name, docs, tribal knowledge, your own understanding of the math… etc. to actually understand what it does. Type signature alone is a very incomplete understanding. But come on, do you think I learned how to write Haskell and don’t understand what a type signature’s value is? Give me a little credit.
reply