"Weak type system" means that there are many restrictions on what constitutes a valid program that can't be expressed in Go, that can be expressed in languages with stronger type systems, like Rust, Haskell, or even Java and C#.
in my understanding, weak typing comes from values being interpreted differently or are silently converted based on how they are used. php taking strings with numeric values when used in a math operation is a form of weak typing.
if that is not what you mean then you are using a different definition for weak typing. that's ok, i don't want to argue about what is the right definition, but i am interested in the definition you are using.
I should have said that Go has a less expressive type system, i.e. the expressivity of its type system is weak.
It has no sum types, no algebraic data types, no real pattern matching, and limited generic constraints. And of course if we compare it to much more expressive type systems, which is a bit unfair because none of them are mainstream, it has no higher-kinded types, no dependent types, and no refinement types.
As for "true" weak typing, the idiomatic use of `any` (`interface{}`) in Go comes pretty close. While languages with more expressive type systems will often have some way to express that general concept, it's typically more constrained, more friendly to static checks, and less unsafe, because of the some of the other properties I mentioned, such as pattern matching where the compiler will warn you if you're not properly checking a value before unsafely accessing it.
The reason for my comment about Python and PHP is because to me, programming in Go feels little different in programming in those languages along with one of the bolted-on static checkers they have - you don't get anywhere close to the same level of static guarantee of correctness of programs. It's difficult to implement Yaron Minsky's adage "make invalid states unrepresentable" in Go's type system, and that's unfortunate.
...who invented this letter-casing convention?
import (
"embed"
"html/template"
"net/http"
)
//go:embed templates/*.html
var files embed.FS
var tmpl = template.Must(template.ParseFS(files, "templates/*.html"))
but the names of functions accessed via its namespace upper-cased?
how does this make sense?
lol
> if err != nil {
lmao
> defer rows.Close()
Oh dear
...
I'm only poking fun, I'll take a go backend any day over most of the alternatives. Same goes for CLI tools.
Maybe I develop games. Maybe I develop IoT devices. I might even be working in a high-stakes environment where formal verification is needed, who knows.
Whatever the case may be, we all have our reasons for choosing certain technologies. Not everyone is building run-of-the-mill 'backends' after all.
So please, let's stuff that neckbeardy arrogance away. It serves no purpose and distracts from the discussion.
Thanks.
P. s. I develop my backends in go.
For non-trivial golang apps you're still gonna find npm in the mix. I recently packaged forgejo, yopass, and a few others, and if you don't have `npm` on the build machine, the resulting daemon won't serve the front end.