131–140 of 384 posts
I'd love to see Nim on this diagram: https://talks.golang.org/2016/applicative.slide#13 - it could be close to the top right corner.
The go devs are very careful to avoid mention of all the other languages that compete in the same space and are significantly better.
All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good…
Slide 13 ( https://talks.golang.org/2016/applicative.slide#13 ) is interesting. I was expecting Go to be very close to C/C++ on the X axis (fast/efficient) as it doesn't use VM, but it is more close to Java ?
All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good…
Are you sure? Google offers 2 Google Cloud APIs for Go:
- Google API Client Library for Go, which is auto-generated like you wrote;
- Google Cloud Platform Client Library for Go, which is intended to be idiomatically-designed.
Earlier quoted context omitted.
Definitely, but isn't Crystal still in its early stages? I heard it doesn't even have Windows support yet for example.
Yes, you're right that it is in an early stage of development and doesn't yet support Windows (to be fair, even Rust added full Windows support fairly late in their development cycle to 1.0). Crystal is probably in a slightly earlier stage than Nim, though not by much. Both are very interesting languages that I think would plot in similar locations on the chart. D is also a lot of fun. I think all are competing in th…
Earlier quoted context omitted.
Slide 13 ( https://talks.golang.org/2016/applicative.slide#13 ) is interesting. I was expecting Go to be very close to C/C++ on the X axis (fast/efficient) as it doesn't use VM, but it is more close to Java ?
It's true that Go compiles down to an executable and doesn't run on a VM like Java, but it does have it own runtime compiled into it, which manages the GC and goroutine scheduler to name two, so there is definitely some more overhead to Go then just straight C/C++
What are some cases where I would choose to write a server in Go instead of in Erlang?
First thing on duckduckgo when you search for how to write a server in erlang: http://20bits.com/article/erlang-a-generic-server-tutorial That's just ridiculous. Erlang looks like php and python had an unholy child.
I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways…
Bad programmers are always going to be bad programmers, no matter what their age. Bad programmers are inflexible and unadaptable; unable to keep up with new languages or idioms. Ken Thompson is about as old school as they come and he wrote much of Go.
All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good…
> Dependency management is a nightmare Is it that bad now in 1.6 with vendor support? And a tool like `govendor` makes it easy to stick things inside of vendor. > it just really surprises me how little Google seems to care about the language and ecosystem To be blunt, google's priority is google, not the open source community or other companies using golang. Dependency management wasn't a priority because of mono rep…
All of the server backends at my company are written in Go. This was a result of me writing a couple servers in Python a few years back, ending up with lots of problems related to hanging connections, timeouts, etc. I tried a couple different server libraries on Python but they all seemed to struggle with even tiny loads. Not sure what was up with that, but ultimately I gave Go a swing, having heard that it was good…
We've been running splice.com on Go for 3 years now and handle 5TB of audio/binary data per day. Our memory usage is around 10-15MB per server and the GC pause time has been really low. You do need to stream your IOs instead of reading everything in memory. In regards to dependency management, we honestly had no issues and now with vendoring, it's even easier. We do use a main repo with lots of smaller packages and o…
Nice business model.