5 ms·

I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-l

I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-like verbosity. Meh, I can deal with it. []byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal. Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go, there was a bunch of extra stuff that just seemed like noise. Likewise for cypto, Base64, stringwriters, bunch of other stuff. A bunch of little annoying stuff like that adds up. Eventually I just said fuck it. Maybe I'm not hardcore enough or something, but now I'm back with LuaJIT. Goroutines are cool, tho. Lua's synchronous threads aren't quite the same. Also google's app engine datastore is sweet. Nice and simple, no screwing around with SQL. If I had to do systems stuff, I'd reach for Go. LuaJIT is faster anyways.

encoderer 14y ago
> LuaJIT is faster anyways. This man speaks the truth. Well, actually, I know nothing about Lua. But I do know that Go currently isn't very fast. I mean, compared to highly dynamic languages the performance is fine. But compared to C++ or even modern JVM it's meh. I feel like there's going to be improvement here, though, and I wouldn't be surprised if the versions of golang used internally at Google aren't faster. My take has been to use it the way I imagine Google does. If I'm not building something that uses protobuffs and goroutines I do it in Python.
- kristianp 14y ago
  When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I think if you are doing a lot of memory allocation, then the garbage collection may slow you down, but I wouldn't be suprised if it's still faster than a jitted language like LuaJIT.
  - batista 14y ago
    >When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I've tried in in 2-3 things which I re-implemented afterwards in C and had before in Python. In all cases it has about 2x the speed of Python, which I consider meh. (The tasks where mostly parsing some huge files and doing some filtering and computations, and C made it IO bound while Python/Go both had it CPU bound).
  - encoderer 14y ago
    My largest Golang deployment is a blender service. That's where I used the Goroutines and protocol buffers I mentioned earlier. Its speed is acceptable. My take on it is that this is a new language. Of course it doesn't have fully mature, fully optimized internals. And certainly part of the problem is that I haven't developed a full mastery of the language (Mastery is not a word i use lightly) so that will improve, too. But if your experience is that you've built multi-threaded apps in Go that perform comparable to a c++ implementation then I'd love to know if you have any specific tips and also I suppose that means that we're not going to see any broad improvements in runtime performance?
    - lobster_johnson 14y ago
      I recommend trying gccgo, the Go compiler for the GCC suite. (GCC 4.7.1 and later have Go built in.) In my experience it is (at -O2) much faster than Go's own compiler. GCC, after all, has because a bunch of advanced optimizers with a long history of development behind them, and Go's own compiler does not. My recolleciton is that Go's own compiler was intended as a "suboptimal but correct" reference compiler, but this may have changed.
      - encoderer 14y ago
        Appreciate the tip -- sincerely.
kleiba 14y ago
* []byte and string aren't the same. ...and how could they be?
- arnsholt 14y ago
  Despite Unicode being something like 20 years old, people still expect strings to be byte arrays and other assorted lunacy, like reading from file not requiring stuff like encodings. "How hard can it be" to just figure out which encoding the file has, after all...
- EdiX 14y ago
  BTW in go a string can be cast to []byte like this: []byte(aString) it returns the utf-8 bytes, casting to []rune gives unicode codepoints.
dsymonds 14y ago
This is the first time I've heard "Java-like verbosity" as a criticism of Go, and I'm baffled by it. Go is generally much more succinct than C++, Java and other similar statically typed languages. Can you expand on your comment?
- nyan_sandwich 14y ago
  everything is package prefixed, names are long. Totally minor, but reminded me of my days with java
  - dsymonds 14y ago
    I guess you could call that "verbosity", but it's very different from what people normally think of when you refer to "Java" and "verbose".
buu700 14y ago
In Lua, markdown (discount) is a single function https://github.com/buu700/upskirt.go https://github.com/buu700/upskirt.go
masklinn 14y ago
> []byte and string aren't the same. Nor should it be. I've got plenty of issues with Go, but that most definitely isn't one. It's one of the few things Java got completely right (even though they fucked the String type itself): strings are not bytes.

encoderer 14y ago

> LuaJIT is faster anyways. This man speaks the truth. Well, actually, I know nothing about Lua. But I do know that Go currently isn't very fast. I mean, compared to highly dynamic languages the performance is fine. But compared to C++ or even modern JVM it's meh. I feel like there's going to be improvement here, though, and I wouldn't be surprised if the versions of golang used internally at Google aren't faster. My take has been to use it the way I imagine Google does. If I'm not building something that uses protobuffs and goroutines I do it in Python.

kristianp 14y ago
When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I think if you are doing a lot of memory allocation, then the garbage collection may slow you down, but I wouldn't be suprised if it's still faster than a jitted language like LuaJIT.
- batista 14y ago
  >When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I've tried in in 2-3 things which I re-implemented afterwards in C and had before in Python. In all cases it has about 2x the speed of Python, which I consider meh. (The tasks where mostly parsing some huge files and doing some filtering and computations, and C made it IO bound while Python/Go both had it CPU bound).
- encoderer 14y ago
  My largest Golang deployment is a blender service. That's where I used the Goroutines and protocol buffers I mentioned earlier. Its speed is acceptable. My take on it is that this is a new language. Of course it doesn't have fully mature, fully optimized internals. And certainly part of the problem is that I haven't developed a full mastery of the language (Mastery is not a word i use lightly) so that will improve, too. But if your experience is that you've built multi-threaded apps in Go that perform comparable to a c++ implementation then I'd love to know if you have any specific tips and also I suppose that means that we're not going to see any broad improvements in runtime performance?
  - lobster_johnson 14y ago
    I recommend trying gccgo, the Go compiler for the GCC suite. (GCC 4.7.1 and later have Go built in.) In my experience it is (at -O2) much faster than Go's own compiler. GCC, after all, has because a bunch of advanced optimizers with a long history of development behind them, and Go's own compiler does not. My recolleciton is that Go's own compiler was intended as a "suboptimal but correct" reference compiler, but this may have changed.
    - encoderer 14y ago
      Appreciate the tip -- sincerely.

kleiba 14y ago

* []byte and string aren't the same. ...and how could they be?

arnsholt 14y ago
Despite Unicode being something like 20 years old, people still expect strings to be byte arrays and other assorted lunacy, like reading from file not requiring stuff like encodings. "How hard can it be" to just figure out which encoding the file has, after all...
EdiX 14y ago
BTW in go a string can be cast to []byte like this: []byte(aString) it returns the utf-8 bytes, casting to []rune gives unicode codepoints.

dsymonds 14y ago

This is the first time I've heard "Java-like verbosity" as a criticism of Go, and I'm baffled by it. Go is generally much more succinct than C++, Java and other similar statically typed languages. Can you expand on your comment?

nyan_sandwich 14y ago
everything is package prefixed, names are long. Totally minor, but reminded me of my days with java
- dsymonds 14y ago
  I guess you could call that "verbosity", but it's very different from what people normally think of when you refer to "Java" and "verbose".

buu700 14y ago

In Lua, markdown (discount) is a single function https://github.com/buu700/upskirt.go https://github.com/buu700/upskirt.go

masklinn 14y ago

> []byte and string aren't the same. Nor should it be. I've got plenty of issues with Go, but that most definitely isn't one. It's one of the few things Java got completely right (even though they fucked the String type itself): strings are not bytes.