Three Minor Features in Go 1.18

You don't need immutable structures to communicate between goroutines. Value types are fine. Just think a bit about how to use channels as signal carriers, it eventually starts to make sense

V2 - Nehalem/Jaguar

V3 - Haswell/Excavator

V4 - AVX512

Ah, and a map that performed side effects.

Other than that it's unreadable.

Then again, I learned BASIC first technically, so my brain probably isn't quite right :).

I don't really think it has much to do with you language path but rather with the field you are working most of the time.

People who are building Rails startups for sale will have opinion different from people who build some sort of integration systems.

I rediscovered imperative programming later and found it to be such a breath of fresh air.

DDJ had quite a few articles on how to do Lisp-in-C kind of thing.

Mainly, IME, because of the combination of JS map, etc., passing extra, infrequently used parameters, and functions you might want to use often accepting optional less-frequently-used parameters, which can end up interacting horribly wrong when you do:

  arr.map(func)

  arr.map(v => func(v))

The point is you can't implement Pattern, because it's a nightly feature. If you just make your own, that isn't Pattern and provides none of the benefits.

Yes, you can implement your own trait, and provide blanket implementations for it, but unlike Pattern yours is not part of the standard.

The nice thing about Pattern is that if Rust added say split_exactly_six_times() to the standard library that would take separator: Pattern too and so things which implement Pattern qualify, I can't see a way to get that benefit for my own traits.

I said nothing of using one package per function.

Yes, hence why it was able to call the Go functions directly during SSR, the results of which were bundled with the payload delivered to the client. gRPC played no role during initial render.

If the React app needed more information/updates as the user used the app then the function calls would transparently happen over gRPC instead.

Consider:

    const MyReactComponent = () => {
        const [things, setThings] = useState()
        useEffect(() => {
            // In-memory call to Go GetThings function during SSR render; gRPC call
            // to Go GetThings function when running in the client.
            GetThings().then(setThings)
        }, [])
        return <div>{things}</div>
    }

Build time injected into builds would absolutely break any reproducibility.