Very interesting. We use Boost.Python to provide Python binding for Bond [0]. It works well but having something lighter weight would is great. One big issue with Boost.Python is long compilation times. Does your library improve on that?
There is a really interesting proposal to add reflection to the language: N4447 [1] (N3951 before). The idea is based on an observation that C++ already sort of has reflection-like syntax in form of parameter pack expansion [2]. I find this approach to be a very elegant and in the spirit of modern C++. It is also very powerful. Bond serialization is implemented using reflection. Because C++ doesn't have reflection, for normal classes we have to use code generation to provide type metadata. But for std::tuple<T...> all the necessary information is already available and Bond can serialize arbitrary instances of std::tuple<T...> today [3].
As another example, Firefox uses "manual reflection" to e.g. build lists of all the smart pointers in some classes. It then uses these lists as part of its "cycle collector", which breaks cycles in the refcounted graph of objects.
Writing and maintaining these lists is error-prone, and at least used to be a major source of memory leaks. You can imagine writing a static analysis to figure this out, and the Moz folks may have since I last checked, but if the language could do it, that would be so much better...
As a somewhat-related data point, Servo is already using the macro deriving infrastructure of Rust to generate these lists at compile time for its garbage collector.
It was in response to a comment that was referring to Firefox. Servo is touted as the eventual replacement of Firefox's rendering engine. It's literally a response to a comment about Mozilla's current practices in this area explaining their proposed future practices.
Reading through N4447, correct me if I'm mistaken, but it seems to be more about compile-time metaprogramming than it does runtime reflection? It does talk about class.for_name(std::string) but kind of handwaves about how it would work.
This got downvoted but I think there's more truth here than on much of the rest of the thread, though I might use words other than "engineering" and "craft". I'm fond of saying that Golang isn't a particularly great programming language, but is one of the great programming tools.
The way I read it, he meant that Go is not a great language. Go is "boring" as a language. However, it actually is a great programming tool. Great as defined by how long it takes to write module X, how well module X performs, how many bugs are in X, and how easy it is for a different programmer to come along and work on X later. In a real sense, the very design that makes Go boring is responsible for the good things.
This is an awesome point. I feel like programmers using Go care less about the language and more about the process of creating and maintaining a product.
I really dislike this description, which you see often in golang discussions because it implies either the people that prefer other languages are dilletantes focused on the wrong things, or the people who like golang are too stupid to use a more elegant language AND do product development.
I don't think either is true. What I do think is true is that every language makes trade offs and golang makes me less productive with it's choices & restrictions. I'm reserving judgement about how it impacts my teams aggregate productivity.
I have used SML, OCaml, Haskell, and many other languages, and I like Go, and use it for almost anything I do these days. So your statement is false. The only thing I did like more in functional languages was writing compilers (which ironically happens to be what I'm doing now in Go).
I didn't carry out a scientific study -- to my knowledge, no one is bringing any hard facts to the table when they talk about programming language preferences -- so you can't evaluate what I said as logically true or false.
For reference, I have used OCaml, Haskell, Golang and C extensively. I think Golang is a wasted opportunity to replace C. It's a mediocre language with a bunch of annoyances.
Indeed, ML was more advanced at the time of release, and has been improved since. However I won't blame C, since C was much more successful and (as Javascript knows well) it's very much harder to make changes to a language when you have to maintain backwards compatibility with a vast body of code used in production.
Microsoftie chiming in: Open offices "are the future" here. Some coworkers in other orgs still have single offices, but this is mostly legacy, unfortunately. You could probably get on a team that has single offices, but it'd be a dart throw, and you'd have iffy guarantees as to how long it'll last.
