[zAy0LfpBZLC8mAC]

> Being able to use any programming language with modern HTTP-based protocols is a real luxury.

No, it's not, it's a huge pile of crap, because HTTP is so complicated that you essentially have to distrust any implementation of it that you haven't audited, and even then, it's questionable (plus, most implementations turn out to be buggy if you look closely, and serious vulnerabilities aren't exactly uncommon), and it doesn't even fit many common scenarios without additional hacks like long polling.

Also, "any programming language" is a huge exaggeration. Ever used HTTP on a microcontroller?

> Before, you could only use a programming language if had a production-ready implementation of the protocol you wanted to speak. Otherwise you would spend the next weeks or months tediously writing one.

Now, that's just bullshit. If you have an HTTP implementation, you necessarily also have a TCP implementation. You don't need to write anything in order to use TCP, you just open a socket and use it and forget about HTTP. HTTP serves no purpose in most cases.

Oh, and maybe more importantly: Ever used HTTP for peer-to-peer communication? No, you need a server! Because it's so much more convenient to add a server "in the cloud" than to simply use a TCP connection between two devices that need to communicate. (And no, of course, you technically don't need a server, but in practice that's how people deal with the pointless complexity of HTTP.)

[photojosh]

I've just finished my first project using websockets. Coming from the embedded world and bare UARTs plus a little bit of C sockets, I found it hilarious that we've got so many layers to essentially do the same thing that I could do on an 8-bit microcontroller.

The critical difference? Speed of development. Websockets was so blindingly quick to get working. Haven't hit the edge cases yet though. If I were doing it with raw sockets I'd have to reimplement many of those layers and write a mobile app as opposed to a mobile webpage with only 300 lines of JS.

> Ever used HTTP for peer-to-peer communication? Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to. One of the nodes connects to a public server and has other private nodes connect to it. (300 lines of Python/Twisted)

[zAy0LfpBZLC8mAC]

> The critical difference? Speed of development. Websockets was so blindingly quick to get working.

Now, is that websockets or is that "not C"?

I mean, speed of development certainly is valuable, but I would think that same speed of development only needs little more than an 8 bit µC (or, for that matter, is even possible on an 8 bit µC if the memory size is at the upper end of the range).

> Sort of. They're peers, but one always acts as the server, I just haven't needed to make them true peers, but I could if I needed to.

But that's the thing: You could if you needed to. Instead of it just being the natural thing to do. Though I guess NAT also is part of the problem here, which is another of those idiocies of the "modern internet".

[photojosh]

> Now, is that websockets or is that "not C"? > Though I guess NAT also is part of the problem here, which is another of those idiocies of the "modern internet".

The second point answers the first. It is websockets rather than C, because the client is a random user on a mobile web browser.

Now if I could control the other endpoint and were it not for those modern idiocies, P2P could easily be done in C. The problem then becomes discoverability (if you're after true distributed P2P) rather than the actual communications.

(I did port the lightweight lwIP TCP/IP stack to a 16-bit microcontroller and custom RTOS many years ago...)

[milesrout]

It's not exactly super hard and complicated to get things working on a microcontroller though. In fact, the first time I did it, I felt it was so much simpler than all this complicated web stuff.

[photojosh]

It absolutely is! I love micro-controller development. It's you and the bare metal, not dozens of layers of abstraction that often feel like they're fighting you at every turn.

On the other hand, it's hard to impress with blinkenlights and basic motor driving.

I'm currently going through a phase of thinking on how I could apply functional programming theory and techniques to the next iteration of this embedded system...