skysight-inc/HackerNews huggingface dataset:
Easiest way to send data over the wire.

struct mytype s;
s.field1 = something;
s.field2 = something else;
send(socket, &s, sizeof(s), 0)

or, using a language with a good type system like Haskell

data MyData = MyData Int Int deriving Generic
instance Storable MyData

alloca $ \buf -> do
let d = MyData field1 field2
poke buf d
send socket buf (sizeof d)
https://en.wikipedia.org/wiki/Luddite

Same "fears" different century.
Google Play Music does let you download the album you purchased, at least. Then you can play it in whatever music player you like.
Scalar primitive fields in proto1/proto2 C++ generated code are not pointers. They are just class member fields returned by accessors (foo()) and their presence is indicated by a presence vector (has_foo()). At least that's what you get if you use Google's proto compiler.

The class layout for proto3 is the same (surprise!) but the presence vector is ignored.
Nepotism:

"the practice among those with power or influence of favouring relatives or friends, especially by giving them jobs."

https://en.oxforddictionaries.com/definition/nepotism
So, does this have knockon effects for mall stores? Lots of malls with one less anchor, after the ripple effects go through. I realize bankruptcy does not always mean everything closes, but in this case I think a lot of it does pretty soon. Many malls are already on the edge, I think this could be a problem.
To be fair, in C++ you could use std::optional or something else that's type-safe.

Go has its own philosophy about zero values which is controversial, but at least with pointers you do get to express optional values. And it's not like you can't work around the ergonomic awkwardness that arises:

type Post struct {
Title *string
}

func (p *Post) GetTitle() (string, bool) {
if p.Title == nil {
return "", false
}
return *p.Title, true
}

func (p *Post) SetTitle(s string) {
p.Title = &s
}

Hardly elegant, but this is Go.

Go also run into the same issue when encoding and decoding JSON. Most languages do distinguish between empty string and a missing string, but not Go, which makes it hard to validate anything. I wrote a code generator for JSON Schema [1] recently, which applies validations while deserializing, and has to resort to a rather low-tech trick to do so:

type Post struct {
Title string `json:"title"`
}

func (v *Post) UnmarshalJSON(b []byte) error {
var raw map[string]interface{}{
if err := json.Unmarshal(b, &raw); err != nil {
return err
}
if _, ok := raw["title"]; !ok {
return errors.New("field title: must be set")
}
type plain Post
var p plain
if err := json.Unmarshal(b, &p); err != nil {
return err
}
*v = Post(p)
return nil
}

(Clearly there are slightly more refined and faster ways to do this, but not that easily without importing third-party code, which I wanted to avoid.)

C and Go are in the minority here. This doesn't come up in languages like Rust, Swift, TypeScript, Nim, Haskell, OCaml, C#, F#, or Java >= 8, all of which have some sort of optional support (algebraic data types or built-in). For example, TypeScript:

interface Post {
title?: string
}

Or Rust:

struct Post {
title: Option<&str>
}

[1] https://github.com/atombender/go-jsonschema
Despite 'The unreasonable effectiveness of RNNs', it's seeming CNNs and the solely attention-based models are managing to perform the same tasks, but with better results and faster speed!
These objections are interesting. I have mixed opinions on protos, I think overall I'm mostly in favor. I'm a bit confused by this set of objections though.

While oneof fields cannot be repeated, oneof fields can be arbitrary protos, so they can contain repeated fields. In other words, you can have a (pseudo-proto)

oneof {
RFoo {
repeated Foo;
}
RBar {
repeated Bar;
}
}

so in practice this isn't a restriction. If anything, its a (very minor) api wart.

As for maps, I'd say don't use them. I have, I don't think they're very useful, except for prototyping things. `repeated (string key, string value)` is just as useful for prototyping things, and you should be quick to promote things to fields. Optional fields aren't costly.

I'm also in the minority who thinks that the `has_foo` methods are a smell, and everything should always be set to a default value[0]. If it really matters, one can define a maybe type via a oneof, but that should be the exception, not the norm. Most people disagree with that though, so maybe I'm crazy and you should ignore me.

[0]: But if that's not the case, everything should be optional, nothing required.
Google's annual revenue was $110 billion in 2017 [1]. Even if headcount doubled and salary has increased, that's $7 billion a year. That's not peanuts, but at a company level it's not a massive expense.

[1]: https://www.androidauthority.com/alphabet-q4-2017-earnings-8...
Many of the restrictions are there because you need to operate as well as you can at the intersection of all target language type systems.
Well as the person I was replying to points out, this is uncomputeable in general (`someUnknownCondition` might be brute-forcing all possible mathematical proofs to see whether the Reimann hypothesis is true), and I would expect optimizing compilers to already handle this in the cases where it is feasibly computable. Is that not the case?
Yes, but it's too simple. Consider:

a = { x: [1, 2, 3], y: [1] }
... (a.y used, but a.x not used)
Sure, so here's an example. You've got this cert for api.example.com that's got "Symantec" branding on it.

So it's issued by "Symantec Class 3 Secure Server CA - G4"
and that cert chains back to a root named "VeriSign Class 3 Public Primary Certification Authority - G3"

Well all that stuff is tainted so it's going away, right? Yup. But maybe your client checks for a pin to that "VeriSign Class 3 PPCA - G3" stuff so you need that!

DigiCert have your back, since it's being distrusted anyway there's no problem having their "DigiCert Transition Root G3" signed by that VeriSign root and that can issue its own Intermediate which they can keep online to sign for you.

So now the certificates aren't issued by the tainted Symantec systems, but your client trusts them.

They also have a bunch of brand new intermediates with the old branding, for cases where you need the branding to match (Yes, I know, that's cosmetic, but eh...) but the cryptography is all fresh.

You definitely should talk to DigiCert people about the specifics of anything you need, rather than take advice from random people on Hacker News like me, but for most scenarios they will either be able to advise you on how to transition safely to something that stays trusted in the Web PKI, or how to transition to something that's maintainable off the Web PKI.

The scenario they can't help with is if you need stuff directly (not via an intermediate) signed by old Symantec roots. That wasn't even supposed to be happening when Symantec existed, and in fact one of the smaller items taken into consideration when deciding to distrust Symantec was that they weren't able to resist plaintive cries (doubtless accompanied by hard cash) by banking customers who asked for this to be done even though it was forbidden.
The tax system and H&S rules are not such a big issue. They are different in the US as well.
The language is an issue and without a common/EU language or some tech innovation there is no way to fix it completely.
The value of large corpora for translation may be diminishing.. In particular, Facebook have achieved impressive results using unsupervised ML for translation: https://code.fb.com/ai-research/unsupervised-machine-transla...

The basic idea is to use word vector embeddings to build a source<->target dictionary, then combine this with a language recognition model to iteratively bootstrap a set of source<->target training examples for use with a conventional ML approach.
If all fields are required, you cannot have middleware that processes multiple versions of the same protobuf, and every application has to be updated when a field is added, even if they do not use that field. This is one of the more important design goals underlying not only protobufs, but most of the non-language specific binary formatters.
Funny reading this after the protobuf rant. Seems like serialization would be a nice feature to add as well.
I think I'm neutral over a 1 week timescale, short over a 1 year timescale, long over a 10 year timescale, short over a 50 year timescale.
Ya I honestly have no idea of what every individual in their family has achieved but I guess James is up to bat for Tesla, I hope he can make some positive reforms in the work culture as well as keep working to increase the market share of electric cars
Yet protobuf is probably the most compact, efficient and performant serialization method especially when saving bandwidth is important. I experimented with protofbuf, flatbuffers and messagepack and always found protobuf messages the most compact by a noticeable margin
JSON/custom binary format + HTTP2?
Libertarian socialism? So a minimal govt that owns all the means of production?

My head just exploded.
I am talking about the .NET Core debugger, see https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...
> That union, however....

Exactly. All unions become "that union" when given enough power and influence.
Mono is not .NET Core.
Almost every board has some sympathetic board members. Very different story for that person to be chairman.

Especially when the intent of the SEC agreement was that there was to be objective oversight of Musk.
> That way everyone who interacts with your service can decide how they want to represent that structure.

Protobufs aren't a message format for publicly specced standard wire protocols. They're a serialization layer for polyglot RPC request and response messages. The whole point of them is that you're transporting the same typed data around between different languages, rather than there having to be two conversions (source language -> "standard format"; "standard format" -> dest language).

In this sense, they're a lot like, say, Erlang's External Term Format—driven entirely by the needs of an RPC-oriented distributed-computation wire protocol, doing interchange between nodes that aren't necessarily running the same version of the same software. Except, unlike ETF, Protobufs can be decoded without the backing of a garbage-collected language runtime (e.g. in C++ nodes.)

I'm not saying Protobufs are the best, but you have to understand the problem they're solving—the "rivals" to Protobufs are Cap'n Proto and Thrift, not JSON. JSON can't even be used to do a lot of the stuff Protobufs do (like talk to memory-constrained embedded kernels running on SDN infra.)

> and Protobuf doesn't contaminate your codebase

Just like in HTTP web-app codebases, a codebase properly designed to interact with an https://en.wikipedia.org/wiki/Enterprise_service_bus will tend toward Hexagonal architecture—you have your own logic, and then you have an "RPC gateway" that acts as an MVC system, exposing controllers that decode from the RPC format and forward requests into your business logic; and then build responses back into the RPC "view" format.

Once you have that, there's no point in having your application's parsed-out representation of the RPC format be different than the on-the-wire RPC format. The only thing that's touching those RPC messages is your RPC gateway's controller code anyway. So why not touch them with as little up-front design required as possible?
You should definitely also look at Cap'n Proto – it is in many ways a theoretically more elegant design: far less overhead and the "time-traveling" RPC design is quite clever. Another potential important advantage, esp for crypto could be that Cap'n Proto in theory has a canonical representation, but in practice this was neither fully defined nor usable last I looked.

Cap'n Proto also suffers from a number of practical disadvantages, which can be quite severe depending on your use case. The main problem is eco system maturity and rate of adoption. So whilst protobufs have excellent cross-language support and a mature RPC system, in cap'n proto everything but C++ feels at bit second class, even other popular languages. Python and Rust, and I believe Java have workable, but not necessarily great bindings for serialization and in theory RPC, but the RPC support for other languages than C++ didn't look that great last I looked (but that was over a year ago) and even with C++ it looks much easier to get something going with gRPC (tooling, http2 based etc). For other languages I looked at (e.g. Ocaml, Lua and Haskell) the bindings looked very immature. There are a few other minor annoyance with capnproto, such as the lack of a timestamp type (you can build your own, incompatible to everyone else's, but this is still an annoying omission). The C++ library is also saddled with the weird home-grown kj library that no one other than Kenton Varda uses. However, it has to be said that the C++ API and also the Python API for Capnproto feel a lot more natural and idiomatic than the protobuf ones. If protobuf is too high overhead for your use case and you don't need the wide language and eco system support, Cap'n Proto is worth a serious look.
Where something like JSON or (if you must) XML is used I prefer the idea of REQUIRING the preservation of all fields in the original structure UNLESS a field or set of fields is validated and then updated in place.

This lets end users and extension authors do things that make sense, such as adding a comment tag ( JSON added key:value "__customcomment": "Any well formed string will be safe here." or XML <!-- Please don't eat me when parsing the config! --> ) to a configuration file stored in either format, and actually having it persist.
Although prototyped in Prolog, Erlang borrowed heavily from an obscure language called Strand.

https://en.wikipedia.org/wiki/Strand_(programming_language)

https://www.amazon.com/Strand-New-Concepts-Parallel-Programm...

I have a copy of the book, and the code samples are really similar to Erlang.
This is also the case in Boulder, CO. In addition to that, each truck is required to install a fire suppression system that start around $3,000.
This sounds like it likely isn't so. Clearly, for any disaster, there will be a certain amount of the things this article tries to suggest won't be.
Ring programming language – Version 1.9 is released
> Go knows that doPerson can't modify person so it is free to allocate the variable on the stack

Escape analysis does not care about modification. It only cares about whether the scope of the variable may end up expanded past the end of the function. Whether that scope is read or write is not relevant.

Causes of escape would be returning the value from the function, referencing the value in a closure, or using a reference to the value in a context with a different lifetime (channels, structs outliving the function). Calling a function with an argument as reference is not a cause of escape.

Escape analysis is tricky and fragile. Go often has to bail out to the heap.

Also, you don't really pass around structs by value much in real code, so the point that this is a benefit to GC performance is kind of moot.
The money saved gets taxed twice: as corporate income and then when distributed to shareholders again as individual income. It likely gets taxed at a higher rate, actually, because the income tax rate of the workers this replaces is probably very low but the rate of the company + the individual could easily be 60%.
http://www.hnreplies.com is a great solution for this. Been using it for a while, works perfectly usually with a few minutes of lag.

IMO this should be a core feature. But I’m just happy to have something that works.
"GC: a simulation of a computer with an infinite amount of memory."

This is not a correct definition.
Well that's just dumb. Taxpayers are subsidizing TWU -- actually paying for absolutely nothing in return.
Hi there,

I'm an actual author of Protocol Buffers :)

I think Sandy's analysis would benefit from considering why Protocol Buffers behave the way they do rather than outright attacking the design because it doesn't appear to make sense from a PL-centric perspective. As with all software systems, there are a number of competing constraints that have been weighed that have led to compromises.

- D

P.S. I also don't believe the personal attacks to be warranted or productive.
Half a decade ago, Rust 1.0 didn't exist. The language was explicitly unstable.
I spent 2.5 years at Google, and most of what I did was pushing one protobuf from one place to another :) - and I loved it... Honestly though, you can complain all day, but some of the decisions made in the list you presented most likely come from experience (daily) not as a user of protobufs (which I simply was), but someone that had to support a plethora of compression formats, how protobufs gets stored in the different databases, proxying, etc. etc.

Your "oneoff" and "repeated" might've been (I dunno really), a decision based on metrics where encoding repeated oneoff would've cost more, or made problems, more testing, or who knows what.

For one, Google was, and I believe still is open to discussing all kinds of matters, and you can get on to a design doc and comment if you like, if you care, if you have something to say... You can definitely influence, and people really did talk (you can even experience this from their public design docs - like from chromium, etc.).

And I love protobufs, so I guess I'm biased...
C doesn't make struct memory layout guarantees, endian guarantees, or size guarantees in some cases, so unless you're running the exact same binary this is a very poor serialization technique.
This article sounds like some sort of propaganda. In an emergency situation, people obviously will do extreme things.
They certainly can leave them empty. There are ~20,000 vacant units in SF where the owners have determined it’s cheaper to keep them empty than rent them out.[1]

They either keep them as second homes or hold as an investment (no tenant means when they sell the price isn't depressed).

If real estate is appreciating 10% per year and you own a $2M home, that's $200K in appreciation each year. Sure, you might get $60K per year if you rent it, but if you have rent control, you'll never be able to sell it at market rates.

[1]https://sf.curbed.com/2017/7/12/15961486/sf-tax-landlord-hom...
This may be easy, but it’s wrong. Endianness issues are just the start. Information leaks due to padding are a big deal. And it straight up doesn’t work if nontrivial data structures are involved.
Sure that makes sense if you can write off C++ as a "legacy" language, which is fine if you just can't get your mind wrapped around the scale at which Google operates. Due to the nature of weighted averages, you can't just write off something as being a "Google-only problem". Google and its peers like Amazon and Facebook own a very large fraction of the world's computing resources.

I think the overall mistake you and the author are making is assuming it is desirable for one program examining an encoded message to respect the type system of the program that produced it. That assumption is not obviously correct. The flexibility to just treat a vector of numbers as a vector of numbers, or to skip it, or ignore it, etc are pretty important in practice. That is why protobuf is defined at the level where it is defined. It encodes numbers and strings on the wire. It happens to be a fairly good way to represent search data. It brings no CS academic wankery to the party. It's very practical.
I guess if you know the dating techniques, you know how to fool them. Kinda test-driven development.
An approach I've used on the Go side is to build nice native Go types and converters to/from proto representations for wire marshaling. There's a minor performance hit but it's insignificant for what I'm doing. The result is quite nice, and you can largely ignore protobufs except for defining service APIs (which it's actually decent at).

Which tool are you using for TypeScript protobuf code generation? This is the next step for me, and I'd be keen to hear more of your experience there.
Samsung is going mass production with their EUV in Q1 or 2 in 2019. I'm also speculating that Qualcomm's next SD would be made by Samsung LSI. How does it compare to TSMC?
These hacking groups could target the 2018 midterm elections
So what if they do look in Apple's datacenter?

Are we supposed to feel sorry for or worried about the fate of one of the world's richest companies?
The thing is, hurricanes are remarkably not deadly compared to the scale of social change that preventing climate change would require.

For example, in the currently worst recent hurricane years, cars killed something like 10 times more people in USA than these hurricanes. If we got people to drive half as much (which would help but not be sufficient), then the most impact on deaths and injuries would come directly from the change in habits, not from the effect on global warming.

If we're not willing to drastically reduce driving so as we'd save some of the 40000 USA road vehicle deaths/year (and we're obviously not), then why would we be willing to drastically reduce emissions just to save some of the 2000-4000 hurricane deaths/year?

The same goes for massive flooding. OK, Bangladesh will plausibly get many deaths from the sea level rise. USA? Not so much; it can probably afford a massive infrastructure investment to do Netherland-style dams for all densely populated coastal areas.
How do you handle binary rollbacks and rollouts safely with an "everything is required" approach? Do you force binaries to roll out in a strict order with appropriate soak time at each layer? How does that affect developer velocity?
It's not just passive pickups, it's all analog signals. Analog signals can degrade quite a lot of a run of shitty cable.
America tears itself apart over what did or didn’t happen at a high school party in May of 1982 while the once and future most powerful country in the world marches further in neutralizing all advantages we once had in knowledge economies.