4 ms·

IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1].

by takeda 10y ago

IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1]. Yes, it is simple, and you can learn it fast, you also can also communicate with it, but you will often have to fight with the language to express what you want. That person generally won't be satisfied. Go's shortcomings wouldn't be so bad if in exchange, the language would ensure that your code is less prone to errors, but that doesn't seem to be true. In fact Go programs from my experience appear to be slightly below average in terms of stability and robustness compared to other statically typed languages. [1] https://en.wikipedia.org/wiki/Toki_Pona https://en.wikipedia.org/wiki/Toki_Pona

yanilkr 10y ago
Your opinion on this is couple of standard deviations away from popular one. Is there a specific example where a program written in golang lacked compared to other statically typed languages?
- takeda 10y ago
  Well, it's small sample but I used things like InfluxDB, Consul, there were some command line tools (that I no longer remember) as well.
weberc2 10y ago
Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.
- takeda 10y ago
  I don't think you understood my analogy. Go supposed to be Toki Pona. I'm saying that once you are used to a language that's more powerful you feel constrained. I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases. BTW: The Go is not subset of Java if anything it's very similar to Algol-68 (http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/)
  - weberc2 10y ago
    > I'm saying that once you are used to a language that's more powerful you feel constrained. I did misunderstand your point, though I don't find this one more compelling. While Java has more features than Go, the only one I would consider to be "more powerful" would be generics. > The concurrency supposed to be the killer feature, but it is limited to specific cases. How do you figure? To which specific cases is it limited? How is Java better? > BTW: The Go is not subset of Java if anything it's very similar to Algol-68 My argument wasn't that Go is most similar to Java; only that Go's featureset is almost a strict subset of Java's. Go gives you tighter control over memory and a better concurrency story, but most of the rest of it looks the same.

by takeda 10y ago

yanilkr 10y ago

Your opinion on this is couple of standard deviations away from popular one. Is there a specific example where a program written in golang lacked compared to other statically typed languages?

takeda 10y ago
Well, it's small sample but I used things like InfluxDB, Consul, there were some command line tools (that I no longer remember) as well.

weberc2 10y ago

Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.

takeda 10y ago
I don't think you understood my analogy. Go supposed to be Toki Pona. I'm saying that once you are used to a language that's more powerful you feel constrained. I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases. BTW: The Go is not subset of Java if anything it's very similar to Algol-68 (http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/)
- weberc2 10y ago
  > I'm saying that once you are used to a language that's more powerful you feel constrained. I did misunderstand your point, though I don't find this one more compelling. While Java has more features than Go, the only one I would consider to be "more powerful" would be generics. > The concurrency supposed to be the killer feature, but it is limited to specific cases. How do you figure? To which specific cases is it limited? How is Java better? > BTW: The Go is not subset of Java if anything it's very similar to Algol-68 My argument wasn't that Go is most similar to Java; only that Go's featureset is almost a strict subset of Java's. Go gives you tighter control over memory and a better concurrency story, but most of the rest of it looks the same.