01:40 <viaken> To be fair, Ada has some good ideas behind it.

01:41 <viaken> If you're going to entrust lives to software, you want something with as many safeguards.

07:04 <tankf33der> https://learn.adacore.com

07:21 <Regenaxer> My experience is the more a language "protects" the programmer the less he thinks by himself, with a less "safe" total outcome

09:28 <tankf33der> huge.l passed on latest pil64 snapshot

09:30 <Regenaxer> Good

18:16 <beneroth> hi all

18:16 <beneroth> Interesting log

18:16 <beneroth> Congrats to the fixed bug, nasty namespace-arithmetics

18:16 <beneroth> <Regenaxer> My experience is the more a language "protects" the programmer the less he thinks by himself, with a less "safe" total outcome

18:16 <beneroth> one for the book

18:16 <beneroth> tankf33der, thanks for the diff

18:24 <razzy> beneroth: i would add, that safe code is code more thinked through. there is sweet spot for amount of cooperating programmers that make safest code.

18:40 <beneroth> razzy, T

18:43 <beneroth> or to word it differently: there is a sweet spot for the size of a single unit of software that can be kept safe (whatever that might be - a module, a single function - a contained piece of code with limited surface/interface to other code)

18:52 <razzy> good wrap-up. i would also say, there is sweet spot for size of a group that could robustly optimize to "whatever"(safety included)

18:53 <beneroth> T

18:57 <razzy> goes without saying, that size varies for different types of goals and different people(some are more productive than others)

18:59 <beneroth> maybe. but the point of the saying is that there IS a upper limit

19:00 <beneroth> I don't think this limits the overall scope, but makes divide and conquer a requirement.

19:02 <beneroth> similar Microservice approach, just without overlooking that adding async and networking with all its failure modes is actually a huge increase in interlinking/scope of functionality/api surface which usually ruins the whole thing again.

19:04 <beneroth> e.g. in this framework (what we discussed above), the state-less nature of HTTP is a big simplifying feature (reducing scope of potential states, reducing api surface), even when it's often tried to add statefullness to it

19:27 <razzy> i like http for stateless reason.

19:34 <beneroth> I'm sceptical if HTTP/2.0 will be an improvement

19:35 <beneroth> proper used/implemented HTTP/1.1 pipelining might have been better

19:36 <razzy> idk what do you mean by pipelining

19:38 <razzy> some comprimation and predictive cache-ing would be nice

19:43 <razzy> isn-t there http 5 already?

19:45 <beneroth> no

19:45 <beneroth> that's html

19:45 <beneroth> http is the transfer protocol. see http://jmarshall.com/easy/http/

19:48 <beneroth> http/1.1 is current. http/1.0 is still in used and supported by http/1.1 compliant servers. biggest difference is that in http/1.0 a single webserver (IP + port) only ever serves one single website (host,domain) while a http/1.1 webserver may serve multipe websites (usually called "virtual hosts"). http/1.1 has an additional header in the request declaring the host.

19:49 <beneroth> http/2 is a proposal for a new http standard which will not be a simple extenstion of http/1.1 but a complete new protocol with various changes, e.g. requiring HTTPS always, server push, additional compression, ...

19:49 <beneroth> https://en.wikipedia.org/wiki/HTTP/2

19:50 <razzy> more is sometimes less

19:52 <beneroth> https://en.wikipedia.org/wiki/HTTP_pipelining is an addition to HTTP/1.1 which allows the client to send multiple requests to a server without first waiting for the response. so it allows quicker interaction between client and server. most browsers implemented it once, but also disabled it because most servers do not support it.

20:01 <razzy> if you have planetary computer ecosystem, you should take things slowly

20:02 <razzy> maybe once a year make one change on most bad system

20:10 <beneroth> the bigger problem than HTTP is TCP

20:10 <beneroth> TCP has some pretty clever algorithms to be resilient against traffic jams

20:13 <razzy> why is TCP bad?

20:14 <beneroth> but it's basically unchanged since the 90s, broadband connections were not expected, so today’s high-volume traffic (basically youtube/netflix streams, not much else, but those are the biggest part of the current traffic load) hit limits within TCP.

20:14 <beneroth> TCP is not bad, it's absolutely amazing

20:15 <beneroth> basically, TCP increases package send rate as long as it gets confirmations that the packages were received. when packages get lost, package send rate is slowed down at once (because a traffic jam / congestion / or bottleneck is assumed)

20:17 <razzy> streams should be handled with UDP and some clever algorithm up top on that

20:17 <beneroth> makes it extremely resilient against bottlenecks, be they permanent on some routes or sudden failures/takedowns of some nodes

20:19 <beneroth> but for high-volume traffic the slow-down (triggered by (I think?) one lost package) is nowadays too strong, resulting in an artificial limit below the actual physical capacities of the route

20:23 <razzy> and?