tylerchr

Why not you?

You could, but then you’ll have replaced a universal and standardized abstraction with a hard commitment to one very specific approach. That doesn’t come cheap.

> The only time I feel dumb in life...

I find that feeling dumb in life is one of life’s greatest opportunities!

No.

I thought copyrights protect literary and visual illustrations, but not any underlying processes, mechanisms, or artifacts they describe (patents protect those). My understanding of copyright law is surely flawed, and perhaps the “original work” standard means that only descriptions of systems are copyrightable and not the systems themselves.

In that case I agree that my examples fail. Keys and clutches are mechanisms and filling gas is a process, and those aren’t copyrightable (but they are patentable). The file format example fails too, because the concept of laying out data in a particular way is a mere idea, and ideas aren’t copyrightable either (they are also not patentable, though a description of the format is copyrightable and a specific process for reading or writing the file might be patentable if it were nontrivial).

You’re suggesting that Microsoft may choose not to crush WINE even if they had the right, because some other incentive holds them back. I think GP agrees, and is merely saying that Microsoft’s current philosophical beliefs would not likely be that incentive.

> That said there are ALL KINDS of interop code that is at risk with the ruling

Yes, there are parties that stand to lose a lot in the short term from a decision for Oracle.

But would it be so bad in the long term if proprietary vendor-specific protocols were put at a disadvantage? Maybe back-to-basics open protocols (or at least protocols formally contributed to the public domain) would resurge, and interoperability would actually _increase._

> Is {X} copyrightable?

Evidently yes, to the extent that {X} includes subjective properties that go beyond the fundamental function of {X}.

To use file formats as an example, the fundamental function of an archive file format is to bundle a set of otherwise-independent files together. A basic archive file format that simply concatenates file contents together (and I guess the necessary header to identify the boundaries between them) wouldn’t be copyrightable. But a more advanced format that includes an index of included files might be, since the addition of the index is a product of some artistry by someone who thought it would be a helpful convenience for users. [1]

Extended to the car example, “putting gas in tank” wouldn’t be copyrightable because no tank can function without gas. But improvements to the method of transferring that gas might be. Engaging a clutch is fundamental to the operation of a transmission and not copyrightable, but a clutch that is specially-designed to require less force might be.

The key is an interesting case though... I suppose I’d have to say that mechanism would have been copyrightable, since one could start an engine in ways other than a key (maybe a crank or a push button), or perhaps because the idea to couple the unlocking mechanism to the engine start signal was a clever idea rather than a fundamental necessity.

[1]: To my understanding, this is exactly the situation with “tar” and “zip,” though fortunately for us the “zip” format was contributed to the public domain rather than copyrighted.

> Google copied them so they would get access to the large developer community and ride the coattails of the successful investments into the Java platform that Oracle made.

I like this framing and think it’s entirely correct, but I don’t agree that it necessarily dooms the interoperability argument.

Google wasn’t trying to achieve compatibility with existing code (for which, you’re right, they’d have needed to take the whole set) but rather compatibility with existing developers. Arguably, that is still interoperability.

Very neat. I had a similar need recently which led to a similar solution[^1]. Notably, I used a syntax nearly identical to yours, albeit without the very handy pluggable validators yours has. Nice job.

What led you to choose “!” as the “optional” modifier? My intuition would have guessed that character to have the opposite meaning.

[1]: project: https://github.com/tylerchr/jstn/ — playground: https://tylerchr.github.io/jstn/

Awkward! Thanks for the tip. I added a copy of that post to the repo and fixed the link.

I undertook a similar endeavor a while back. My solution[1] rested on the observation that you don’t need to have a B-tree to do a binary search; one need only be able to calculate the correct byte offset of the Nth hash. With some optimizations, this approach produced a 9.9GB file with similarly fast lookups.

[1]: https://github.com/tylerchr/pwnedpass/blob/master/README.md#...

The thing that caught my attention about this post was specifically that it‘s a JavaScript bundler not written in JavaScript. The “in Go” in this case made the difference between my noticing and skipping a very interesting submission, so I think it’s relevant.

Though one-sided, that’s a well-reasoned and well-argued piece I had not seen before. Thanks for sharing it.

Disclaimer: I’m an active Mormon.

The Interstate Highway System, manned spaceflight, and National Parks come to mind.

That’s really reassuring to hear! Keep up the hard work, and I’ll keep an eye out for something in March or so.

Until then, where is the best place to look for updates?

I have been watching this group since its inception, waiting for something that I can treat as a standard.

They’re trying—and I am rooting for them—but from the outside it seems piecemeal and scattered, like a side project that is nobody’s real priority. Meanwhile, other initiatives have so much movement as to be unfollowable: Zipkin! No, Jaeger! No, OpenTracing! No, OpenCensus! No, OpenTelemetry!

I am beginning to doubt that we will ever have a standard for distributed tracing.

> This, according to a series of tests, has put Firefox on par with Chrome, in regards to power usage.

So still not awesome, but a round of applause to the team nonetheless. Not a small achievement.

Despite having spent the last two years working specifically on addressing the operational issues caused by a monolith, I couldn't find anything apart from the title and the implied pro-microservice premise in this post that I agree with.

A monolith's tests need not take all day to run. Features don't need to take weeks or months to ship—one can practice agile even inside a monolith. A monolith does not preclude the use of modern tooling—we adopted CI/CD and distributed tracing despite having a monolith, and use them to great effect.

In some cases scaling a monolithic codebase may be _more_ instructive about how to scale, because it's not as simple as "pay AWS more money and use more instances." Instead, you're forced to understand bottlenecks and consider how to solve them with algorithmic changes. Circuit-breaking is a critical feature in a monolith, even more so since one bad type of request could otherwise ruin the day for everyone.

The inability to "rewrite your business" has more to do with how well-architected your platform is than whether you have microservices. Both monolithic and microservices can be built well and built badly; a clean monolith is straightforward to rewrite the same way that cleanly-designed microservices are.

My personal opinion aligns with that of the author and greatly favors microservice architectures. But the usual hatred of monoliths strikes me as more dogmatic than well-reasoned, and I find this post to ultimately fail in defending its claim by falling victim to that.

I wonder, did you perhaps not read the linked article? If so I must have misinterpeted you.

By my reading, its author seems to share your frustration and wrote the post to answer your question.

This was a little disappointing to me; the paper[0] pitches as a design principle it’s efficiency and embeddability but it’s not clear to me how one could achieve this except in another JVM-based language. This is in contrast to the core fdb client library, which is ~easy to embed all over as it’s in C.

So it seems like services in languages like Go, Rust, python, node, etc are essentially forced to dream up a bespoke wire protocol and revert to the client-server approach. Am I missing something?

[0] https://www.foundationdb.org/files/record-layer-paper.pdf

I really enjoyed studying the BoltDB source[1], which is Ben Johnson's popular key/value store library. I found it to be clear, idiomatically written, and well annotated.

[1]: https://github.com/boltdb/bolt