leighmcculloch

The article doesn't discuss one of the most significant differences between building in Go and Rust: tooling.

> Tools that use the GOPROXY protocol as a crutch

What does the article mean that using the Go proxy protocol is a crutch?

This quote had me too. Too real.

Go downloading a toolchain is not any different to dustup downloading the version of rust that is in a toolchain toml file. At least with Go it will presumably only download officially released versions, and not gotip/nightly.

Continuing to work on the soroban-sdk[1] and soroban wasm environment[2], but after spending last year completely immersed in Rust, which was exhilarating learning experience, I'm really hoping to find some ways to spend more time back developing in Go soon and hope to do more of that this year, but unclear on exact plan for that yet.

Also hoping to find some small uses cases for cutting my teeth on using Zig beyond the toying around I've done recently.

[1]: https://docs.rs/soroban-sdk

[2]: https://github.com/stellar/rs-soroban-env

Some prior discussion about why turn on TCP_NODELAY: https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-...

John Nagle's comments about it: https://news.ycombinator.com/item?id=10608356

In several places it is mentioned as a Rust library, but I don't see any links to it. Using google search I'm not finding a Rust library named "Turbo". Is the library open source, or available on crates.io / in a public repo somewhere?

No port mapping, the ports are available on the IP of the VM. Volume mounts are supported by multipass, but dockerhost doesn't set them up automatically, yet!

Rancher's, and Podman's, efforts on Mac are exciting, but you can also just run the Docker daemon in a VM on Mac and install the free docker CLI using homebrew. This is what I do using Canonical's Multipass to create the VM. I wrote a simple script that makes it a simple `dockerhost create`. https://github.com/leighmcculloch/dockerhost

Stellar Development Foundation | Non-Profit | San Francisco, Remote (US, Canada) | Engineering

Stellar is an open network for storing and moving money. The Stellar Development Foundation's mission is to create equitable access to the global financial system.

Most of our work is open source, you can see it at https://github.com/stellar.

Roles hiring at https://jobs.lever.co/stellar?lever-via=BSIk3Flh8Q

Find out more about us at https://stellar.org/foundation

+100 Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment. I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features, which makes me think as I also mature as a developer I'm going to find those things less important.

However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.

Australia has very little immigration to the US it seems.

I added unicode and emoji for fun which is where the YAGNI reference came from. I doubt many websites accept them, even Google don't. But you're welcome to give it a go:

randstr -charset ASCII,UnicodePassword

I've been learning go and this is my first CLI app. There's definitely some YAGNI in this..cough emoji cough..but supporting unicode/emoji led me to expressing the charsets as an interface instead of as a string or array of characters, which are so nice and so lightweight in go.

brew install leighmcculloch/randstr/randstr

or

go install github.com/leighmcculloch/randstr/cmd/randstr

Feedback welcome, especially on project structure and best ways to distribute go CLIs.

Here's my process:

1. Open a PR when you're ready for review. The PR should have the following attributes, which make PRs fast to review, and reduces the back and forth since the reviewer has everything they need to provide a really good review. - Be for a single "What" and have a clear "Why". Both of these should be explicitly in the commit message. - Preferably be a single commit PR. - Preferably be less than 100 lines of changes. Keep them as small as possible. If you see a refactor opportunity while working on something, `git checkout -b do-the-refactor master` and make it a separate PR. People review +10 -3 PRs eagerly and very very fast, much faster than a +300 -200 PR that contains refactors, fixes and other jibble.

2. Drop the PR into a #channel and immediately switch to doing something else. Your assumption in an asynchronous work environment is that you are an interruptable as anyone else. This means you default to being interrupted and pickup another piece of work rather than expecting someone else to be interrupted.

3. If I don't hear back within 24 hours, assign an individual and ask them to put it in their "queue" of work for doing in the next 24 hours.

4. If there's non-LGTM feedback, then make the changes in a new commit (so it's clearly separate) and after that I jump back on some other work.

The take aways are I context switch in favor of not interrupting my team mates. There are plenty of times I need to interrupt them, for help, code design discussions, etc. PRs are not something I need to interrupt people with.

You might think this process means it takes a long time to merge a PR, and when looking at a single PR that's true. But I'm constantly working on 3-4 tasks at a time, interleaved, and using the above process I can still ship multiple PRs a day.

You can use CloudFlare with a custom domain in front of Github Pages. It works. I do this for https://github.com/leighmcculloch/5tweets.com which you can see SSL'd at https://5tweets.com.

US health bills seem extraordinarily high, maybe 5x in comparison to other first world countries. Why is this?

Branchless development is a terrible idea. I think what the author is wanting to avoid is long lived branches. Keep your branches small, isolated, get your changes into the main branch as soon as possible, but develop each atomic change independently of it. We do this at Gumroad, keeping our branches as small as possible, and it's amazing.

ModularFirst, defer the decision to create a monolith or a microservice architecture. Start with a single application and focus on your software design being modular. One way dependencies, single responsibility, and simple interfaces make a big difference here. Breaking out microservices will be simple if you need to, and if you stick with a single app you'll have an app that will grow as a monolith well.

2 hours of running.

Breaking things is time expensive too, plus it erodes trust.

Not breaking things can be time expensive if you do it late, but it doesn't have to if you do it early. If making sure you don't break something is time expensive then you're probably not building on a solid foundation and solid processes.

Be foundation first. Incurring the time expensive to build a foundation (process, infrastructure, software) that will allow you to move fast with stability IS controversial; because it's not the "hack" approach.