6 ms·

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

by nickjj 8y ago

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.

vbezhenar 8y ago
You can't do that with Java. There are some workarounds, but generally people restart application to check changes.
- rubyn00bie 8y ago
  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.
  - vbezhenar 8y ago
    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.
    - chii 8y ago
      > 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.
      - vbezhenar 8y ago
        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.
        tomjakubowski 8y ago
        > 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.
        twblalock 8y ago
        > 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.
        8y ago
    - steve_taylor 8y ago
      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.
    - fnord77 8y ago
      you're mistaken. tomcat using exploded wars hot reloads out of the box. run it inside intellij and it is even easier.
    - rubyn00bie 8y ago
      What about http://ssw.jku.at/dcevm/ http://ssw.jku.at/dcevm/ ?
- burgerboy 8y ago
  Who cares about Java lmao it has no place on the web past 2010
- barrkel 8y ago
  If you want to do it with the JVM, I recommend Play.
- paulddraper 8y ago
  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.
- SomeHacker44 8y ago
  Clojure in JVM does hot reloading brilliantly.
- holtalanm 8y ago
  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/ http://dcevm.github.io/
- RossDM 8y ago
  hot reloading is standard with Java frameworks such as Spring Boot or Play.
tathougies 8y ago
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.
- BigJono 8y ago
  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.
- joevandyk 8y ago
  Easier: Save a file, see the result instantly. In a browser, terminal, etc. Using live reload, auto test, Rails class reloading, and so on.
- mayank 8y ago
  If you have multiple monitors, you don’t have to lose keyboard focus to see a change visually.
  - 721dfc139ee 8y ago
    tiling window managers solve this problem _really_ good (atleast dwm/awesome, but probably everything else, too).
- pdpi 8y ago
  Developer ergonomics are made of an accumulation of small things like this.
- wastedhours 8y ago
  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.
stephenr 8y ago
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"
- TheAceOfHearts 8y ago
  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.
  - deleted 8y ago
    [deleted]
- unityByFreedom 8y ago
  > 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.
- guru4consulting 8y ago
  do you feel the same when you hear "wireless internet", "WiFi", "cordless mic", "wireless phone"? in that context, 'serverless' sounds okay to me.
  - stephenr 8y ago
    No because wifi is a local network standard that, wait for it, works without wires. Serverless very literally involves a server
    - erikpukinskis 8y ago
a_t48 8y ago
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).
honopu 8y ago
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.
ianamartin 8y ago
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.

by nickjj 8y ago

vbezhenar 8y ago

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

rubyn00bie 8y ago
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.
- vbezhenar 8y ago
  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.
  - chii 8y ago
    > 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.
    - vbezhenar 8y ago
      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.
      - tomjakubowski 8y ago
        > 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.
      - twblalock 8y ago
        > 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.
        8y ago
  - steve_taylor 8y ago
    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.
  - fnord77 8y ago
    you're mistaken. tomcat using exploded wars hot reloads out of the box. run it inside intellij and it is even easier.
  - rubyn00bie 8y ago
    What about http://ssw.jku.at/dcevm/ http://ssw.jku.at/dcevm/ ?
burgerboy 8y ago
Who cares about Java lmao it has no place on the web past 2010
barrkel 8y ago
If you want to do it with the JVM, I recommend Play.
paulddraper 8y ago
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.
SomeHacker44 8y ago
Clojure in JVM does hot reloading brilliantly.
holtalanm 8y ago
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/ http://dcevm.github.io/
RossDM 8y ago
hot reloading is standard with Java frameworks such as Spring Boot or Play.

tathougies 8y ago

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.

BigJono 8y ago
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.
joevandyk 8y ago
Easier: Save a file, see the result instantly. In a browser, terminal, etc. Using live reload, auto test, Rails class reloading, and so on.
mayank 8y ago
If you have multiple monitors, you don’t have to lose keyboard focus to see a change visually.
- 721dfc139ee 8y ago
  tiling window managers solve this problem _really_ good (atleast dwm/awesome, but probably everything else, too).
pdpi 8y ago
Developer ergonomics are made of an accumulation of small things like this.
wastedhours 8y ago
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.

stephenr 8y ago

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"

TheAceOfHearts 8y ago
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.
- deleted 8y ago
  [deleted]
unityByFreedom 8y ago
> 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.
guru4consulting 8y ago
do you feel the same when you hear "wireless internet", "WiFi", "cordless mic", "wireless phone"? in that context, 'serverless' sounds okay to me.
- stephenr 8y ago
  No because wifi is a local network standard that, wait for it, works without wires. Serverless very literally involves a server
  - erikpukinskis 8y ago

a_t48 8y ago

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

honopu 8y ago

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.

ianamartin 8y ago

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.