121–130 of 144 posts
Go puzzles me. It's slower than C/C++/Rust and GCed, so not really suited for performance critical stuff. No OO so not really suited for larger complex applications. So for smaller not-performance-critical programs, why not Python, Typescript etc? It seems that its popularity exceeds its scope, or am I missing something?
Also, unless inheritance is what you mean by oop, it supports the other usecases of oop
Earlier quoted context omitted.
That link shows the Go type system's lack of expressiveness. You have to manually include things like the default case. Rust's compiler will do exhaustiveness checking for you, and you can't just forget about it. Also, it's not about ADT's being required. They're preferred, and Go's type system suffers for their lack. Go is a living, breathing example of the blub paradox in action.
> That link shows the Go type system's lack of expressiveness. And I ask again what that is supposed to mean in technical terms, and what specific problems would be prevented if Go's type system was "more expressive". > They're preferred I am fully aware that for every given language feature, there are people who prefer that feature. And many languages reacted to that by including everything and the kitchen sink. Tha…
Earlier quoted context omitted.
I'll bite. Why can't you compare it? Is it the class/function on struct thing? Generics? Go-routines not threads? Rob Pike did say once that the GC is deliberately not tunable because a JVM knob-twiddler should not be a job title.
Many reasons including: * Poor modeling ability (lack of default interface methods, no records, pattern matching, exhaustiveness checks, etc.). * Error handling is error prone. * Generics are half baked. * No short hand syntax for passing functions as lambdas. * No annotations. * Implicit interfaces make it hard to navigate large code bases because it is very easy to accidentally implement another interface. There ar…
Earlier quoted context omitted.
> Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that? > Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. At runtime. i.e. production. You think that is just as good as solving the problem at compile time? I certainly don't.
> At runtime. i.e. production. At runtime, i.e. initial testing, pre-commit-checks, integration-testing, QA and then production, yes. So there are a lot of checkpoints where the system can crash before it ever goes live. > You think that is just as good as solving the problem at compile time? No, I don't, and I never wrote that I do. I do think that it's a lot better than not crashing and running inti undefined behav…
Sure the language in its totality is more complex. At least compared to Go or C. But nothing is forcing you to use every feature of it.
> When you search "golang" on google for a long time, the question "Why people hate Go?" comes up at the top. What does this mean? Where do you see this? Also, I don't believe that question comes up verbatim, since it's not grammatically correct.
When you search reddit golang, the title continues to come first.
Earlier quoted context omitted.
> That link shows the Go type system's lack of expressiveness. And I ask again what that is supposed to mean in technical terms, and what specific problems would be prevented if Go's type system was "more expressive". > They're preferred I am fully aware that for every given language feature, there are people who prefer that feature. And many languages reacted to that by including everything and the kitchen sink. Tha…
What it means in technical terms is what I just told you: Rust's compiler will not let you forget to handle an enum variant. Go's compiler can't do that because the type system can't handle it.
Correct. And that isn't a disdvantage.
The fact that Go's type system "cannot handle that" directly in it's type system (functionally, the language itself can handle that easily enough, as shown by the article I linked above) is a choice, which results in a simpler language.
And I still haven't seen any specific problems that would be prevented if Go included this feature directly in the type system. I have, however, seen a lot of extra syntax that Go doesn't need to support in its compiler, Go students don't have to learn, and Go devs don't have to worry about.
Earlier quoted context omitted.
> At runtime. i.e. production. At runtime, i.e. initial testing, pre-commit-checks, integration-testing, QA and then production, yes. So there are a lot of checkpoints where the system can crash before it ever goes live. > You think that is just as good as solving the problem at compile time? No, I don't, and I never wrote that I do. I do think that it's a lot better than not crashing and running inti undefined behav…
The higher cost in developer time is a myth. Because the type checking seriously helps you out when you are changing existing code and it results in much fewer bugs out of the gate. Sure the language in its totality is more complex. At least compared to Go or C. But nothing is forcing you to use every feature of it.
And yet, Go is a huge success in the industry, and one of the main reasons often given for chosing Go over a competing language, is how easy it is to get things started, how easy it makes the onboarding process, and how accessible and maintainable the code is.
> the type checking seriously helps you out when you are changing existing code
If you have Algebraic Datatypes in your codebase, which is not a given. Having a simple, easy to read language helps me out ALL THE TIME.
> But nothing is forcing you to use every feature of it.
And nothing forces C developers to use so many macros that their libraries resemble a completely different language where everything I thought I learned about C flies out the window. Nothing forces Python devs to use nested dictionary-comprehensions, that are, ironically, completely incomprehensible. Nothing forces C++ developers to use generics everywhere, regardless of whether they are actually needed or not.
And yet, that is, unfortunately, what is often happening in the wild.
The point here is; If a language offers X, then X will be used. And it will be used in smart ways, it will be used in unnecessary ways, and it will be used in not-so-smart ways. It will be used when it makes sense, and when it absolutely doesn't.
The thing the developers of Go figured out, and which, in hindsight, is surprisingly obvious, is that there is exactly one, and only one, foolproof way to prevent that from happening: By not having X in the language.
Go puzzles me. It's slower than C/C++/Rust and GCed, so not really suited for performance critical stuff. No OO so not really suited for larger complex applications. So for smaller not-performance-critical programs, why not Python, Typescript etc? It seems that its popularity exceeds its scope, or am I missing something?
I can compile my go application down to a single, static binary that can run in a distroless container. The packaging/deployment simplicity of Golang appeals to me much more than Python, TypeScript, etc.
Also the developer tooling is first class and sustained backwards compatibility is top-notch. I can pretty much always upgrade the version of Go 1.x I target and have 0 worries in the world. Meanwhile in Python and JS land, the dependency management problems are a nightmare.