41–50 of 297 posts
Earlier quoted context omitted.
Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.
"Functional"? I suppose you meant "procedural" :)
"Why Go is not Haskell"
"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution. That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's…
Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems.
When you design a language, you have to be so careful of things you add. Because otherwise you get C++ (or one of those cute let's-add-all-the-features-we-can-think-of scripting languages). In good and in bad. You can't remove features afterwards, so better not add a feature you can't get right from the beginning.
This article has some good points but I'm going straight for the first one: I don't miss generics. Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go. Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much. I didn't miss them when I developed M…
This article has some good points but I'm going straight for the first one: I don't miss generics. Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go. Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much. I didn't miss them when I developed M…
"Why Go is not Haskell"
Author here. I think that is a very valid point. However, a lot of features I mentioned are present in other imperative languages, like Rust. The Go authors however picked other solutions I consider inferior, hence the article.
Earlier quoted context omitted.
> ... error verifications in Go ... you understand by reading your code the places where error can occur or where you decided to ignore errors (By using _) This compiles: package main import "errors" func main() { f() println("hello erroneous world") } func f() error { return errors.New("boo") }
Which you can catch with a linter like https://github.com/kisielk/errcheck . Errors in Go are just values. There's nothing "more wrong" about ignoring a return value that is an error or one that is file handle, for example. And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error. That's pretty g…
This compiles:
package main
import "errors"
func main() {
x, err := f()
if err != nil {
return
}
y, err := g()
h(x, y)
}
func f() (x int, err error) { return 1000, nil }
func g() (y int, err error) { err = errors.New("boo"); return }
func h(x, y int) { println(x/y) }
This article has some good points but I'm going straight for the first one: I don't miss generics. Indeed, they are useful. I use them in Java every time I find a good reason to do it. So, I should say in another way: I don't miss generics in Go. Given my experience [0] in Go in the last years, I realized that if you miss generics in Go, your code is trying to cope with too much. I didn't miss them when I developed M…
Did you miss it when you were working on larger codebases? The library you mentioned clocks at 500 LOC, and while the LOC metric is pretty inaccurate, it takes a lot more time to really miss language features.
For example, I recently wrote a compiler in Ocaml for a scripting language. The type I used for the syntax tree has lots of type parametsrs:
type ('id, 'str, 'enum) stmtf =
(* big ADT definition goes here... *)
These type parameters give me some flexibility. When the parser builds the first syntax tree everything is still a string:
type syntaxtree = (string, string, string) stmtf
type boundtree = (nameId, interpolation, string) stmtf
val map_sstmtf:
id: ('i1 -> 'i2) ->
str: ('s1 -> 's2) ->
enum: ('e1 -> 'e2) ->
('i1, 's1, 'e1) sstmtf ->
('i2, 's2, 'e2) sstmtf
Liberal use of type parameters also gave many other benefits. For example it was trivial to modify the tree to add a line number next to all identifiers, all I had to do was update the type definition and then see the compilation errors to find the parts of my code that had to be updated.
type syntaxtree = ((position * string), string, string) stmtf
One thing that is perhaps counter intuitive is how you do a lot of for loops compared to other languages (Compiled/Statically typed included). Once you let go your previous expectations, Go gets a lot nicer to use. The amount of for loops you will write will also makes it obvious when you start doing O(n^2) operations in your methods. Same can be said with variables declaration and error verifications in Go. They are…
Yeah, it seems like a lot of the criticisms of go boil down to "I don't like writing simple loops".