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.
The rustup toolchain toml file is under your control, dependencies have no affect on it.
This Go feature is like the rust-version key in Cargo.toml where if a dependency specifies in it's own Cargo.toml file that it needs a rust version higher than you what you have you will get an error and your code won't compile (there is no option to auto upgrade the toolchain in rust).
This is incorrect afaict. The Go docs specify that the toolchain directive is only considered in the "main" module. If your dependencies set it, it has no effect (unless they're binary tool dependencies that you go install).
According to the docs[0] you can't declare a go version in the main module or workspace that is lower then the go version of one of your dependencies.
A module’s go line must declare a version greater than or equal to the go version declared by each of the
modules listed in require statements. A workspace’s go line must declare a version greater than or equal
to the go version declared by each of the modules listed in use statements.
For example, if module M requires a dependency D with a go.mod that declares go 1.22.0, then M’s go.mod
cannot say go 1.21.3.
so the "go" directive is like "rust-version" in Cargo.toml and the "toolchain" directive is like the rust version in a rust-toolchain file.
It's totally different.
In go "go build" will fetch a new toolchain without your asking it to.
For that matter it seems every go subcommand will do this (even --help [1]).
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.
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?
And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library.
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
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!
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.
+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.
> Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment.
It is a balancing act.
As an industry we don't "do" training on work time.
So how do you convince developers to work on learning and development during their own time?
One way is to make the language fun and interesting.
> I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features
20+ year devs don't like jumping onto the latest unproven technique/language. Don't mistake that for wanting few/limited features in a language.
20+year developers arent driving transitions to go. It is fairly new developers wanting to switch because it's cool, it's new, and it helps level the playing field by bringing experienced developers down a peg or two.
Having a lot of experience in Elixir and Go I will say that the advantage of Elixir is not excitement, but that you can reason about your code and expect it to work. For years. Half assed go programs will crash. Half assed elixir programs can run for decades without maintenance.
Elixir is way easier to understand than Go. If you will put one week into learning it, you'll be a lot further than you are with go.
I have a couple decades of professional experience, if you are building a serious system, you want Elixir. IF you are building a devops tool, where a single binary with no install process is what's important, you want go.
But given all the containerization and distributed programming people are doing these days using go for that kinda shows to me that most engineering is done by people who don't understand distributed systems.
