demi56

> Sorry, but no - putting the burden on the developer to detect whether they are running in a container or not and then determine and adjust to cgroup settings is far too high an encumbrance on the service developer.

Because there’s no one way solution to this problem, the problem isn’t unique to only Go, but every GC language because you’re starving the program if there isn’t sufficient CPU Quota it will all eventually lead to CPU throttling, this isn’t really the problem of Go or any other GC language but at the OS layer, the inherent nature of containers

Secondly am pretty sure the Linux CFS does not strictly follow the CPU Quota, tho there could be something like a panic or warning, or switching to entirely different memory management just for what ? people who want 10ms ?

> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"

Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles

> You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.

I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue

> Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...

We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19

> As an example, the Go runtime does not honor container resource limits

That’s no longer true for Go 1.19+

I would say the leaders(could be the creators) of the language plays the most important role in its infancy the decisions they make defines what decisions the community are gonna make and the was what Go made right, Java been a business oriented decisions made by the community will also be business oriented

But you see nobody really wants to be “different” if there are 100 people and the first 90 went right the probability of the remaining 10 going right will be higher. Java was designed to be business oriented and I think this is why Go and Java is very different not in terms of language but the way the community makes decisions

So the community influences the language, not the language that influence the community that explains everything

Yeah, some dev usually don’t put safe guards especially when the user input is directly linked to file operations

Oh, the community is the reflection on how the language is being maintained

Does shell scripting really need to go hand in hand with the language flexibility ?

Systems Programming is kinda generic category and it ultimately depends on the individual to define what’s system programming and what’s not, is it performance, security or access to hardware

Nobody enjoys writing Go but there’s a reason do code in Go and we can’t ignore it

Basically the type system, most rust projects usually don’t come near “The advanced Reason there’s rust” and if they do need that there’re hardcore libraries for that, an ecosystem like that usually suffers from exhaustion cause no dev will want to maintain just a library and this is also the good apart of rust cause it lessens the barrier into the language as the ecosystem gets bigger

You can’t just compare a library from another language, because they’re different, if all flag parsing library were inspired by Clap it’ll be a living nightmare for language that isn’t rust

You don’t have to worry people have been saying this for more than a decade now and I see no action about it

Not gonna lie am also getting 200% triggered whenever he states gVisor Syscall costs lol

From my experience the reason $GOPATH has pkg, bin src directory was they wanted to limit spread of affecting the filesystem, I could zip my go directory put it in another computer and still works as good as before, I hated Python because it couldn’t do this even pyenv have high chances of it not working correctly if changed to a different distro and most times I don’t wanna download 500M of anaconda everytime I swap.

> and b) configured using a YAML-based DSL.

Go devops HATE YAML-based DSL we just put it there cause there’s not alternatives, json ?, don’t wanna go there fortunately there’s CUE lang but moving all these project to accept cue isn’t that easy either.

> Devops guys are mostly incapable of using any service that isn't a) written in Go

Lol we basically rewrite it in Go if we’re using it frequently. Most Go projects are just things the founder really wanted for himself

Damn that’s a comeback that’s not complicated

Dude you tried, there’s no need for 50000 word essay against a sentence

Dude if the 70% don’t care they don’t care besides it’s open source

> The huge volume of boilerplate makes the code harder to read, and annoying to write

That may be superficially true but don’t forget our brain is structured to optimize every repetitive work or some boilerplates, we can basically use “strcpy” and “string_copy” we are so used to all these that even if repeated a billion times it can be processed fast

Sooo what’s the new 2025 way?

You’re just complaining because the compiler isn’t complaining

> I have nothing against Go, it's a tool that does its job fairly well and has very interesting qualities (fast compile time, self-contained binaries, decent performance out of the box), but the religious worship of “simplicity” is really annoying.

Typical Gate keeping the gate keepers of simplicity and pretty sure you code 23.5 hours a day on Haskell

As a language that’s focused on backward compatibility than features oriented this is the best and optimal way to reduce some of Go’s loopholes. The problem of using developer tooling to solve the innate problems is that they lack awareness

I do recommend the Go team to find a way to these tools to run before it complies, just doing go build while going through these tools first goes a long way than just using scripts

Basically proves his point, I hate JavaScript but am pretty sure my children is gonna write some code in JavaScript

What makes you think that Google has active authority over Go development?,

Or you could use a 3rd party error package that’s not a good excuse because the standard don’t have it as a priority

Let python be python, let Go be Go, let Rust be Rust it has never worked well for any language trying to be like another language

Blame that to glibc not the container