jatone

edit: for example one could envision the compiler generates the top n specializations per generic function based on usage and then uses the current stuff non-specialized version for the rest.

> with very few regressions, up until now.

the idea that this is a regression is silly. you can't have a regression unless old code is slower as a result. which is clearly not the case. its just a less than ideal outcome for generics. which will likely get resolved.

I can't imagine monomorphizing being that big of a deal during compilation if the generation is defered and results are cached.

you can hand wave 'possible alternative realities' all you want but the fact is they triggered those economic returns. spacex would be another (recent) example of a primarily NASA funded endeavor that will generate massive returns in the future and would not exist without said funding.

anyways good luck.

without the original research, the spinoffs may never occur because the initial capital outlay isn't warranted for the various individual uses.

the fact of the matter is fusion reactors are such a game changer ignoring them because of the chance they might not work is insane. meanwhile all the research into getting them to work generates a ton of economic activity because other smaller markets can take advantage of the technological progress that was made in the attempt.

outside of a few specific areas; like compilers but that's mainly because hardware is constantly evolving.

ok then nothing useful will be gleaned from this article. lol

magnetic confinement, lasers, material sciences have all advanced because of these projects and had impacts in other markets.

even if the money invested never ends up with an ITER reactor. we've still come out ahead economically.

this has been shown over and over to be incorrect. go programs are within the ballpark of other languages in terms of LOC. usually the examples given are niche use cases that impact an extremely small amount of code.

golang is looking for ways to make it more ergonomic just hasnt found a decent path forward yet. interestingly your sum types complaint might allow for it eventually.

> Go really likes forcing you to either write a ton of tests or discover your errors in production

this is just not true compared to most languages. evidence please. given the prevalence of dynamic languages in the wild today its most likely the opposite. i know my golang tests tend to be less in number than java or any dynamic language.

>Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect

also not true, golang absolutely gives you the ability to control this. but its guarded by rules. rules that prevent you from screwing up and causing memory issues. this is a good thing.

for the record it stopped working in go 1.15. 1.14 was the last version it worked in.

    var temp func(x) T = g
    if cond(x) {
       temp = f
    }
    err := h(temp(x))

    var names []string
    for i, user := range users {
        if user.isAdmin {
            names = append(names, user.Name)
       }
    }

my main issue with wasm is no standard interopt for primitive types. thankfully some sort of FFI is in the works from my understanding.

its the classic jargon speak problem most specialized fields have.

and some people will definitely move. but cities will only be getting better moving forward.