41–50 of 367 posts
If the added complexity is "good" to you, then fine. In modern systems, simplicity is a powerful debugger.
Adding all those features that the author talks about -- "Constraint-based Generics and Parametric Polymorphism", "Algebraic Types and Type-safe Failure Modes", and "Pattern Matching and Compound Expressions" -- even if useful, would defeat the purpose of Go.
>If you want to modify a data structure, you have to create an entirely new data structure with the correct changes. This is still pretty fast because Haskell uses lazy evaluation.
I believe the issue is persistent data structures -- the new data structure "remembers" the old one (instead of recreating it) and records changes. (Clojure works like this as well) -- and not lazy evaluation.
For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…
>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. And what happens when you don't check? It crashes. That's the unsafe part. These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will…
This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.
In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…
I do agree with the author here: Go the language does nothing new. Go the platform, on the other hand, is a really pleasant new experience when compared with other languages.
The language is a regression in features compared to what other languages can do, but that is totally understandable when you look at what Go is aimed at.
The author is using a sharp blade as his implication for good : features that make a language more complex. If the added complexity is "good" to you, then fine. In modern systems, simplicity is a powerful debugger. Adding all those features that the author talks about -- "Constraint-based Generics and Parametric Polymorphism", "Algebraic Types and Type-safe Failure Modes", and "Pattern Matching and Compound Expressio…
For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…
> It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. I disagree: if the construction can fail, the constructor must return an error, which will be checked; only if the error is nil can the process continue. There shouldn't be logic on the actual data returned to assert whether a constructor worked or not.
http://play.golang.org/p/eqnDLVMHGA (pseudocode)
The author is using a sharp blade as his implication for good : features that make a language more complex. If the added complexity is "good" to you, then fine. In modern systems, simplicity is a powerful debugger. Adding all those features that the author talks about -- "Constraint-based Generics and Parametric Polymorphism", "Algebraic Types and Type-safe Failure Modes", and "Pattern Matching and Compound Expressio…
I don't consider the features I mentioned in this article to constitute "complexity".
I think that Haskell is a beautifully simple language, in the same way that e.g. Euler's identity is beautifully simple. The reasoning behind it may be somewhat complicated, but the result is very simple (and impressive) to behold.
But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken abstraction itself too. (Anyone who has ever seen a gcc compiler error for C++ knows how this feels.)
Therein lies Go's value proposition. It does not make it possible to make things pretty (ugh, nil). It just makes it impossible (ok, really hard) to overcomplicate things. When you write Go code, you can picture what the C equivalent would look like. You want to deal with errors? Here's an if statement. Data structures? Here's a struct. Generics? Here's another if statement, put it inside your for loop.
Obviously, Go is not the right choice of language for most things. When you're doing application development, you may be able to afford the cost of abstractions. But for tools that only need to do one thing and do it extremely well, it's either that or C. And I'm not going back to managing my own memory anytime soon.