5 ms·

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

by jwdunne 10y ago

pryelluw 10y ago
Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.
- jwdunne 10y ago
  Have you got a few examples where you had to replace the former for the latter? Really interesting.
  - pryelluw 10y ago
    Sure. Last one was a static asset server that had to perform or the users would notice a delay. Built one in Go in about a week and put it behind nginx on a vps. It was faster than required, stand alone, and used very little memory. Its still running to this day.
pjmlp 10y ago
What is interesting is leaving the expressiveness behind of a language like Ruby or Python, for a bit of AOT compilation to native code. I bet if something like RubyMotion wasn't a commercial product, the reality would be quite different.
- alehander42 10y ago
  Crystal and Nim can be good alternatives, no type system sucks anyway
  - pjmlp 10y ago
    I agree, but they lack the Google stamp, which is one reason for Go's adoption.
fleurdelotus 10y ago
I've read a lot of Go users come from the Ruby and Python communities Don't believe what you read, especially when it originates from a biased source. When i want productivity, i use python. When i want speed, i use c. When i want both, i use both.
- jwdunne 10y ago
  So it isn't the case many Go users come from the Ruby and Python communities?
- tejasmanohar 10y ago
  I'm more confident with static typing... also easier to refactor. Go's more productive for me after a cut-off. I still love using Python for quick scripts.
taway_1212 10y ago
As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking frameworks expect to mock classes, so every bit of functionality needs to be it's own separate class, just like in Java...
- pjmlp 10y ago
  If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE.
  - geodel 10y ago
    SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.
    - pjmlp 10y ago
      > The no-GUI and no-framework Go is not helping Java style solutions. Just wait and it will come, it only needs a bit of enterprise architecture caretakers. JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.
      - geodel 10y ago
        I have no problem with JavaEE and I have used it many times. Though JavaEE developers/architects like Java EE solutions generates 10-20 times scaffolding in meetings before getting to the point.
- jwdunne 10y ago
  Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?
tootie 10y ago
It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.
- deleted 10y ago
  [deleted]
- jaegerpicker 10y ago
  If you hate yourself sure, Java is one of the worst working environments for a tech stack I've ever worked in. I've worked in a ton of others.
  - pjmlp 10y ago
    I am yet to use a development environment that matches Java and .NET in terms of tooling, including libraries, IDEs, GUI toolkits, profilers , application servers, integration with legacy systems, network monitoring of clustered applications,...

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

by jwdunne 10y ago

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

pryelluw 10y ago

Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.

jwdunne 10y ago
Have you got a few examples where you had to replace the former for the latter? Really interesting.
- pryelluw 10y ago
  Sure. Last one was a static asset server that had to perform or the users would notice a delay. Built one in Go in about a week and put it behind nginx on a vps. It was faster than required, stand alone, and used very little memory. Its still running to this day.

pjmlp 10y ago

What is interesting is leaving the expressiveness behind of a language like Ruby or Python, for a bit of AOT compilation to native code. I bet if something like RubyMotion wasn't a commercial product, the reality would be quite different.

alehander42 10y ago
Crystal and Nim can be good alternatives, no type system sucks anyway
- pjmlp 10y ago
  I agree, but they lack the Google stamp, which is one reason for Go's adoption.

fleurdelotus 10y ago

I've read a lot of Go users come from the Ruby and Python communities Don't believe what you read, especially when it originates from a biased source. When i want productivity, i use python. When i want speed, i use c. When i want both, i use both.

jwdunne 10y ago
So it isn't the case many Go users come from the Ruby and Python communities?
tejasmanohar 10y ago
I'm more confident with static typing... also easier to refactor. Go's more productive for me after a cut-off. I still love using Python for quick scripts.

taway_1212 10y ago

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking frameworks expect to mock classes, so every bit of functionality needs to be it's own separate class, just like in Java...

pjmlp 10y ago
If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE.
- geodel 10y ago
  SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.
  - pjmlp 10y ago
    > The no-GUI and no-framework Go is not helping Java style solutions. Just wait and it will come, it only needs a bit of enterprise architecture caretakers. JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.
    - geodel 10y ago
      I have no problem with JavaEE and I have used it many times. Though JavaEE developers/architects like Java EE solutions generates 10-20 times scaffolding in meetings before getting to the point.
jwdunne 10y ago
Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?

tootie 10y ago

It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.

deleted 10y ago
[deleted]
jaegerpicker 10y ago
If you hate yourself sure, Java is one of the worst working environments for a tech stack I've ever worked in. I've worked in a ton of others.
- pjmlp 10y ago
  I am yet to use a development environment that matches Java and .NET in terms of tooling, including libraries, IDEs, GUI toolkits, profilers , application servers, integration with legacy systems, network monitoring of clustered applications,...