weberc2

They’re fast moving relative to network latency and the error margins are small (off by a little is the difference between a kill and a miss).

RAM is billed by the hour (or minute?) by cloud providers, and it’s 1GB per process, not 1GB total. If you’re running 20 virtual servers, that’s 20 GB. Moreover, if you’re shipping a desktop app, it’s 1GB * number of licenses. Finally, the “it’s not worth tuning” argument proves my point—Java proponents will tell you that Java doesn’t need to consume that much memory—you just have to tune it, but no one tunes it because it’s too hard/not worth it.

This is really odd. One of the biggest criticisms of Java is that it consumes so much memory, for which the rebuttal is the JVM can be tuned to use less! But no one does this in practice, so I assume there must be a reason that renders the “tuning” argument to be penny wise and pound foolish. I.e., you end up giving up something more valuable in exchange for that lower memory value. It seems like these Java apologists are trying to give the appearance that Java competes with (for example) Go in memory usage and startup performance and runtime performance when in reality it’s probably more like “you get to choose one of the three”, especially with respect to the top level comment about how the AOT story deceptively requires hidden tradeoffs.

Good to know. Hopefully it works now.

Last I checked (maybe 6 months ago), it definitely _didn't_ support py3, although it was advertised. I thought I was doing something wrong, but there were half a dozen issues in the tracker that indicated it was critically broken.

I understand that "it should be simpler" is a pretty lazy criticism. It's been a while since I audited Bazel and friends, and I've forgotten which issues apply to which tool. Moreover, because of the awful state of the documentation and the messiness of the code base (or perhaps this is just standard quality for Java projects?), it's really difficult to tell whether any given issue is actually a fundamental shortcoming in the application or whether it's simply a knowledge gap.

As far as what I want, keep the starlark configuration file format; implement all rules as starlark libraries (such that no one needs to write Java to extend, and if you must write Java then for goodness' sake fix the plugin interface or document it better or something such that one doesn't need to be a core contributor to implement a plugin--perhaps this is fine for an enterprise audience, but it's not fine for my use case). The rules should call into a base `mktarget()` or similar that takes args like the target's ID (the package:target_name pair), a target type that identifies the code used to build the target, and a dict of args/params that are passed into the aforementioned code. The args/params can be an arbitrarily nested JSON-like type so long as the leaves are primitives (int, string, etc), references to source files, or other targets and all leaves (and transitively, the whole structure) must be hashable such that we can identify a given execution of the build.

Beyond that core operating model, the code and the user interface should be clean and well documented. Ideally, small and medium-sized projects shouldn't need to run it in daemon mode to get reasonable performance. This is important because a daemon running on local development machines introduces a larger maintenance burden (there's just more that can go wrong). Language-specific plugins (custom rules, whatever you want to call them) should adhere pretty closely to the conventions of the target language. Lastly, there should be good support for building toplevel artifacts--this means I should be able to build a whole CloudFormation package including lambdas, Docker images, etc just like I would build a JAR or a C++ binary.

I realize that those things are easy enough to say, but the devil is in the details. I've actually gone so far as to prototype the implementation, so I'm confident that those goals are achievable. Unfortunately, it's a pretty significant effort (mostly due to the breadth of project types/languages to support and the nuance/expertise required to support any of them), so I'm bound by free time. If anyone is interested in collaborating or discussing more in-depth, hit me up on Twitter @weberc2 or email me (username at gmail.com).

It pretty much does solve the versioning issue. “Latest, always”. The downside is the abysmal state of monorepo build tools. With multirepos, who updates the downstream repos’ dependency files (e.g., requirements.txt) when an upstream project releases a change? And is the policy “latest, always” or do you support N versions of every package? I would argue that the latter is insane at any scale, and the former leaves you dealing with dependencies manually (someone is updating the downstream repos’ dependency files when an upstream change is released) or you build automation that does it and you’re well on your way to implementing your own monorepo-like build tool.

Everything is hard, unfortunately.

There are tradeoffs both ways. With multirepos you likely have a dependency hell problem and you often have to submit and release several PRs for otherwise small updates. With monorepos, (if you want reasonable build times) you have to be able to determine what has changed and what needs to build (including tests, etc) as a result. This is technically true of multirepos as well, but the problem is pushed into git and manual process.

Having looked seriously at both options, I think the monorepo world is the right one, but it presently lacks good tooling to sanely model your dependency graph AND create custom build rules while still being affordable for small or medium-sized orgs. Git/hub simply isn’t designed for this kind of modeling and everything I’ve seen built atop it is either way too manual or a kludge. Maybe the “kludge” solutions are actually reasonable, but my confidence is low.

Bazel is the right idea, but it’s execution disappoints. The documentation is abysmal, last I checked they advertised Python 3 support, but it’s been broken for years with no signs of progress. Building custom rules also looked hopelessly complex (by which I mean, “not something our organization can afford to implement and maintain”) but maybe there’s some undocumented happy path that I’m missing out on? These things seem easy enough to implement. We’re using Pants right now, and for it’s many similar problems (bugs, documentation, poor code base, difficult extensibility), it at least does a passable job at building Python projects.

I’ve thought about it a fair amount, and I think it’s reasonable to build something simpler that might not meet Google’s use case, but would at least enable small and medium sized shops to play the monorepo game.

Yeah, I imagine the test is “do you need those things badly enough to dedicate a large portion of a team’s capacity”?

Presumably there are text formats which are both machine parseable and which are static? Or why not simply use the static subset of HTML?

The fact is that people are being dragged around mentally and emotionally, and telling tens of millions of people to just stop doesn't seem particularly likely to reverse the trend. This is a systemic problem and it demands a systemic response. That response could well be public education programs for processing fear mongering (if you can overcome the obvious political problems).

When the Tweet expresses some abhorrent view (like "she deserves to be treated badly because she is $RACE", terrorism apologism, etc) and it garners hundreds of thousands of likes and retweets, it causes me quite a lot of stress, doubly so if it comes from or is endorsed by major publications or political officials.

Arguably, I shouldn't feel stress for things so far beyond my control, but at the same time I have a vested interest in my community and its future (and if so many people feel this way, it certainly _feels_ like a credible threat).

> Ironically, one of Boehm's use cases is looking for memory leaks. You basically #ifdef Boehm into a test build, and if a GC finds garbage, you know that you didn't free something correctly.

So a "garbage checker"? :) This is interesting, I never really thought about using it as a checking tool.

Unless something has changed very recently, Go docs aren't story-format.

We tag each commit with the (JIRA) ticket ID. The ticket has the broader business context, and the commit message is generally shorter. There's still some gap between the one-line commit message and the ticket ID, but it hasn't really caused problems in our org to my knowledge.

If you account for engineering effort, Fargate is cheaper than EC2. No central logging or log exfiltration to configure, no bin packing apps onto AMIs, no SSH to set up or keys to manage, no configuration management, no process management to worry about, etc.

Just put your app into an image and write the CF templates for your cluster, services, and task definition and you’re good to go.

What are you comparing? If you’re comparing a large, HA SaaS use case with a static website on a VPS, then of course the latter requires less DevOps work, but if you hold the use cases equivalent, AWS requires much less DevOps work than bare metal. Notably, just because you’re using bare metal doesn’t mean the motivation for infra-as-code goes away; to the contrary, you need more of it because you’re now managing more services that come out-of-the box on AWS.

I've always been confused by the English definition of "carpenter". I always thought it was originally something like "woodworker" or a furniture smith, but it appears that most native speakers understood "carpenter" to mean "house builder". I wonder if at some time the same occupation referred to both or if I simply grew up misinformed?

I'm not taking a neutral stance. I don't understand the issue and I'm asking for clarification on one of the points. I'm not passing judgment on either position nor am I asking anyone to "justify themselves". What a bizarre accusation...

I'm not being coy, I don't know what the specific concerns are. I've been quite explicit about this.

In idiomatic English, "or" can imply a dichotomy as you suggest or an incomplete list, which was my intention. I wasn't thinking about the ambiguity when I wrote it, so that's my fault.

That’s not a dichotomy. It’s not an exhaustive list.

You're probably right. It's been a while since I had the misfortune of working with BT.

I want to keep this civil and perhaps learn something, but what is the specific objection with respect to complaints of detention? Do folks just want better detention conditions or are we advocating for giving citizenship to everyone who wants it?

EDIT: Why the downvotes? I'm asking a genuine question. How did I manage to offend?

Pretty sure you can change the name she responds to.

> any existing SBCs will need to be replaced/extended to support new type of network and due to bloated protocol specs with a myriad of abstraction levels will render it almost impossible to implement it on your own and the open source library that can do that will implement the standard as specified whereas all proprietary solutions will have some quirks and little differences from official standard making it very hard to connect to anything from your open source lib.

Whoa, is it really necessary to call BlueTooth out like that?

I don't see how you get "what he really means is ... all kinds of dark money republican activism" from "Mark is friends with Peter Thiel and a lot of Republicans". This seems like baseless conspiracy theorism unless you're privy to more information.

I’m not sure what point you’re making, if any. Care to elaborate?

I thought postwar America was known for investing in real estate to great wealth-building effect? I’m not sure how worthwhile other time periods are for comparison as our economy is so much different.

The cost per passenger per mile is two orders of magnitude lower for roads than for public transit; I can’t imagine parking space accounting for that.

I have a really hard time believing public transit could reasonably compete with the highway system with respect to return on investment. Consider how much food and consumer goods would cost without highway infrastructure never mind the secondary effects. Consider also that you would be making road travel prohibitively expensive for the lower classes.