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
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.
I'll take writing tags, thanks.
I guess it's a difference of perspective: do you let the outside world's naming conventions leak into your codebase, or do you translate at the boundary? Go's field tags chooses to keep consistent naming internally and translate at the boundary, in exchange for defining that translation explicitly. Note, in some cases you will have conflicts no matter what you choose (e.g. serializing both json and database).
The outside world is going to be messy and inconsistent and full of conflicts. I would prefer to keep that external to my codebase as much as possible and follow a consistent naming convention within the language instead of letting the outside world and its whims dictate it.
You can use `#[serde(rename_all = "camelCase")]`[1] in the struct to apply the fix to all fields.
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.
When I was a cowboy solo coder I'd never use anything but things like python, but having worked in teams, they have limitations.
These days you get decent enough libraries even in lisp languages.
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.
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.
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.
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.