As a love-hater of C++, Go did indeed feel like nothing new under the sun.
Why Go Is Not Good
171–180 of 367 posts
Re: Why Go Is Not Good
#172We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't. No, Go's solution to generics is not interface{}. The moment you say that, you have lost . You are trying to fight Go and make it a language that it is not. Always remarkable that such critiques always focus on t…
> No, Go's solution to generics is not interface{}. The moment you say that, you have lost. You are trying to fight Go and make it a language that it is not. What is the solution?
There isn't one. Go, by design, does not provide generics as they would complicate the language and for insufficient benefit. (according to at least one of the authors)
While I do agree that Generics can open up a whole new dimension of programming concerns. I think they are worth the additional syntactic complexity, because they allow you absolute accuracy when it comes to types. If we as a programming community want to ever get to the point where we have provably correct programs, or even reasonably correct programs, clear definitions of functions for an exact set of types is a necessity.
Re: Why Go Is Not Good
#173We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't. No, Go's solution to generics is not interface{}. The moment you say that, you have lost . You are trying to fight Go and make it a language that it is not. Always remarkable that such critiques always focus on t…
But the fact that Go proponents don't actually have solutions to those problems is an issue.
How do you make a custom, generic data structure without syntax overhead? I have not seen any counter proposal to this aside from "maps should be enough for everybody".
How do you avoid the noise from not having operator overloading or a similar alternative? This, again, goes unadressed.
What are the succint alternatives to functional abstractions for quickly processing collections of data?
"Just use a channel" doesn't really ring like a reasonable alternative to these questions.
Re: Why Go Is Not Good
#174Earlier quoted context omitted.
>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible. Uh, what? Haskell already compiles to native code, and is faster than Go in many cases. Also, if you were implementing a programming language, there are much better languages to do it in than Go.
Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)
Most of those seem to be things that could arguably be "implementing a language that compiles to Go and then leverages the Go compiler & runtime", which is pretty much orthogonal to "implementing a language in Go".
Re: Why Go Is Not Good
#175Earlier quoted context omitted.
I mean too complicated for writing, reading, and maintaining and generally just working with from day to day. It costs too much time to do the same thing.
Again, what specifically? I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.
Hundreds of thousands of lines of Rust? Out of curiosity, what kind of software are you writing in Rust?
...
And can I get in on some of that? ;-)
Re: Why Go Is Not Good
#176Earlier quoted context omitted.
>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awes…
Lack of generics is part of the reason why Go is easier to learn and the Go compiler is faster than, say, Rust. Sure, generics don't have runtime overhead in Rust and Haskell but they have other costs. You always pay for abstractions some way.
Last I checked compilation time wasn't really a thing a ton of folks worry about (myself included). Faster machines and reasonably better compilers have mostly solved this problem. I'd take zero-overhead generics over a slightly faster compiler any day of the week.
Re: Why Go Is Not Good
#177Earlier quoted context omitted.
I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.
You might want to google dereference null pointer code execution. Go regresses language design, because it allows constructs that have been proven to fail and are already fixed in other languages. This has nothing to do with shiny features of the newest language or whether language A or B is someone's favorite. This has to do with program correctness.
You might want to google pcwalton, just sayin'.
Re: Why Go Is Not Good
#178Earlier quoted context omitted.
> Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for. The blunt but approximately correct version is that embedded means that you're running on hardware that isn't powerful enough to run a Linux kernel. Systems programming just means you're working below the application layer. So if you take your laptop and write a devic…
Just curious : how does one run go without a linux kernel ? (without a kernel at all, please, I know about the freebsd port)
You'll probably be looking for a Go runtime that fills a kernel shaped hole. Without a kernel, where do all your syscalls go?
Re: Why Go Is Not Good
#179We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't. No, Go's solution to generics is not interface{}. The moment you say that, you have lost . You are trying to fight Go and make it a language that it is not. Always remarkable that such critiques always focus on t…
Since concurrency and composition are important, why doesn't Go have support for immutable variables and monitoring/linking ? These are features proven to make it easier to reason about concurrent systems and to manage failures in a distributed system. From what I can tell it is completely impossible to implement supervisors in Go.
Immutable values will complicate a type system and implementation. The Go creators are very strict about adding features to the language without enough justification, which is one of the biggest features of the language imo.
There are more synchronization features than channels in Go. Channels and switches solve most problems very well. However when another synchronization method is just simply required, check out: http://golang.org/pkg/sync/
Re: Why Go Is Not Good
#180Earlier quoted context omitted.
that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.
No, you are wrong. First, mapping that page doesn't cause all null pointer dereferences to segfault. And second, the language doesn't require a segfault. In fact, it explicitly permits the implementation to do whatever it likes. That is the difference between safe and unsafe. It is in the language definition.
"the language"... which one? AIUI, Go doesn't state that null dereferences are undefined behaviour, but rather that they are guaranteed to panic.