Live data from Hacker News

Ask HN: What is the future of back-end development?

news.ycombinator.com

121–130 of 164 posts

Re: Ask HN: What is the future of back-end development?

#121

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.

i often get the, can we make this a websocket instead of an api call. that way it can just get updated instead of you having to run a query... 1. not neccessarily faster (push vs pull depends entirely on the data creation consumption model) 2. the push scenario is not how most database access patterns work. Instead it's likely just polling the db on the backend instead of the front end. So same db load. and now lots of open connections to simultaneously maintain and garbage collect.

Re: Ask HN: What is the future of back-end development?

#122
post #61

Earlier 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.

Sounds like you're looking for something closer to Otto (https://www.ottoproject.io/)

Re: Ask HN: What is the future of back-end development?

#123

I 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…

[deleted]

Re: Ask HN: What is the future of back-end development?

#124
post #78
post #68

Earlier 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?

Everyone has their reasons, but if it is something I actually cared about I would prefer to pay money for it. Generally things that cost money, even 5 cents, have better uptime than "free" stuff.

Re: Ask HN: What is the future of back-end development?

#125

When large code bases will have sane(!) static typing and functional programming principles. And no, slamming types onto Python won't help much.

Hi, why the anger? What's the difference between (quote)slamming types into python(unquote) and adding support for types? Do you mean we should all learn Haskell now?

Re: Ask HN: What is the future of back-end development?

#126
I would love the future to be P2P. However, I don't see it happening unless we have an economic revolution. There is just too much money to be made from collecting data. Data is king.

My 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?

#127
post #77
post #67

Earlier 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…

If you make a few competing 3-man startups.

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?

#128
post #19

Earlier 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…

> Push to master. Update production.

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?

#129
post #75

Earlier 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.

The financial exchanges I know DO use GC.

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.

Post reply on HN