Nice thread. The comment about "full steam ahead with Rust" was nice.
Like you I've been on a basically identical search, but instead of coming up from Rust I've come down from dynamically typed languages on the backend. I just couldn't bear another run-time error that would have been easily prevented with Typescript.
I've come to the conclusion that the palette of ergonomic and statically typed languages for the backend is surprisingly quite sparse (when one includes the requirement of a relatively sizable community) if you don't include Java/Go.
Languages I personally crossed off:
* Java - Just much too verbose for my taste, too mutable, too nullable, and I don't find "Kingdom of Nouns" elegant to program in. (The JVM is quite magnificent though..)
* Golang - I get why people like it, and I have absolutely nothing against it. For me it's not expressive enough.
* Typescript - Pretty much 100% what you said. The language itself is wonderful, but it really shines when confined to the browser. The runtime differences between the Browser/Node cause all sorts of problems. Also compiled binaries are nice, which are out here.
I see why somebody might choose each of those languages, and be highly justified in doing so, but for me they didn't fit the bill.
That leaves:
* Scala - Only have very light experience. Really strong support for functional/immutable style programming, and checks all the boxes as another commenter pointed out. Community seems a bit complex at times. I haven't had time to really dive into it, but it's been on my mind.
* Rust - Seems like it nails a lot of things really well. Haven't ever touched it, so I can't give an educated appraisal of its merits. The only real obvious con is that it's "overkill" for systems dealing primarily with business logic, i.e. where GC isn't a big issue.
* Swift - Seems quite excellent, but I had written it off as unsuitable for general purpose stuff. Perhaps a premature take?
* Nim - The one on the list I have played around with the most. Seems to have a very powerful macro system which I have yet to take full advantage of. Feels like a statically-typed python, with a bent towards an imperative style over a more functional one. I am personally thrilled they went with the decision to make "func" a fist-class keyword, with special compiler significance. Still a bit niche however.
The technique that you have described on viewing the simple object combinations as "projections" is an excellent one; composability in your system emerges from efficiently selecting and combining these projections into the desired combination. At different points in your system you take just take different projections. Cross-cutting concerns are a breeze.
It actually all starts to feel like.... SQL! State is stored globally in a defined schema and queried as needed by the system.
But you can't do this if your compositions are preordained from on high by a rigid class hierarchy, the data is crystallized into the "blessed" projection and that's that. It's analogous to your SQL queries being constrained to solely static views. No JOIN. No GROUP BY. No WHERE.
Agreed, very interesting things going on in the "edge" space. I personally think this is why HN is so jazzed about things like fly.io. Super low latency opens up a whole new category of applications, it's a "step function" change in that regard.
Interestingly enough, assuming you use React this is how I see the role of something like Remix[0], which serves as a "rendering layer" that aggregates application data from different API's/stores and then sends a cachable HTML representation to the client which is thereafter hydrated.
It's not quite a backend and it's not quite a frontend, but it sort of sits in the middle and (hopefully) helps you achieve lower latency. I haven't used it myself but I think it's a promising idea and based on your post I gather a similar concept worked very well for you.
I haven't implemented this pattern (and I'm not convinced it is widespread or even exists in a cohesive form yet) but I've become quite bedazzled with the idea of "UI as pure function of state" a la React/Redux, but with state maintained in the backend database and transmitted to the client via websockets, instead of locally.
Assuming a real-time interactive application, the major components would look something like this:
- Backend service distributed geographically to facilitate low latency to clients, with a single writer node and many read replicas
- Backend data store is SQLite, and importantly runs as a process on the same VM as each of the service nodes, so that there is no need for any network roundtrip to query the database on a read operation
- Clients subscribe to the service and receive a single JSON object representing the UI state
- Database modifications trigger a websocket notification to all subscribed clients with the respective diffs to the state object
- On the client side, a library like React (my choice, but of course there are others) watches the state object and renders the UI accordingly. Client writes are routed to the writer node (Traditional caveats about RYOW apply), UI updates are optimistically applied
- Pure client side state (modals, etc.) is handled solely via the frontend
It's tangential to the architecture, but this obviously would be well suited for something like fly.io. I'm sure many of the Phoenix people are nodding their heads as this architecture bears a lot of resemblance to LiveView, which I am also interested in for its own merits.
I see this as essentially a marriage between React/Redux and LiveView; it essentially comes down to having a globally replicated SQLite DB serve as your Redux store, but "over the wire" and it's colocated with your API layer.
What's the motivation? For me, React/Redux with Redux Toolkit is pure bliss for any sort of UI development. Throw in Tailwindcss and you're really rockin'. The problems arise from the impedance mismatch between maintaining application state locally in a Redux store when the true source of truth is your DB, and all the network traffic/caching considerations/api logic that needs to come with that. (You've actually got a distributed system on your hands)
If you can keep the client focused on the UI, then the complexity mostly lives in the API service layer where writes are replicated to all the VMs. It wouldn't work for every style of app, but with a service like fly.io behind you this tradeoff starts to look very attractive.
(Aside: I think this is why a lot of HN'ers are so excited about fly.io. If I can distribute my application and achieve super low latency relatively simply that is a step-change and opens up so many avenues of experimentation for development)
If the application were a more traditional read-heavy website and didn't need real-time updates, I might rip out the websocket layer and replace it with something like Remix, which I see as sort of a "rendering layer" that sits between the client and the backend for React apps.
Anyway, it's an exciting time to be a web dev. I would be curious to hear if anyone else has pondered a setup like this.
Insightful comment. In general I prefer tools that have a prescribed way of looking at the world and don’t try to be everything to everyone. That said, I feel a certain allure to the depth and “wizardry” that I’ve heard so much about in Scala, which doesn’t generally fit this mold.
So at the moment I really think I’m stuck between Scala, Haskell, or Elixir.
It’s tempting for people to simply say, “Learn all of them” but for practical reasons that’s not possible at the moment. So thanks a lot for your comment.
Thanks a lot. The general hope of the question, was in that there may be people like me on HN who had a similar itch at around year 2-5 in their career.
In general, it's a low-risk decision, because it's only for personal enrichment. But time is precious at the moment and it would be quite a good bit of fun to hear from some people that simply ~love~ their language.
I know, I know.. questions like this can sometimes lack rigour and lead to a simple cheerleading fest, but I was hoping for a relatively lighthearted thread.
I am also convinced this is not an isolated feeling on my part, what I mean by that is, I'm sure this is a relatively common phenomenon among younger engineers who enjoy CS in and of itself, and I would be very interested in hearing what they have to say.
I haven't read enough about GraphQL (or even used it) to debate its relative merits, but I find it very interesting from "business architecture" point of view.
For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their respective needs.
GraphQL essentially allows you to simplify the work that any client (internal or external) needs to do to tap into your interface, provided that you invest the appropriate resources on the backend. (which you would, if that were your core business proposition and a piece of your competetive advantage)
If companies continue to digitalize (is there any doubt) then a company's value will be encompassed and driven by the quality of its API, and importantly, it's relative use of connecting with many diverse clients. Therefore backend API's that support and interface to digital products the best will win.
I see GraphQL supporting this in that it trades simplicity and a uniform mono-interface on the front-end for complexity on the backend. I think a lot of firms will look at that trade and call it a great deal.
Some interesting & fruitful replies in here. There is definitely some nuance that deserves to be unpacked. Yes, a well-oiled team with competent leadership and an effective culture can do more than an individual alone.
However the premise of their statement is that it used to be more feasible for one person to "do it all", whereas now things have transitioned towards a more team-oriented environment.
>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport.
I find actually the opposite to be true. The leverage of individual engineers is only growing with the advent of SaaS and the proliferation of API's. Then of course there are the stories of small engineering teams with Unicorn exits, e.g. Instagram, WhatsApp, etc.