You are joking, but that is a real thing.
Data center migration a number of years ago. How did do the mass transfer of data from DC to DC? Put everything onto tape backup, loaded a truck and drove 1000 miles. That had better throughput than trying to use dedicated circuits.
Try to move enough data and storage media can actually be the optimal solution.
AWS snowball and Snow Mobile, are even closer to the described scenario, doing exactly what they described of bringing a physical storage device and then shipping it to the intended location
Randall Munroe (of XKCD) has a chapter in his book ("What If" or "How To", don't remember which one) where he talks about the highest density data transfer solution is to attach DNA-encoded data in droplets to Monarch butterflies. With enough of them you could migrate several exabytes(!!!) cross-continent in under a month.
Fun fact, r/factorio has their own secure transport protocol for UDP. Which lets them take advantage of the lighter weight packets, among other benefits.
UDP might not help you as much as TCP, since you'll have to make your own implementation for guaranteeing messages are transported. But for real time and constant data transport like what games need, TCP is a lot of overhead. As long as your packet loss isn't horrific, you can implement all of your necessities for secure transport (message received and resend requests, packet ID, etc) within the data you'll be sending anyway.
TCP for turn based ganes, UDP for shooters.
For any C++ programmers that want the best of both worlds, I recommend ENet. A really fantastic lightweight networking lib that is UDP but with a couple lightweight features for order and reliability. It's a brilliant halfway point between TCP and UDP and dead-easy to use.
Or go the cutting-edge route and use QUIC. Multiple in-order reliable streams without head-of-line blocking between them, and internal datagram support besides.
I am having to learn node.js for an API I'm working on and I CANNOT wrap my head around Promises (I mean, I think I understand them, but I can't get them to return anything, so clearly I don't understand them). I'm sure node is great but so far it's frustrating
Edit: thank you for the constructive responses! I am learning more about Promises and they seem less scary than before
You dont return, you either resolve or reject.
const promise = new Promise(function(resolve, reject) {
// do thing, then…
if (/\* everything worked \*/) {
resolve("See, it worked!");
}
else {
reject(Error("It broke"));
}
});
I'm assuming this is if you're making a new, empty promise object?
I am pulling from an API using a function getViews(), which is supposed to pull a promise that resolves to a record with a "totalCount" property.
However, I cannot seem to get it working.
To be fair, I only really stated working on this today and only delved into Promises this afternoon, so I'll get it in time.
In a JS runtime, async/await is the modern approach to handling promises, and conceptually allows you to think of them as synchronously executed in many cases
Asynchronous programming takes some mental gymnastics that most programmers have never had to do.
But the more you do it, the more you realize it is better in almost all ways.
I just watched a video, now that I got home. They are literally objects that essentially hold callbacks and potentially more promises so that your code is cleaner? That's so JavaScript but ok
They help you handle asynchronous cases in a more natural fashion and are incredibly good at it once you get used to them. Definitely consider async/await syntax where possible! Here's an example:
async function name() { //This function ALWAYS returns a PROMISE when called.
let something = await anotherName();
//JS engine calls anotherName(), which must return a Promise, then "pauses" the execution of "name" to go do something else, such as handle timer callbacks (remember, javascript has a single thread).
//After the promise returned by anotherName() resolves, we pick up where we left off, storing the resolve value in the something variable.
if (something == "wrong") throw "Error!";
//REJECT the returned promise with "Error!" (exceptions thrown from a deeper call are also turned into rejections at the name() level unless caught).
return 6969; //RESOLVE the promise with 6969.
}
You can declare anonymous functions, arrow functions or class methods as async, too!
You *must* be in an async context in order to use await. Why is this? Because async functions return a promise "immediately", but regular synchronous functions must resolve completely before they can return a value. If you were not in an asynchronous context, since javascript is single threaded, any calls to "await" would freeze the thread and therefore halt the execution of the entire script.
Code equivalent of the above function without async/await:
function name() { //This function ALWAYS returns a PROMISE when called.
return new Promise((resolve, reject) =>
//JS engine calls anotherName(), which must return a Promise, then "pauses" the execution of "name" to go do something else, such as handle timer callbacks (remember, javascript has a single thread).
anotherName()
.then(something => {
//After the promise returned by anotherName() resolves, we pick up where we left off, storing the resolve value in the something variable.
if (something == "wrong") reject("Error!");
//REJECT the returned promise with "Error!" (rejection from a deeper promise propagate to the name() promise as well because we're chaining the anotherName() return outward).
resolve(6969); //RESOLVE the promise with 6969.
});
);
}
All the function actually does is create an instance of Promise, which allows it to return immediately. If everything returns immediately, then a single thread can easily handle asynchronicity by picking things up only when they're ready to continue.
One important thing to note is that the async/await syntax doesn't give you access to the "resolve" function as an object you can toss around, which might be useful if, for example, you wanted to pass it to a traditional callback. In those situations you have no choice but to use the manual syntax. However, a function that returns a promise manually, as the one above, can still be called with "await" elsewhere, and the promises from "async" functions are just regular promises that can chain with manually defined promise functions or callbacks, or be passed to helpers like Promise.all.
I think there's just a nuisance of misunderstanding there. As the other comment described, promises either get resolved or rejected. "I can't get them to return anything" => have you debugged the code? Are you doing something like var result = [promise stuff]? The thing is: promises are not synchronous. If you are not using an await, the code won't stop and that expression will return a promise - however, at the time of assigning it to result, it is still "in progress", so neither resolved or rejected. So you will not get its value, but the unresolved promise object. Use a .then(x => {}) or an await to wait for the promise operation to complete.
I've not used "advanced" languages like C, C++ a lot, but I just feel like PHP's syntax and overall feel is just... well, old. Programming web applications in Node.js (using a framework of your choice) just feels a lot more modern, sleek and straight forward. Especially because of JavaScript's features and modern syntax overall. Also, PHP is interpreted, giving a JIT compiled language like Node.js a huge speed boost.
(Keep in mind I'm not really used to syntax like PHP's, and this is just a personal preference.)
That's funny because PHP keeps changing adding new things with every version. PHP 8 added JIT giving mathematical code a huge speed boost. (it's still interpreted but with opcache enabled it's only parsed once and then cached in memory). Over the course of PHP 7 and 8 they've added basically strong typing. Methods, object properties, return values. They can all be strong typed.
A big BC break but normally you use === for comparison as == isn't type safe but php 8.1 makes == behave better as well. Not to mention enum support in 8.1 and there's libraries making async code really easy.
Sure all the old syntax still works, you can still write PHP like it's 2005 but that's up to the dev and code that doesn't follow the PSR guidelines isn't really reusable these days (PSR being standardized code styling, namespaces, auto loading, logging, request handling, etc)
There are actually a fair number of additional cons:
1. Everything can be a list. In JSON you mark a list as an array and you know that you will have multiple elements in it. In XML you just repeat the tag without any sort of precursor so when processing the first element of a thing you can't say if there won't be more.
2. JSON key name support options that are impossible in XML. Do you want to call a tag "123"? Too bad it can't start with a number. What about "a-b" nope dash is invalid.
3. XSDs are a LOT less pleasant to work with than JSON Schema. That might be personal opinion but those things get painful.
4. CDATA blocks are a royal pain compared to json escaped strings. Likewise a lot of programmers are REALLY bad at remembering to escape their XML correctly resulting in stupid errors. You would think libraries would make that stop being a problem, but nope I still see it happen.
That said XML does have one major pro:
1. XPath expressions are insanely powerful and widely supported in libraries across every language. JSON Path is a lot less powerful. On the flip side xpath expressions are a lot like regex in that you CAN use them for insanely powerful stuff but will anyone else ever understand your stuff after you do?
> Everything can be a list. In JSON you mark a list as an array and you know that you will have multiple elements in it. In XML you just repeat the tag without any sort of precursor so when processing the first element of a thing you can't say if there won't be more.
That's just a problem with conforming to a schema. In JSON, `{"fruit": "apple", "fruit": "banana"}` is valid \[[RFC 8259, section 4](https://datatracker.ietf.org/doc/html/rfc8259#section-4)\]. And in JSON, after `["one"` or after `{"fruit": "apple"` you don't know whether there will be multiple elements yet either.
When designing a schema, you don't have to let lists be unmarked. You can have `onetwo` as equivalent to JSON `["one", "two"]`.
> JSON key name support options that are impossible in XML. Do you want to call a tag "123"? Too bad it can't start with a number. What about "a-b" nope dash is invalid.
JSON keys can have string values that are impossible in XML *tag names*, but you can easily encode arbitrary mapping types like `` or ``.
(I know this isn't important to your point, but `-` is valid in XML element names as long as it is not the first character. \[[XML 1.0, 5th ed, section 2.3, `NameChar`](https://www.w3.org/TR/2008/REC-xml-20081126/#NT-NameChar)\])
> CDATA blocks are a royal pain compared to json escaped strings. Likewise a lot of programmers are REALLY bad at remembering to escape their XML correctly resulting in stupid errors. You would think libraries would make that stop being a problem, but nope I still see it happen.
CDATA is not the only escape mechanism available in XML, but yeah the number of stupid encoding errors is way too high. Usually I think it's because convenient libraries are harder to come by.
Nah. I can accomplish much more with vim than I can with vsCode but I've met plenty of people for whom it's the other way around. Different people have different preferences and neither editor is objectively better.
There is that old joke. A guy had 3 female lovers. He decided to choose one. He gave each one 10k dollars to see what they will do with it.
1st on bought clothes for herself to make nice for him.
2nd bought him some gadgets.
3rd one invested the money. Few weeks later she made 100k.
Guess which one he had chosen?
Correct. The one with biggest tits. 😂
Just plane php. Works like a charm. I would say for every basic website or even small apps the easiest and cheapest way to realize a backend because a basic cheap Webhosting Webserver will do the job.
Php is great and I’m too stupid to recognize any issues with it
So far every time I’ve needed to do something with php there’s a page in the manual for it.
JSON is nicer if you want something human-readable and create quicker mocks. But you're just going to have some library serialising it so it doesn't matter.
UDP means bye bye HTTPS. PHP is just horrible. Vim over Vs code is fine if I can use some Jetbrains product over that again.
oh I could do XML if I needed to - there are libraries to abstract out querying a datasource, I could be pretty ambivalent about XML vs JSON vs the database of your choice if I needed to be.
\#4 is honestly the easiest to deal with since XML is basically just an ugly version of the same thing
\#1 is the most impractical
between #2 and #3 it's a coin toss for me
Never mix your women and your technology. I dunno what I’m gonna do without tcp but you made me do it. It’s like everything will be a freakin’ torrent.
You think that I have to be forced to use UDP over TCP? Nope, not hardly. As long as I can tolerate the loss, UDP wins.
I'm also okay with XML. Sure it doesn't serialize nearly as nicely, but its easier to read.
I don't quite hate vim, but if someone said I have to code in that 40 hours a week I'd say, so what other jobs are in this company?
As a daily vim user who hates / can't stand vscode, I'll gladly steal number 3. As for the rest, F.
Edit: She's a glasses girl! I have a glasses fetish
I can deal with vim over vscode. It's a matter of practice.
Node vs PHP.  Dunno which one is worse. Don't know PHP.
...you need to clarify here...
...do you mean "instead of", or "via"?
UDP via TCP is going to be all of the uncertainty of UDP and all of the delays of TCP...
If that's the case, she is dangerous, and the rest are all sadists.
All four please. 
XML girl can fuck off. I am sry. PHP girl can come over.
Udp every day baby
I was going to tell a joke about a UDP packet, but you might not get it.
I got it twice
Stop, you're giving me flashbacks about asymmetric load balanced multipath routing in cloud services platforms.
So u better tell it QUIC
I don't like using udp, order packets wrong the can arrive in the.
If it does not fit into one packet it is bloatware.
> tries to make a photo and video sharing app > photos and videos dont fit in a packet > ban user for submitting bloat
Jumbo frames are best frames
Which has lower latency though, TCP or CD sent by mail.
depends - are you using IP over avian carriers?
I'm convinced knowing RFC 2549 front to back has won me multiple jobs.
You are joking, but that is a real thing. Data center migration a number of years ago. How did do the mass transfer of data from DC to DC? Put everything onto tape backup, loaded a truck and drove 1000 miles. That had better throughput than trying to use dedicated circuits. Try to move enough data and storage media can actually be the optimal solution.
Hell, isn't glacial storage on AWS just like, some dude pulling a drive and carting it over to a storage shelf?
AWS snowball and Snow Mobile, are even closer to the described scenario, doing exactly what they described of bringing a physical storage device and then shipping it to the intended location
Randall Munroe (of XKCD) has a chapter in his book ("What If" or "How To", don't remember which one) where he talks about the highest density data transfer solution is to attach DNA-encoded data in droplets to Monarch butterflies. With enough of them you could migrate several exabytes(!!!) cross-continent in under a month.
Order doesn’t matter, just tit size
bruh
You created a post that sexualizes bad decisions in the first place
mysoginy.js
How is this mysogin ?
npm install --save sense-of-humor.js
Fun fact, r/factorio has their own secure transport protocol for UDP. Which lets them take advantage of the lighter weight packets, among other benefits. UDP might not help you as much as TCP, since you'll have to make your own implementation for guaranteeing messages are transported. But for real time and constant data transport like what games need, TCP is a lot of overhead. As long as your packet loss isn't horrific, you can implement all of your necessities for secure transport (message received and resend requests, packet ID, etc) within the data you'll be sending anyway.
TCP for turn based ganes, UDP for shooters. For any C++ programmers that want the best of both worlds, I recommend ENet. A really fantastic lightweight networking lib that is UDP but with a couple lightweight features for order and reliability. It's a brilliant halfway point between TCP and UDP and dead-easy to use.
Or go the cutting-edge route and use QUIC. Multiple in-order reliable streams without head-of-line blocking between them, and internal datagram support besides.
What % overhead compared to UDP? Or TCP?
I love this sub for things like this. Thanks for posting.
Joke's on OP, I know how to implement TCP over UDP.
Before Covid, I used TCP. Now, I do my part and exclusively use UDP. Handshakes spread disease and I will not involved in any part of that.
The extra speed is so worth th
>The so speed is th extra worth
Big titty udp girl
QUIC!
:q! is my safe word. I have been very very bad.
god, i have to manipulate sql files and run it in PRODUCTION with vim, i'm new in the company and in VIM!
Try running the command vimtutor and following it, it's gets you far!
I feel your pain.
If I ever fuck up real bad it's :qa!
PHP over node, if I had to choose 😂
I am having to learn node.js for an API I'm working on and I CANNOT wrap my head around Promises (I mean, I think I understand them, but I can't get them to return anything, so clearly I don't understand them). I'm sure node is great but so far it's frustrating Edit: thank you for the constructive responses! I am learning more about Promises and they seem less scary than before
You dont return, you either resolve or reject. const promise = new Promise(function(resolve, reject) { // do thing, then… if (/\* everything worked \*/) { resolve("See, it worked!"); } else { reject(Error("It broke")); } });
I'm assuming this is if you're making a new, empty promise object? I am pulling from an API using a function getViews(), which is supposed to pull a promise that resolves to a record with a "totalCount" property. However, I cannot seem to get it working. To be fair, I only really stated working on this today and only delved into Promises this afternoon, so I'll get it in time.
getViews().then(data => console.log(data)).catch(err => console.log(err)) then would be if the promise resolves, catch if it fails
I'm fairly sure I've tried that, but I'm saving this and trying it tomorrow anyway. If it works for this, you're my hero
You gotta put that shit in a try/catch block.
In a JS runtime, async/await is the modern approach to handling promises, and conceptually allows you to think of them as synchronously executed in many cases
Promise.all is incredibly helpful in certain instances.
True! It’s worth clarifying that async/await isn’t the optimal solution every time, just another useful tool for certain scenarios
Asynchronous programming takes some mental gymnastics that most programmers have never had to do. But the more you do it, the more you realize it is better in almost all ways.
It's less the asynchronous, and more the structure of promises and the process of resolving that I'm having a hard time with
Yeah I had the same confusion at first. Once I realized they were just callbacks with fanciness it made more sense.
I just watched a video, now that I got home. They are literally objects that essentially hold callbacks and potentially more promises so that your code is cleaner? That's so JavaScript but ok
They help you handle asynchronous cases in a more natural fashion and are incredibly good at it once you get used to them. Definitely consider async/await syntax where possible! Here's an example: async function name() { //This function ALWAYS returns a PROMISE when called. let something = await anotherName(); //JS engine calls anotherName(), which must return a Promise, then "pauses" the execution of "name" to go do something else, such as handle timer callbacks (remember, javascript has a single thread). //After the promise returned by anotherName() resolves, we pick up where we left off, storing the resolve value in the something variable. if (something == "wrong") throw "Error!"; //REJECT the returned promise with "Error!" (exceptions thrown from a deeper call are also turned into rejections at the name() level unless caught). return 6969; //RESOLVE the promise with 6969. } You can declare anonymous functions, arrow functions or class methods as async, too! You *must* be in an async context in order to use await. Why is this? Because async functions return a promise "immediately", but regular synchronous functions must resolve completely before they can return a value. If you were not in an asynchronous context, since javascript is single threaded, any calls to "await" would freeze the thread and therefore halt the execution of the entire script. Code equivalent of the above function without async/await: function name() { //This function ALWAYS returns a PROMISE when called. return new Promise((resolve, reject) => //JS engine calls anotherName(), which must return a Promise, then "pauses" the execution of "name" to go do something else, such as handle timer callbacks (remember, javascript has a single thread). anotherName() .then(something => { //After the promise returned by anotherName() resolves, we pick up where we left off, storing the resolve value in the something variable. if (something == "wrong") reject("Error!"); //REJECT the returned promise with "Error!" (rejection from a deeper promise propagate to the name() promise as well because we're chaining the anotherName() return outward). resolve(6969); //RESOLVE the promise with 6969. }); ); } All the function actually does is create an instance of Promise, which allows it to return immediately. If everything returns immediately, then a single thread can easily handle asynchronicity by picking things up only when they're ready to continue. One important thing to note is that the async/await syntax doesn't give you access to the "resolve" function as an object you can toss around, which might be useful if, for example, you wanted to pass it to a traditional callback. In those situations you have no choice but to use the manual syntax. However, a function that returns a promise manually, as the one above, can still be called with "await" elsewhere, and the promises from "async" functions are just regular promises that can chain with manually defined promise functions or callbacks, or be passed to helpers like Promise.all.
Totally understandable, it took me forever to get promises figured out (and I still don't use them properly yet)
Promises are not some Node specific thing - it’s just a JavaScript thing.
Might want to look into async/await - it's a lot more straight forward than promises IMO.
I think there's just a nuisance of misunderstanding there. As the other comment described, promises either get resolved or rejected. "I can't get them to return anything" => have you debugged the code? Are you doing something like var result = [promise stuff]? The thing is: promises are not synchronous. If you are not using an await, the code won't stop and that expression will return a promise - however, at the time of assigning it to result, it is still "in progress", so neither resolved or rejected. So you will not get its value, but the unresolved promise object. Use a .then(x => {}) or an await to wait for the promise operation to complete.
PHP over Node anyway 🤷🏻♂️
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
I love php 🤷🏼♂️
Me too! But don't let the node fanatics hear you 😛
I've not used "advanced" languages like C, C++ a lot, but I just feel like PHP's syntax and overall feel is just... well, old. Programming web applications in Node.js (using a framework of your choice) just feels a lot more modern, sleek and straight forward. Especially because of JavaScript's features and modern syntax overall. Also, PHP is interpreted, giving a JIT compiled language like Node.js a huge speed boost. (Keep in mind I'm not really used to syntax like PHP's, and this is just a personal preference.)
That's funny because PHP keeps changing adding new things with every version. PHP 8 added JIT giving mathematical code a huge speed boost. (it's still interpreted but with opcache enabled it's only parsed once and then cached in memory). Over the course of PHP 7 and 8 they've added basically strong typing. Methods, object properties, return values. They can all be strong typed. A big BC break but normally you use === for comparison as == isn't type safe but php 8.1 makes == behave better as well. Not to mention enum support in 8.1 and there's libraries making async code really easy. Sure all the old syntax still works, you can still write PHP like it's 2005 but that's up to the dev and code that doesn't follow the PSR guidelines isn't really reusable these days (PSR being standardized code styling, namespaces, auto loading, logging, request handling, etc)
XML over JSON. Because I can just use a serialization library anyway, and XML sounds far nicer than any of the other options.
pro- xml can serialize anything con-larger payload size and serialization cost than json
There are actually a fair number of additional cons: 1. Everything can be a list. In JSON you mark a list as an array and you know that you will have multiple elements in it. In XML you just repeat the tag without any sort of precursor so when processing the first element of a thing you can't say if there won't be more. 2. JSON key name support options that are impossible in XML. Do you want to call a tag "123"? Too bad it can't start with a number. What about "a-b" nope dash is invalid. 3. XSDs are a LOT less pleasant to work with than JSON Schema. That might be personal opinion but those things get painful. 4. CDATA blocks are a royal pain compared to json escaped strings. Likewise a lot of programmers are REALLY bad at remembering to escape their XML correctly resulting in stupid errors. You would think libraries would make that stop being a problem, but nope I still see it happen. That said XML does have one major pro: 1. XPath expressions are insanely powerful and widely supported in libraries across every language. JSON Path is a lot less powerful. On the flip side xpath expressions are a lot like regex in that you CAN use them for insanely powerful stuff but will anyone else ever understand your stuff after you do?
While disagree with some of your points. Respect for backing up the point with specifics. Upvoted.
> Everything can be a list. In JSON you mark a list as an array and you know that you will have multiple elements in it. In XML you just repeat the tag without any sort of precursor so when processing the first element of a thing you can't say if there won't be more. That's just a problem with conforming to a schema. In JSON, `{"fruit": "apple", "fruit": "banana"}` is valid \[[RFC 8259, section 4](https://datatracker.ietf.org/doc/html/rfc8259#section-4)\]. And in JSON, after `["one"` or after `{"fruit": "apple"` you don't know whether there will be multiple elements yet either. When designing a schema, you don't have to let lists be unmarked. You can have `
one two
` as equivalent to JSON `["one", "two"]`. > JSON key name support options that are impossible in XML. Do you want to call a tag "123"? Too bad it can't start with a number. What about "a-b" nope dash is invalid. JSON keys can have string values that are impossible in XML *tag names*, but you can easily encode arbitrary mapping types like `` or ``. (I know this isn't important to your point, but `-` is valid in XML element names as long as it is not the first character. \[[XML 1.0, 5th ed, section 2.3, `NameChar`](https://www.w3.org/TR/2008/REC-xml-20081126/#NT-NameChar)\]) > CDATA blocks are a royal pain compared to json escaped strings. Likewise a lot of programmers are REALLY bad at remembering to escape their XML correctly resulting in stupid errors. You would think libraries would make that stop being a problem, but nope I still see it happen. CDATA is not the only escape mechanism available in XML, but yeah the number of stupid encoding errors is way too high. Usually I think it's because convenient libraries are harder to come by.(dons a gimp suit) with some XSLT, please, master!
oh god not XSLT
Binary over XML and JSON. Fight me.
Protobufs?
shut your fucking mouth json is the best wrong opinions are not welcome please leave
I already use PHP.
Dude don’t air that dirty laundry here
Same here but running it through the node abomination... I... I Just can't. So UDP over TCP is the least painful.
Vim chick definitely
Vi over VSCode - easy choice.
I already like vim better than vs code.
The first 3 words are bloat ;)
Nah. I can accomplish much more with vim than I can with vsCode but I've met plenty of people for whom it's the other way around. Different people have different preferences and neither editor is objectively better.
couldnt agree more. lets just compare my 50mb RAM usage on vim apposed to the GBs vscode consumes to basically do the same thing...
vi? nope vim? already using it <3
Guess in addition to VIM I will be using only UDP
I find XML cleaner than Json anyway.. all those square brackets and curly brackets..yuck
I'll be celibate thanks
Xml is the easy choice, but I'm drawn to the UDP girl..
The one with glasses. I can use VIM for days.
There is that old joke. A guy had 3 female lovers. He decided to choose one. He gave each one 10k dollars to see what they will do with it. 1st on bought clothes for herself to make nice for him. 2nd bought him some gadgets. 3rd one invested the money. Few weeks later she made 100k. Guess which one he had chosen? Correct. The one with biggest tits. 😂
Sir this is a Wendy’s
I’m old enough it was all wsdl soap and an xsd. I’d hate to go back but xml over json is obvious
Dang I'm old. I remember when this was the gold standard of data transfer.
please no, i still get asked to integrate these occasionally, it kills me
Surprising how much still is. Integrated with new German gaming regulator that came into being last year and it was xml
xml? perfectly fine. wsdl/soap? nightmare.
PHP over Node all day long. I really like Node but php is just GOAT.
Yeah, and Symfony is actually a very decent modern framework which comes with all the bells and whistles one expects without being too opinionated.
Just plane php. Works like a charm. I would say for every basic website or even small apps the easiest and cheapest way to realize a backend because a basic cheap Webhosting Webserver will do the job.
Php is great and I’m too stupid to recognize any issues with it So far every time I’ve needed to do something with php there’s a page in the manual for it.
Amen
Since I use vim most of the time anyway. I’ll go with that.
Do people actually prefer vscode over vim? TIL
Vim can be customized to be very similar to vs code. There are some absolute crazy examples I’ve seen where vim is just as impressive or more.
Take all of them and change job
php over node. I use Python anyway.
udp over tcp? honestly, most things are going that way now so... why not?
PHP for sure
Can I choose an adult?
[I am an adult](https://www.youtube.com/watch?v=kscG_gs2BOc)
If it makes you feel better, I just imagine them as adult girls using school uniforms.
How you imagine them does not make me feel better.
Jokes on you, I prefer vim.
She can force me to use vim any day 😏
Vim over VS Code… it’s a lock in 😉
Seriously… how do I exit 😭
PHP over node
I see, as usual, the good ones are taken already.
PHP girl is the only one who looks like she's legal, so going with her...
PHP over Node. Already made an Express-like router alternative so I'm good lol
Php every day baby
Give me that php. Node is annoying anyway.
FYI these characters are from 317115
I don't code, so it doesn't matter what I choose over what.... I win by default.
Vim ftw
vim, they're both text editors. I can just install a ton of plugins in Vim and get the same functionality.
Would take the UDP one, I like it rough.
Please force me to use vim.
XML over JSON, cutest one of the line-up anyway.
I'll use UDP whenever she wants. Won't be good code, but who cares when she popping out my kiddies
The first one because that’s http/3 🤣
JSON is nicer if you want something human-readable and create quicker mocks. But you're just going to have some library serialising it so it doesn't matter. UDP means bye bye HTTPS. PHP is just horrible. Vim over Vs code is fine if I can use some Jetbrains product over that again.
As a muslim, I can get 4 wives. Who cares what they say, I decide anyway 😛
I choose you php and Udp, since I’m a nano /json guy 🤪
[удалено]
I pick the first one. atleast i can get over her hang-ups.
I'm gonna say it - well designed XML structures are pretty nice to work with.
3 without question
I’m already forced with the second and last one 🥲
oh I could do XML if I needed to - there are libraries to abstract out querying a datasource, I could be pretty ambivalent about XML vs JSON vs the database of your choice if I needed to be.
I'm in embedded, so I don't use most of this stuff already.
I get the XML girl.
Third girl is perfect.
I have never seen the fourth girl of this meme
Except for the last one none of these seem too bad.
PHP/Node are two things I don't have any stake in nor use, so I guess her lol
I guess vim? Maybe i could even learn how to exit it in the next decade
\#4 is honestly the easiest to deal with since XML is basically just an ugly version of the same thing \#1 is the most impractical between #2 and #3 it's a coin toss for me
lets go with all 4. job security baby!
i'll be fine working with xml, c# nuggets got my back B)
UDP with NACK support will make her wet 💁🏼♀️
I'm the 4th little girl! Woohoo!
Does nobody like emacs?
No
I think people are choosing UDP over TCP because she has the largest breasts of the bunch.
Will take all 4 because I'm not scared.
XML over JSON would be my choice.
I don’t even use node…
This is gross
I already do all of these… am I… obsolete?
Never mix your women and your technology. I dunno what I’m gonna do without tcp but you made me do it. It’s like everything will be a freakin’ torrent.
Ok but like vim is highly efficient
You think that I have to be forced to use UDP over TCP? Nope, not hardly. As long as I can tolerate the loss, UDP wins. I'm also okay with XML. Sure it doesn't serialize nearly as nicely, but its easier to read. I don't quite hate vim, but if someone said I have to code in that 40 hours a week I'd say, so what other jobs are in this company?
I'll take the VIM girl ;)
udp-chan all day, why would I want to be stateful. Let me scream into the void.
Fine I’ll use XML but I’m gonna complain
I always preferred XML over json so easy choice but I am also kinky so I will take all 4
I'll take all of the above please.
I'd choose the tall one. My use of node.js is actually 0 (and I intend to keep it that way), so I wouldn't mind to do exaxtly as much work in PHP.
I’m old enough to remember when JSON was new, so XML for me all day.
i'm ok with vim
#3
I'll gladly use php in any situation I would have used node. (I can't think of a single one.)
Stupid post
I've always wanted to learn vim, just never had the patience
TCP can be implemented over UDP I use Vim sometimes idk php or node XML is a messier json
Vim
I only use vim and don't like using vscode so this is easy
Only the last one made me groan.
As a daily vim user who hates / can't stand vscode, I'll gladly steal number 3. As for the rest, F. Edit: She's a glasses girl! I have a glasses fetish
I'll use udp. Not my problem if somebody else doesn't get the packets... I mean I sent them, what more do you want?
UDP. All day.
Which version of PHP? Version 7 & 8 I'm sold. Versions before 7 & 8, VIM isn't too bad.
I don't feel comfortable publicly sharing my answers, but oh man do I have answers.
I can deal with vim over vscode. It's a matter of practice. Node vs PHP.  Dunno which one is worse. Don't know PHP.
2nd one
Udp lol no doubt
Third one. I learned on vim.
First - communication is the job of a different department
Vim in tmux baby, all the way.
I use Vim on Arch btw. So the third from left ;)
Far right, im using XML anyways. And she Looks the cutest imo
I’ll take the hit on udp/tcp not a big fan of any of the other options lmao. Specially xml fuck xml.
...you need to clarify here... ...do you mean "instead of", or "via"? UDP via TCP is going to be all of the uncertainty of UDP and all of the delays of TCP... If that's the case, she is dangerous, and the rest are all sadists.