> Because historically this has been found to be the most critical issue killing nations.
This sounds tautological, like "stable states are stable". There are many stable states that don't have term limits on their head of state, and there are many unstable states with 4-6 year presidential terms.
Democracy-as-in-term-limits is a relatively meaningless historical indicator. When political stability is threatened, term limits are swiftly discarded. When the military junta is stabilized, it may introduce term limits to justify its reign (while actively filtering viable candidates).
> ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility.
After working heavily with SNMP across a wide variety of OEMs, this flexibility becomes a downside. Or SNMP/MIBs were specified at the wrong abstraction level, where the ASN.1 flexibility gives mfgs too much power to do insane and unconventional things.
I've been working on and with Kerberos and PKIX for decades. I don't find ASN.1 to be a problem as long as you have good tooling or are willing to build it. The specs are a pleasure to read -- clear, concise, precise, and approachable (once you have a mental model for it anyways).
Of course, I am an ASN.1 compiler maintainer, but hey, I had to become one because the compiler I was using was awesome but not good enough, so I made it good enough.
Here's the problem though: people have used the absence of tooling to justify the creation of new, supposedly-superior schemas and codecs that by definition have strictly less tooling available on day zero and which invariably turn out to be worse than ASN.1/DER were in 1984 because the authors also refused to study the literature to see what good ideas they could pick up. That's how we end up with:
- PB being a TLV encoding, just like DER, with all the same problems
(Instead PB should have been inspired by XDR or OER, but not DER.)
- PB's IDL requiring explicitly tagging every field of every data structure(!) even though ASN.1 never required tagging every field, and even though ASN.1 eventually adopted automatic tagging.
- PB's very naive approach to extensibility that is just like 1984 ASN.1's.
It's a mistake.
Some people, when faced with a dearth of tooling, will write said tooling. Other people will say that the technology in question is a nightmare, and some of those people will then go on to invent a worse wheel.
I'd be ecstatic to use something other than ASN.1 if it wasn't a poor reinvention of it.
Protobuf ended up having more tooling in the end though, and it didn't take very long to get there. This is like how JSON replaced XML for many use cases.
If they had put the same energy towards building tooling for an existing IDL/codec then they would have had strictly less work to do. Besides being inefficient in the use of their resources they also saddled us with 15th system (probably more like a 25th system, but you get the reference), and a poor one at that. There is really nothing much good to say about PB.
Yes, it's about a lot more than that. It's about automatically and recursively encoding/decoding through "typed hole". A typed hole is where you have a struct with one field that denotes the type of the other, and the other is basically a byte string whose value is an encoding of a value of a type identified by the other field. Typed holes are surprisingly common in protocols. Typically you first decode the outer value, then you inspect the typed hole's type ID field, then you decode the typed hole's value accordingly, and this is code you have to write by hand. Whereas with automatic handling of typed holes just one invocation of the codec is sufficient (as opposed to one codec invocation for the outermost value plus one invocation for every typed hole).
Why isn't the other value just a oneof? I get if your holed value is passthru data encoded in some special way that isn't standard asn1 or proto, but at that point it's heavily application-dependent and not really the outer protocol's job to support.
You can do CHOICE in ASN.1, yes, and you can even make it an extensible CHOICE. In that case the tag is the type determinant, and it looks a lot like a typed hole. But! sometimes you want a typed hole where the type determinant is something like a URN, or a URI, or some other type where the value space is a) large, and b) structured so you can avoid needing a registry. And sometimes the protocol you're writing inherently can't have a type registry -- think of an RPC layer where you have headers that provide things like authentication and negotiation of things, session-like things, while the application provides the procedures (the 'P' in RPC) and so you need to identify the application without a registry of oneof tags.
This was the main reason. The asn.1 language has a ton of unnecessary features that make it harder to implement, but the stuff I dealt with was using those features so I couldn't just ignore it. I didn't write a compiler but did hack
around some asn1c outputted code to make it faster for our use case. And had to use asn1c in the first place because there was no complete Rust asn1 compiler at the time, though I tried DIY'ing it and gave up.
I also remember it being complicated to use, but it's been too long to recall why exactly, probably the feature bloat. Once I used proto3, I realized it's all you need.
> The asn.1 language has a ton of unnecessary features that make it harder to implement
Only if you want to implement them. You could get quite far with just a subset of UNIVERSAL types, including UTF8String, SEQUENCE/SET, SEQUENCE OF / SET OF, etc. There's a ton of features in x.680 you can easily drop.
I've implemented a subset of x.681, x.682, and x.683 to get automatic, recursive decoding through all typed holes in PKIX certificates, CRLs, CSRs, etc. Only a subset, and it got me quite far. I had a pretty good open source x.680 implementation to build on.
This is the story of how Heimdal's authors wrote its ASN.1 compiler: they wanted tooling, there wasn't a good option, they built enough for PKIX and Kerberos. They added things as they went along. OpenSSL does not-quite-DER things? Add support in the Heimdal decoder. They hacked a lot of things for a while which I later fixed, like they didn't support DEFAULT, so they changed DEFAULTed members to OPTIONAL, and they hacked IMPLICIT support, which I finished. And so on. It still doesn't have things like REAL (who needs it in security protocols? no one). Its support for GeneralString is totally half-assed just like... MIT Kerberos, OpenSSL, etc. We do what we need to. Someone could take that code, polish it up, add features, support more programming languages, and make some good money. In fact, Fabrice Belllard has his own not-open-source, commercial ASN.1 compiler and stack, and it must be quite good -- very smart!
Json doesn't support comments specifically to not allow parsing directives, that means less customization. More customization of interoperability protocols is not always a good thing.
> It is seen as more and more normal to track one’s partner through Find My iPhone or an AirTag, even though the potential for abuse of this technology is staggering and obvious. There are all kinds of new products, such as a biometric ring that is allegedly able to tell you whether your partner is cheating, that expand this capability into more and more granular settings.
These criticisms seem to be more a reflection of the author's paranoia and sex-obsession than legitimate criticisms of the tools and technologies.
IMO, location sharing is pretty awesome among loved ones, and biometrics can help us manage our health? But I guess everything has to be about "sexual surveillance"...
Location sharing is extremely divisive. Loved ones need privacy too, in my eyes. But we are also clearly in time where that kind of tech can save their lives so I don't want to dismiss it all as goverment surveillance.
But my parent use it, so it's clear it depends on the couple.
"Just build/produce more" (abundance) sounds fantastic if you are part of the upper classes who have been on the right side of wealth inequality trends. It allows us to avoid the issue of inequality. Just grow the pie!!
But surely you can see how this agenda is not appealing to most Americans who have been on the wrong side of wealth inequality? Even if you double the size of the pie, how do you convince them that their proportional slice of it won't halve in the same period? Because that HAS been their experience so far in the past ~50 years.
We do need to build more, but that has to also come with reform to be politically viable.
I'm not sure a simple citation to the law of supply and demand can count as "bad faith"? I genuinely don't understand your argument, which is why I called it incoherent.
You genuinely don't understand that <median real wages have been stagnant/decreasing for decades in USA, particularly in relation to skyrocketing housing/education/medical costs? Do you have any situational awareness of what just happened politically in NYC?
I would assume users engaging in economic debate on HN would have a knowledge of the basic economic facts and trends, and not dismiss them as "incoherent".
This level of derangement pervades the housing discourse from the left, and it's best to ignore it. At best you will argue in circles forever. At worst, you will be called a fascist bootlicker, etc.
People with normal mental health agree that having enough homes for all the people is a precondition of considering the housing problem to be "solved".
Whoah, this degree of incivility also not helping the case I want to make here!
I agree with pretty much everything you've said on this thread, which makes it all the more important to me it be expressed persuasively and not angrily. Remember: you're not just writing to the person you're responding to, but also to everybody else who reads the thread. Trust readers to spot inane arguments, if you perceive them to be coming up!
Griefers ranting about years old _closed_ tickets on v1.0.5 versions on a blog as some sort of proof of lameness... is a poorly structured argument. Julia includes regression testing features built into even its plotting library output, and thus issues usually stay resolved due to pedantic reproducibility. Also, running sanity-checks in any llvm language code is usually wise.
To be blunt: Moores law is now effectively dead, and chasing the monolithic philosophy with lazy monads will eventually limit your options.
Languages like Julia trivially handle conditional parallelism much more cleanly with the broadcast operator, and transparent remote host process instancing over ssh (still needs a lot of work to reach OTP like cluster functionality.)
Much like Go, library resources ported into the native language quietly moves devs away from the same polyglot issues that hit Python.
Python threading and computational errata issues go back a long time. It is a popular integration "glue" language, but is built on SWiG wrappers to work around its many unresolved/unsolvable problems.
Not a "smear", but rather a well known limitation of the language. Perhaps your environment context works differently than mine.
It is bizarre people get emotionally invested in something so trivial and mundane. Julia is at v1.12.2 so YMMV, but Queryverse is a lot of fun =3
reply