Given the complex services we already have, services that access complex, multi-source databases of the relational and NoSQL kind, I find it amusing that UI developers are so unaware of the complexities of the back end--complexities that are normally hidden from them--that they think they can be reduced to so many calls. WebSockets don't magically assemble complex back-end data. Amusing in the extreme.
Ask HN: What is the future of back-end development?
121–130 of 164 posts
Re: Ask HN: What is the future of back-end development?
#122Earlier quoted context omitted.
This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that…
Consider the problems that both Lambda and Containers/PaaS solve for you: ignoring infrastructure. It's there, sure, but I don't care much about it. Now take that idea to the absolute extreme. I write code, I push it into the cloudy-cloud machine, and it's serving clients immediately.
Re: Ask HN: What is the future of back-end development?
#123I think the future of back-end development is heavily decided by the future programming language. I think we are still missing a programming language that is safe, fast and productive. Safe meaning type safe and memory safe(Also memory leak safe), Fast meaning near zero abstraction costs, and productive meaning productive syntax and good tooling support. And it has to be built on modern compiler architecture, which m…
Re: Ask HN: What is the future of back-end development?
#124Earlier quoted context omitted.
You're still paying only a few cents.
If you could host via s3, why not use GitHub.io and do it for free?
Re: Ask HN: What is the future of back-end development?
#125When large code bases will have sane(!) static typing and functional programming principles. And no, slamming types onto Python won't help much.
Re: Ask HN: What is the future of back-end development?
#126My guess is that future of back-end is using tighter languages like C++ and rust. Why? Because energy will become more expensive and we will require fewer machines to operate the application. These apps will run on single purpose kernels like exokernels and unikernels where the OS and app are married like in the "good old days"
Re: Ask HN: What is the future of back-end development?
#127Earlier quoted context omitted.
Depends on where you work. If you're a three-nan start up, you don't have an infrastructure or ops team. You do everything. As well, companies who have dedicated infrastructure teams are wasting money when we reach a world where that problem is purely automated. And that's where I think we're going.
Sure, sometimes you cant have it all, but in my experience (and hey, I am aware that I'm biased here!) I've seen ops engineers being better at programming than developers at doing ops. Another reason why I'd prefer to have 2 devels and 1 ops person is that that single ops person can bring to the table entirely different experience and point of view and that's a pure added value here. If you think that infra teams is…
One team has 2 devs and an op guy
One team has 3 devs, one of which knows enough ops to ship code
One team has 1 dev, 1 MBA, and 1 QA
One team has 1 MBA, 1 QA, 1 Marketing guy
I pick the 3 dev team, and hope each of them can fill in some of the other roles on the side (ops, marketing, qa).
Not everyone would pick the dev team, but I would.
Re: Ask HN: What is the future of back-end development?
#128Earlier quoted context omitted.
It's the classic "Can't you just add another checkbox here?" situation. Yes, I can add a checkbox there. But I have to add the code to include that setting in the API that the front-end calls, to give you a way to retrieve it and change it. Then I have to add code to the data access layer for this new setting. Then I have to write the SQL scripts to add columns/tables for this new setting, as well as change scripts t…
Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…
You monster. You fucking monster.
The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code to work (basically, just the database driver since I own everything else).
ORMs are a huge surface to secure, tune, and understand, and I think that it's unfair to tell someone their app sucks just because they refuse to use one.
Re: Ask HN: What is the future of back-end development?
#129Earlier quoted context omitted.
The financial exchanges running in Java would like to disagree with your gross generalization.
Yes, but: These a highly-tuned code that starts infrequently and doesn't use GC. VMs still have a startup cost; although one could argue that it's something that can be optimized out if there's enough desire.
Startup cost on server side apps is big O of 0. The average JVM for most apps run from maybe 1 hour (continuous deployment shops) to 1 month (slower to release shops). 3 seconds to start the JVM? Does't matter in either of those, don't server traffic until it is done.