When a process is used to serve multiple requests, I don't think you need to let the whole process terminate just because there is a bug dealing with a single request.
Just because we can not reason about the current request does not mean the only way to get to the clean state for other requests is to terminate the whole process.
I'm lost on how should I integrate all these "languages" of Racket into a single application.
Like, I can see there are `typed/racket`, `racket/gui` and `scribble/base` languages. But how do I write a GUI application that create PDF while also having all the code be typed?
I tried following Racket tutorial multiple times but I'm still lost on how to tied each unrelated "languages" together.
IMO, each chapter of the tutorial just talk about unrelated "language" and then never once show how they all work together. One chapter will talk about web server but not class system, then another chapter will talk about another "language" that support class but then never write web server in it.
You can think of the #lang line as a kind of compiler instruction with that file as scope. There's much more to it but that's a good starting point. If you have an application and want to add types doing it one file at a time is a good strategy.
Besides the #lang line you can also use 'require to bring in libraries, so a single file could contain GUI as well as web server code. #lang isn't constrained to one language at a time either, if they don't conflict you can just add more to that line.
I think this is a fair question. In my opinion, if you're developing a larger application then nearly all of your code will either be in the "racket" language. If you're keen on types, substantial fractions of this may be in the "typed/racket" language. It is true that all of the languages share a common substrate, and they can more or less all interoperate, but it's definitely not the case that a programmer would be likely to break their program into five equal pieces and use a different language for each one. You'll probably write your docs with scribble. Using different languages allows you to have a fundamentally different programming model, and while having that as a backdrop made things like the development of Typed Racket feasible, it isn't something that should prevent you from starting.
TL/DR: Just use Racket. If you find that you really wish that you had some other feature or style of programming, you can investigate whether there's a language that already provides that.
It's not completely about handling unplanned failure, but handling alternative path when the condition for one path is not met. For example, when you perform `withdrawMoney()` it can fail because there's not enough money in the account. This has nothing to do with your coding failure.
If you have if/else in your code, you don't think "If one path fail, so can the other path, so I never handle the other path".
> If my code works out of the box in an unmodified browser, then it is Vanilla JS. If I have to load a framework for it to work, then it isn't, period.
Minor nitpick, third party library and framework does not modify your browser. They all still run on unmodified browsers.
In a way processed food is a scary boogey man - whether animal or plant based, processed foods are bad at providing nutrients to our bodies and can be packed with excessive amounts of salt and other substances.
Agreed: "made from processed ingredients such as pea protein, potato starch and potassium chloride"
Since when is potassium chloride a processed ingredient? I think the author just doesn't know enough chemistry. And you can make potato starch by shredding a potato and drying the resulting water - that's not really what I think of by "processed".
"Processed" as in, this food has been altered from its original state. i.e. Peas = not processed, pea protein = processed. The exact cutoff of how much processing is allowed is kinda up to the individual, but generally when you hear people talking about processed foods being bad, they are talking about almost anything that isn't a "whole" food, i.e. vegetables, whole grains, etc... So things like homemade pasta sauce, even if made with simple ingredients, would be a processed food.
The advice to avoid processed foods isn't necessarily to avoid nasty chemicals, it is to avoid high calorie, high salt, high fat foods that often strip out the healthiest parts of the constituent components during processing. For example, the healthiest part of a potato is the skin, but very few "processed" foods made from potatoes will keep the skin on as part of the processing. You can make a pretty healthy french fry by using organic potatoes and air frying instead of deep frying, but at the end of the day, you would have been better off just eating the whole potato. That is the argument that is generally being made when people talk about processed foods.
I personally like the new plant-based meats and hope they succeed, but I definitely consider them processed food and limit my consumption to every once in a while. But I also consider normal burgers to be processed food, because of the bun and sauces, and in many cases the patty. Using really good pasture raised meat to make a burger patty is way more expensive than any of the plant-based patties. And the cheap meat based patties are probably made from factory farmed animals full of antibiotics. So I am fine paying a little more for a non-meat patty that kinda mimics the real thing. Even if I consider it a processed food, I think I would rank it above the cheap meat patties in terms of health risks.
Agreed. The pea protein though. All the food chemistry technology that enables such proteins to make deep fried nuggets, or vegan ice cream, and so on, that fits the definition of processed food. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7399967/
There are many millions of people who believe that, generally, the less processed, ie the closer to it's natural state any food item is, the better it is for you (or the less bad it is for you). Are you not aware of this?
Which is fine if your company and teams use React a lot.
Why introduce inconsistency in everyone's workflow just because this specific page is a simple contact form?
The fact that it is just a simple contact form is exactly why you should use the same tools and workflow that everyone in your team has already been using.
Write what other people knows so you don't have to be the one maintaining it.
If your client is an otherwise idle system with the latest browser, a fast wired connection, and the developers carefully monitor time to render.
In most cases, at least one of those is not true and the developers are using something like CRA so your site has a number of users who see tens of seconds of nothing while their Android phone downloads and runs a 1MB JS bundle. Bonus points if the marketing department has tossed in a tag manager which delays that even longer.
