4 ms·

While I think most of the points raised are subjective, the overall theme does make sense to me. Of late my toolbox has become: Ruby - for problems that are pr

While I think most of the points raised are subjective, the overall theme does make sense to me. Of late my toolbox has become: Ruby - for problems that are programmer bound - regular web servers / APIs, CRUD. Go - for problems that are CPU / Memory bound - fast servers, proxies, APIs with lots of long I/O waits or high RPS requirements. Java - for problems that require modelling - logistics systems, data structures, algorithm heavy or design heavy problems JS/React - for UI

zengid 9y ago
Interesting distinctions. How do you get them to work together? Http and TCP/IP?
- inlined 9y ago
  When we migrated Parse from Ruby to Go, we started with two parallel efforts: 1. I built a Go implementation of resque. This let us swap any async process. Things that needed async tended to benefit from Go's speedup. 2. We also moved some internal APIs to Go in a sidecar server to help build up/validate core library implantations before replacing whole endpoints.
- sudhirj 9y ago
  Usually, yes. But the model lends itself to other options as well, like different micro services in different languages, or the user facing front end in Go and the back office / management systems in Rails.
tetha 9y ago
I've recently been asked about my choice of language to implement a new backend for some software. Imo, you want two languages + JS for the frontend if you do client-site frontend. You want a simple, expressive language, like python with django, or ruby with rails or sinatra. You want to implement most of your application in this language, because these languages allow programmers to be very, very productive. Put in a dumb way - 10 to 20 lines of ruby with modern libraries go a really long way without golfing. And if you notice you need performance and low latency, switch to your second language, java or go or something like that. This should be very little code, so you can throw all the really ugly optimizations at it to make it go fast. I've pushed some java services to sub-millisecond response times, but the things you gotta do with netty and lock-free data structures aren't suitable for a general audience anymore. And I guess, on top of that you need some kinda request routing, but that's simple to do with nginx/haproxy or some kind of DNS / service discovery provided by an orchestration system.
- aaron-lebo 9y ago
  In my experience python and Ruby and their ilk aren't actually that much better for programmer productivity anymore. They do have great libraries, but static languages have easily closed the productivity gap and have huge advantages in other areas, mainly that bugs are much easier to track down in properly typed languages and you gain productivity just from that. When I was a cowboy solo coder I'd never use anything but things like python, but having worked in teams, they have limitations.
  - kamaal 9y ago
    Plus given how much stagnation there has been in mainstream C based languages, most other languages have caught with library ecosystem big time. These days you get decent enough libraries even in lisp languages.
trey-jones 9y ago
> I think most of the points raised are subjective That was my take away. In fact many of the points made in the negative are actually positives for me : - capitalization - I actually think it's much easier to spot the public API with this convention - no exceptions - I get the concern about forgetting to handle and I think a compiler error for unhandled unhandled return values would be great. I also think golint probably handles this. Other issues can be solved easily with tooling (goimports). I admit, I love the language and I feel very productive working in it. Error handling has NEVER been more successful - that's my number one praise.
- __david__ 9y ago
  The problem with capitalization for me comes when interfacing with external json. Suddenly serializable structs have to be exported (since introspection doesn't work on private structs) which means that none of the names match the json names anymore (the web world tends to use lowercase or camel case with the first word uncapitalized). So now every json structure had to not only be public but also has to have introspection hints (`json: "my_field_name"`). It makes everything verbose and ugly. In these cases I'd much rather have "pub" in front of some lowercase names that match the json I'm reading or writing.
  - infogulch 9y ago
    I feel like changing the implementation of a core feature just to make json serialization a little easier would be the completely wrong thing to optimize for. 99% of go code is not json serialization structs. Are you going to name all your fields with underscores for the same reason? What if you're using the same struct with your database? Are you going all the way and name your database fields based on your json api naming conventions just so you don't have to write some metadata? I'll take writing tags, thanks.
    - __david__ 9y ago
      You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting with Go case conventions vs. the rest of the world. I like the concept of tags in principle, but in practice they end up being very repetitive. Compare it with Rust's "serde" stuff—it's much nicer.
sudhirj 9y ago
Should also note that the Java 8 Streams API and lambdas are a joy to use. I used to hate it 8 years ago, but the project I’m working on has a modeling heavy problem, and Java with the immutable data structures in Guava was a good match. Was just blown away by the language now. Still clunky, but there’s something to be said for a compiled language with great tooling, effortless refactoring and budding expressiveness.
- bunderbunder 9y ago
  It's a big step up, but man, I really wish Java would introduce extension methods. The streams API starts to get clunky if you need to add any functionality that they didn't think to include in the core implementation. (zip and mapi, for example.)
  - lokedhs 9y ago
    Have you considered Kotlin? It does address specific pain points of Java, such as extension methods. That said, I personally don't think Kotlin went nearly far enough, and some of their design decisions are questionable but if need to be in the Java ecosystem it's a nice choice.
    - bunderbunder 9y ago
      Kotlin's great, but that's a battle I'm just not willing to spend much social capital on. I'm also, let's face it, pretty jaded at this point. Lack of extension methods makes for code that's less clean-looking than I'd like it to be, but otherwise it's NBD. There are plenty of other language features that I straight up bang my head on that I'd like to see change first. Most of them are ones that affect Kotlin every bit as much as they affect Java.

zengid 9y ago

Interesting distinctions. How do you get them to work together? Http and TCP/IP?

inlined 9y ago
When we migrated Parse from Ruby to Go, we started with two parallel efforts: 1. I built a Go implementation of resque. This let us swap any async process. Things that needed async tended to benefit from Go's speedup. 2. We also moved some internal APIs to Go in a sidecar server to help build up/validate core library implantations before replacing whole endpoints.
sudhirj 9y ago
Usually, yes. But the model lends itself to other options as well, like different micro services in different languages, or the user facing front end in Go and the back office / management systems in Rails.

tetha 9y ago

I've recently been asked about my choice of language to implement a new backend for some software. Imo, you want two languages + JS for the frontend if you do client-site frontend. You want a simple, expressive language, like python with django, or ruby with rails or sinatra. You want to implement most of your application in this language, because these languages allow programmers to be very, very productive. Put in a dumb way - 10 to 20 lines of ruby with modern libraries go a really long way without golfing. And if you notice you need performance and low latency, switch to your second language, java or go or something like that. This should be very little code, so you can throw all the really ugly optimizations at it to make it go fast. I've pushed some java services to sub-millisecond response times, but the things you gotta do with netty and lock-free data structures aren't suitable for a general audience anymore. And I guess, on top of that you need some kinda request routing, but that's simple to do with nginx/haproxy or some kind of DNS / service discovery provided by an orchestration system.

aaron-lebo 9y ago
In my experience python and Ruby and their ilk aren't actually that much better for programmer productivity anymore. They do have great libraries, but static languages have easily closed the productivity gap and have huge advantages in other areas, mainly that bugs are much easier to track down in properly typed languages and you gain productivity just from that. When I was a cowboy solo coder I'd never use anything but things like python, but having worked in teams, they have limitations.
- kamaal 9y ago
  Plus given how much stagnation there has been in mainstream C based languages, most other languages have caught with library ecosystem big time. These days you get decent enough libraries even in lisp languages.

trey-jones 9y ago

> I think most of the points raised are subjective That was my take away. In fact many of the points made in the negative are actually positives for me : - capitalization - I actually think it's much easier to spot the public API with this convention - no exceptions - I get the concern about forgetting to handle and I think a compiler error for unhandled unhandled return values would be great. I also think golint probably handles this. Other issues can be solved easily with tooling (goimports). I admit, I love the language and I feel very productive working in it. Error handling has NEVER been more successful - that's my number one praise.

__david__ 9y ago
The problem with capitalization for me comes when interfacing with external json. Suddenly serializable structs have to be exported (since introspection doesn't work on private structs) which means that none of the names match the json names anymore (the web world tends to use lowercase or camel case with the first word uncapitalized). So now every json structure had to not only be public but also has to have introspection hints (`json: "my_field_name"`). It makes everything verbose and ugly. In these cases I'd much rather have "pub" in front of some lowercase names that match the json I'm reading or writing.
- infogulch 9y ago
  I feel like changing the implementation of a core feature just to make json serialization a little easier would be the completely wrong thing to optimize for. 99% of go code is not json serialization structs. Are you going to name all your fields with underscores for the same reason? What if you're using the same struct with your database? Are you going all the way and name your database fields based on your json api naming conventions just so you don't have to write some metadata? I'll take writing tags, thanks.
  - __david__ 9y ago
    You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting with Go case conventions vs. the rest of the world. I like the concept of tags in principle, but in practice they end up being very repetitive. Compare it with Rust's "serde" stuff—it's much nicer.

sudhirj 9y ago

Should also note that the Java 8 Streams API and lambdas are a joy to use. I used to hate it 8 years ago, but the project I’m working on has a modeling heavy problem, and Java with the immutable data structures in Guava was a good match. Was just blown away by the language now. Still clunky, but there’s something to be said for a compiled language with great tooling, effortless refactoring and budding expressiveness.

bunderbunder 9y ago
It's a big step up, but man, I really wish Java would introduce extension methods. The streams API starts to get clunky if you need to add any functionality that they didn't think to include in the core implementation. (zip and mapi, for example.)
- lokedhs 9y ago
  Have you considered Kotlin? It does address specific pain points of Java, such as extension methods. That said, I personally don't think Kotlin went nearly far enough, and some of their design decisions are questionable but if need to be in the Java ecosystem it's a nice choice.
  - bunderbunder 9y ago
    Kotlin's great, but that's a battle I'm just not willing to spend much social capital on. I'm also, let's face it, pretty jaded at this point. Lack of extension methods makes for code that's less clean-looking than I'd like it to be, but otherwise it's NBD. There are plenty of other language features that I straight up bang my head on that I'd like to see change first. Most of them are ones that affect Kotlin every bit as much as they affect Java.