Ask HN: What's your ideal tech stack for 2019? | Hacker News Reader

Ask HN: What's your ideal tech stack for 2019?

12 pointsNightMKoder8 comments

There's never a one-size-fits-all solution, so I'm interested to learn of the concerns/experiences folks have!

I'm specifically interested in a consumer facing mobile/web app scenario. I'd love to hear how some of my requirements are excessive in other scenarios. That said, I have several priorities I'm thinking of:

Language:

- end-to-end testing. Not selenium. As close to the edges as possible.

- a large standard library/blessed common libraries. I don't really want to implement `sort` or `groupBy` outside of whiteboarding interviews. That said `tree-seq` (Clojure's depth-first tree traversal as an iterator, part of `clojure.core` - no extra imports) is not strictly required.

- decent concurrency support. Parallelism would be even better, but that's severe limiting factor AFAICT.

- REPL support. Mostly so I can cache things on successive test runs :P.

- It'd be awesome if I didn't have to reimplement everything between serving & ETL. e.g. Imagine ETLing your permission system outputs.

Platform (i.e. serving infrastructure): - Off-hands DB/data data management (e.g. AWS RDS/GCloud SQL/Spanner/etc).

- Off-hands traffic management - i.e. DNS/load balancing.

- Automated, rolling deploys

- Single command rollback

- Easy logging (i.e. stderr) & aggregation.

Data-Platform: - Record everything, forever. Not to say that the business should do that (i.e. user privacy matters), but starting here makes debugging easier.

- I have no desire to manage a spark/HDFS cluster.

- Testability would be awesome.

It depends, if it's just you and you want to get to market quickly building your web app and backend in Rails backed by postgres and redis is still a solid choice. Put your code in docker and have AWS' ECS Fargate manage it, do the same for your DB(Aurora) and cache(Elasticache). I can't speak for mobile devs, but it sounds like a lot of the hype around react native and whatnot has died down.

A bigger org I'd probably just change the backend code to Go and start taking advantages of other AWS products to manage ETL/monitoring/logging/etc. The change to Go is mostly just to prevent your more 'clever' engineers from producing code that no one but them can understand. Languages like Clojure and Scala while cool can start causing real problems in an org where the experience level isn't uniform.

A note on tech that bears repeating, if it isn't going to be your differentiator then choose boring building blocks.

One that lets me start quick projects/MVPs without too much boilerplate or having to think of the general architecture.

I've recently finished a project using Meteor, and I quite liked the opinionated views it has on things (less initial choices to focus on the product rather than the underlying tech).

But if I had to pick some techs I'd want to play with in such a stack, I'd go for Rust (Rocket), Postgres, GraphQL and React.

That’s an interesting point - I haven’t been thinking about quick stuff. If honestly just do something without a server side if that’s an option? E.g. just use coredata on iOS.

Interesting choice of Rust - why that over Scala or Haskell?

I've learned programming with C/C++ so I've always been comfortable playing close to the metal, and Rust ticks a lot of boxes in providing the same low-level strongly typed experience, with a ton of added bonuses: very useful compiler, memory safety, an actual ecosystem of packages that lets one focus on the product and not the build system..

At my previous company, a lot of engineering time was dedicated to maintaining the custom C++ build system, I'm glad to see "newer" languages formalizing this step: "make it opinionated by default so developers can get quickly up and running, but allow hooks into the system for later, when they have specific needs", rather than the JS approach of "batteries not included, nor screws or assembly manual, but hey you can build whatever you want !", which leads to decision fatigue at the most critical time of an idea's inception.

That being said, to answer your actual question: I haven't looked closely into them, but functional programming is still a bit arcane for my OOP-trained mind, it will take a bit of practice to think differently.

FE/BE: Elixir/Phoenix which includes Brunch instead of Webpack/gulp. Also, yarn over npm where possible.

BE: Go, Erlang/Elixir, Pony, Crystal, Rust... take your pick. REPLs in compiled languages usually have to be faked but are still useful for experimentation. Get used to a good debugger like gdb or lldb, with a convenience layer like Voltron, and profiling tools: dtrace, gperf, valgrind.

BE svcs: EnvoyProxy, Nginx highly-customized, Redis, Postgres, CentOS containerized with Chef, Docker and Habitat... and no Kubernetes. If you have bare metal, OpenStack, pfSense/OpenBSD/NetBSD at the edge, KVM (VMware if you can afford it) and BeeGFS over Ceph. Backup mission-critical data with Tarsnap, others with a mix of S3, Glacier and BackBlaze.

Try to standardize on what works best for the use-case to reduce complexity, iteration time and cost. Develop on what's used in production and follow Twelve Factors methodology generally.

Scala + Scala.js allow for code reuse between server and client

Postgres for db

Azure for hosting

I tried to get into Scala a little while ago, but I couldn’t quite grok the language - there was a time where I wanted to pull out a nested function call (e.g. f(g(x))) into a variable and it gave me compile errors (there might have been implicit a involved; I just backed away slowly). Something about that just completely put me off from the language. Maybe it’s worth another go. Have they done any kind of syntax cull since 2-3 years ago?

I’m curious about the choice of Azure. Why that over AWS/GCP?

They have not culled syntax and its a big language but very much worth learning from basics. Pick a good book first before jumping in (if you didn't already). If you did, which one?

About azure- I could ask the same q otherwise :). Remember HN is an echo chamber.

Reply on news.ycombinator.com