Hacker News Reader

Comment by nickjj | Hacker News Reader

From the article:

"When you work with servers, the developer workflow is quite tedious. You have to run a process, find the port, then make your changes, then kill the process (usually with Control+C)..."

I don't know what web servers they are using but in development that's not the case at all in Python, Ruby and Elixir.

With most modern web servers you can run them in some type of development / debug mode where on code change, your code gets reloaded without having to do that manually, and you'll get sub 100ms updates. This has been available for many many many years now. Even with PHP development from 10+ years ago you had a way to see code changes without having to restart Apache.

View on HN

It's hardly surprising the phrasing is a big WTF - the term "serverless" is the most ridiculous thing since rented virtual servers suddenly become "the cloud".

You may as well make a bacon pizza and say "vegetarian" and when someone questions it, just say "well you didnt personally kill the pig, so it's not really from an animal"

I'm also not a big fan of the term "serverless" within this context either, however I don't think it's entirely fair to blame the Zeit team for following along with the rest of the industry. All the big tech companies use the term, which forces smaller players that wish to compete in the same space to use it as well.

> the term "serverless" is the most ridiculous thing since rented virtual servers suddenly become "the cloud".

hah! I'm so happy to see someone say this. I've been thinking the same for awhile and did not know how to articulate it.

do you feel the same when you hear "wireless internet", "WiFi", "cordless mic", "wireless phone"? in that context, 'serverless' sounds okay to me.

No because wifi is a local network standard that, wait for it, works without wires.

Serverless very literally involves a server

Your router has a wire too. Probably two.

Both terms have a deeper meaning which is seemingly lost on pedants like yourself.

Is a rented vm in a warehouse on a remote industrial estate a hyper-scale data centre with dedicated fibre etc.? No.

Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.

But you know that already.

Both terms have a deeper meaning which is seemingly lost on pedants like yourself.

Is a rented vm in a warehouse on a remote industrial estate a managed data centre with dedicated fibre etc.? No.

Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.

But you know that already.

I guess I just don't see how much easier it can get than to kill a process, start it, and test. These are all solutions to non-problems. My control-C + up arrow motion is hammered down after years of practice.

Yeah, same as Ctrl-Shift-R in the browser for me. Even when I'm running a hot reloading server on my project I'll start off pretty much every manual test with a hard refresh because it's so trivial that it's easier than dealing with the 1/500 chance of something going weirdly wrong with the hot reloading and being difficult to debug.

Easier:

Save a file, see the result instantly.

In a browser, terminal, etc. Using live reload, auto test, Rails class reloading, and so on.

If you have multiple monitors, you don’t have to lose keyboard focus to see a change visually.

tiling window managers solve this problem _really_ good (atleast dwm/awesome, but probably everything else, too).

Developer ergonomics are made of an accumulation of small things like this.

Same for me - I even do it for things that don't really need a server restart to take effect, just because it's an ultra-quick reflex. It's a non-issue really.

The reality of developing serverless apps is seriously painful for anything that's not 'hello world'. Non-trivial functions very quickly go over the size limit for directly uploading your dependencies, then you have to start doing stuff like extracting your python packages into a zip file and pushing it to an s3 bucket, and then every small code change requires a new upload. Testing and debugging tools for serverless are distributed logs that are mixed in with all your other logs in your VPC.

I'll take a look at this the next time I'm required to use serverless, but I really don't know what the people pushing this as the future of web apps are smoking. It's never been anything but pain for me. How anyone can try to use this for real and say, "This is sooooo much better than all that old shit!" has never actually used that old shit. That old shit works really, really well. It has for a very long time.

I implemented hot reloading once for a game scripting engine. The gain was totally worth the work I put in (and had the side effect of discouraging use of globals).

Yeah in PHP, unless you have some opcode caching that ignores file modification time, you simply need to just change the file and it immediately starts running the new code. There isn't a compiled runtime generally that persists across requests. This is one of the great things about php, and is one of the things that made PHP so pervasive and get the marketshare that it did.

When I last did PHP, i ran it all in docker, but the same thing applies.

You can't do that with Java. There are some workarounds, but generally people restart application to check changes.

What? I beg to differ... I've used many a JVM web framework with hot reloading. Like most every language, they are not perfect, and come with gotchas but they're surely there.

The only "easy" way to support hot reload in JVM is using java agent. But it can only reload method body, so it's extremely limited tool. That's how IDE usually work. You can sell your house and buy JRebel license, but if you don't have house to sell, you're out of luck. You can try some experimental alternative JVM implementations (DCEVM) which might or might not work.

May be your framework is just restarting automatically very fast. That's not a hot reload, though.

> framework is just restarting automatically very fast. That's not a hot reload, though.

If you can't tell the difference, then what's the difference?

There are plenty of ways to reload classes in the JVM as well - OSGi is the most well known and popular. If an agent is the only way you've seen reloading done, then you mustn't have much experience with the full range of libraries and frameworks available on the JVM.

The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing. OSGI does not reload classes, it loads new classes, you can't reload class for an existing object. It's the same restart, you just leak memory.

> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.

Seems like slow startup time would be just as bad, if not worse, for a workflow that involves killing the server and bringing it back up again from scratch to test changes. So I think that either way it's a good idea to architect your application, at least in "development mode", to have a fast startup time.

> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.

These are good things for serverless, which is what the article is about -- runtime state in a serverless application is bad, and fast startup is good.

Serverless instances are intended to be interchangeable and ephemeral. You should be able to start new instances and they should be able to do the same work as the existing instances -- that only works well if they are stateless. Any necessary state should be stored in a database or blob store or some other external state management system.

Plus, having runtime state around from a previous version (or versions!) of the app sounds utterly terrifying

You are exactly right, and a lot of these frameworks that do "hot reload" for other languages are fundamentally doing similar things.

Granted, there are advantages to things like JRebel that can also preserve state, but I feel like that is really orthogonal to the whole discussion.

Five years ago I was coding Java EE (JSF, EJB, JPA) on NetBeans, which comes bundled with GlassFish. The hot reload development experience back then was extremely fast (sub-second for what I was doing) and a lot more reliable than JRebel. It didn't need any special configuration. The whole thing worked right out of the box. I got the feeling back then that JRebel's days were numbered if developers caught on. Sadly, the trend was more towards a build-your-own stack approach, typically using Spring, and so JRebel continued to have a market. It's a pity, because Java EE 6 onwards seemed to be quite well thought out with numerous open source implementations and a good reference implementation.

you're mistaken.

tomcat using exploded wars hot reloads out of the box. run it inside intellij and it is even easier.

What about http://ssw.jku.at/dcevm/ ?

If you want to do it with the JVM, I recommend Play.

There are in fact several ways to do this in Java.

The Play framework uses classloaders to keep library classes (which are stateless) loaded, while reloading app code.

The JVM has build in hot swapping for cases where signatures don't change.

And then JRebel uses proprietary rocket science to do really good hot reloading.

Clojure in JVM does hot reloading brilliantly.

wut?

java has had hot reloading of recompiled classes for years.

and if you use dcevm, the number of things that can be hot-reloaded is even higher: http://dcevm.github.io/

hot reloading is standard with Java frameworks such as Spring Boot or Play.

Reply on news.ycombinator.com