HiJon89

> “Humans of course can drive with just eyes, so there’s that proof of existence,” he said. “If the goal were to just approximately match human performance or to build an assist product, that’s a very reasonable way to go.”

It feels like there's a lot of assumptions baked in here. For example, do humans get in accidents because eyes are insufficient driving sensors? Or because human drivers get tired, distracted, make mistakes, etc.

Also, you can put 10 cameras on a car looking in all directions at the same time, which feels materially different from a human that only has 2 eyes which can only look in a single direction at a time.

It's possible that massively superhuman driving performance can't be achieved with just cameras, but I'm not seeing a strong case for that being made here.

> Specifically, I think it would be perfectly cromulent to have JsonArray.of() be able to support any Iterable of native Strings, Integers, Doubles, or Booleans; that doesn't feel like feature creep to me at all.

What type would that method accept? Wouldn't it need to be Object? That seems worse than boilerplate

Using observed latency, power of two choices, and requests in flight reminds me a lot of Finagle https://twitter.github.io/finagle/guide/Clients.html#p2c-lea...

Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)

Really cool analysis and visualizations! Although there’s an interesting wrinkle with Mario Kart 8 + 200cc - most players don’t want speed over a certain level because you’re too fast to control. So rather than trying to maximize absolute speed stat you may want to minimize the delta from your optimal speed stat

My Plex lifetime pass is still going strong

> > Another common example is when you are implementing an interface method or overriding a superclass method

> This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.

I think this is already a risk when modifying interfaces or superclasses. For example, if you add a method to a superclass, a subclass might already have a method with the same name/arguments but different return type, which would break compilation.

A common example is try-with-resources where you don't actually need the resource and are just using it for the closing effect. For example, let's say you have a metrics library that allows you to time code blocks like so:

  try (Timer ignored = Metrics.newTimer("getOrders")) {
    return db.getOrders();
  }

Another common example is when you are implementing an interface method or overriding a superclass method, and your implementation doesn't need all the arguments. Would be great for the programmer to have a way to express this intent (to the compiler and to the reader)

This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.

One datapoint: searching our codebase for variables named "ignored" produces >1,000 hits. And probably an order of magnitude more unused variables that aren't named ignored.

What if your system is the one actually sending the emails (ie, you are the 3rd party in this scenario)

When do you record the message as processed? If you do it before the processing is complete, you have at-most-once delivery (because processing could fail after you've recorded it as processed, and it won't be retried). If you do it after the processing is complete, you have at-least-once delivery (because marking the message as processed could fail, and it will be retried).

What if the receiver process fails? How do you know which messages it processed successfully? You can shuffle the problem around indefinitely but it doesn’t go away.

If your processing doesn’t have any external side effects (make external API calls, send emails, charge credit cards, etc) then one option is to put your message queue in a relational DB alongside all your other data. Then you can pull a message, process it, write the results to the DB, and mark the message as processed all inside one big transaction. But not many use-cases can fit these constraints and it also has low throughout.

Thanks for making the previous poster’s point for them.

Thanks for the great writeup and the great work!

The fact that half the comments here are dismissive or condescending is such a sad indictment of HN culture :(

With 2 million users, I imagine it would be on the order of thousands of posts per day, and maybe hundreds of reports?

How would that work for something like S3 range requests? Rather than reading an entire object sequentially (which would work fine with transparent compression) you can also ask to read an arbitrary byte range (give me bytes 1,000,000,000-1,000,001,000 from the original file). I guess you could maybe store the compressed file in chunks with metadata about the original byte range inside each chunk.

There was a later tweet clarifying that an update (presumably over-the-air) was released in 2021 but for some reason not all devices received it.

Quote:

Now it seems an update was available and has been rolled out end of 2021. But many H5000 did not get that update and now, as the certificate has expired, this update cannot be installed in the usual way.

I expected the top comment on hackernews to be something this pedantic and irrelevant to the content, and I was not disappointed

  We don’t need to write a test that tests this function as a whole, we can test the parts we care about independently.

What could possibly go wrong :)

Limited driver assist? Are all the videos of people using Tesla full self-driving on YouTube fake?

Or maybe the sad state is that there are still people dying every day from a pandemic THAT WE HAVE A SAFE AND EFFECTIVE VACCINE FOR.

I had to read that sentence a couple of times but I think it’s just poorly worded. He’s not saying that the person is old, he’s saying that the reason for wanting to fire them “you are not doing a great job”, is a “plain old” reason

I think this misses the point, which is called out directly at the top of the site:

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency."

If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).

For some context, S3 used to provide read-after-write consistency on new objects, but only if you didn't do a GET or HEAD to the key before it was created. So this access pattern is all good:

  PUT new-key 200
  GET new-key 200

However, this access pattern would be unreliable:

  GET new-key 404
  PUT new-key 200
  GET new-key 200/404

This last GET could return a 200, or it could return a cached 404. Unfortunately, Maven uses this access pattern when publishing maven-metadata.xml files, because it needs to know whether it should update an existing maven-metadata.xml file or create one if it doesn't exist yet. So when publishing a new version, it does something like this:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200

And then downstream builds would try to resolve version 1.0-SNAPSHOT, and the first thing Maven does is fetch the maven-metadata.xml:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404

So when publishing a new version, you could get a cached 404 and fail loudly. However, when updating an existing maven-metadata.xml file you could silently read an old maven-metadata.xml, and end up using an out-of-date artifact (which is even more concerning). Here's what one of the maven-metadata.xml files looks like: https://oss.sonatype.org/content/repositories/snapshots/org/...

Because updating an existing object in S3 didn't have read-after-write consistency, we could have a publishing flow that looked like:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v2)

And then downstream builds would fetch the maven-metadata.xml:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)

So downstream builds could read a stale maven-metadata.xml file, which results in silently using an out-of-date artifact.

We ended up just switching to GCS because it was relatively straight-forward and gave us the consistency guarantees we want.

We used to use S3 for Maven artifact storage. This is mostly an append-only workload, however Maven updates maven-metadata.xml files in place. These files contain info about what versions exist, when they were updated, what the latest snapshot version is, etc. We would see issues where a Maven build publishes to S3, and then a downstream build would read an out-of-date maven-metadata.xml and blow up. Or worse, it could silently use an older build and cause a nasty surprise when you deploy. It only happened a small percentage of the time, but when you’re doing tens of thousands of builds per day it ends up happening every day.

We switched to GCS for our Maven artifacts and the problem went away.

Awesome, thanks for the response. Looking forward to trying out Sourcegraph again

Seems like this is in the works already, but the boolean operators in OpenGrok are so intuitive and powerful. I use them every single day and the lack of support in Sourcegraph immediately disqualified it for us. For example yesterday I was looking for Dropwizard Managed classes not annotated with @Singleton so I did:

Managed && !"@Singleton"

(I'm omitting the fully-qualified class name for brevity)

If I also wanted to look for HealthCheck classes I could update the query to:

(Managed || HealthCheck) && !"@Singleton"

I think it also helps that OpenGrok has a separate input for filtering file paths (completely splitting the "where" and the "what" parts of the query). And this file path search supports the same boolean operators. So if I want to narrow my search to two particular repositories I could put CrmSearch || AutomationPlatform into the File Path input. And because this input only handles file paths, I don't need to remember any special syntax. Whereas if you clump the entire query into a single input, then users need a way to tell you whether a search term applies to file paths or file contents.

For #5 I believe it's not just a self-XSS, but also executes on the support agents browser, allowing you to potentially exfiltrate their cookies:

> Anyone can write malicious code into the chatbox and PayPal’s system would execute it. Using the right payload, a scammer can capture customer support agent session cookies and access their account.

How about working to improve those take home projects since it seems to be more promising than the whiteboard interview which is doomed to suck. For example, my company has a take home project that involves hitting some APIs and doing some stuff with the JSON they return. It shouldnt take more than an hour and we give a time limit of 3 hours just so people don't spend days on it.

Engineers: coding exotic data structures on a whiteboard in a time-crunched interview is high-pressure and unrealistic!

...how about we give you a project that more closely reflects problems we solve here day-to-day that you can solve in the comfort of your home on your own hardware in whatever IDE makes you comfortable?

Engineers: That's absurd! I've drawn a line in the sand!

[Copying my reply from reddit]

I can give you some background on the way we structure things in case it's helpful. We use GitHub for our open-source projects, GitHub:Enterprise for our internal code, and our engineering team has about 300 engineers. Each project or feature usually lives in its own repository, and is split into a number of Maven modules. Using the maven-snapshot-accelerator ( https://github.com/HubSpot/maven-snapshot-accelerator ) as an example, it's roughly 1,000 lines of code split into 6 Maven modules (representing a small percentage of what my team owns). There's the root pom which just aggregates the other modules, a core module that contains the POJOs, a REST API module that uses the POJOs, a client module which uses the POJOs to hit the REST API, a module for the maven plugin, and a module for the maven extension. If this was an internal project, it might also have supporting Hadoop jobs, Kafka workers, Spark jobs, etc. depending on how the system was designed. Each of these would usually live in a separate Maven module. I'm not sure how much thought we gave to splitting into Maven modules along these lines, it just kind of seemed natural to us. It also has a few benefits compared to larger modules:

- The dependency trees are smaller, because you're pulling in a more focused set of libraries rather than the kitchen sink

- Our build infrastructure only builds what has changed when you push a commit, but it can only do this at Maven module granularity. So by splitting things up this way, pushing a change to your kafka workers won't rebuild your Spark or Hadoop jobs.

Using one of our larger open-source projects as an example, Singularity ( https://github.com/HubSpot/Singularity ) is split into 15 Maven modules (and represents maybe a third to a half of what that team is responsible for).

Snapshots vs. versions is a whole different topic and probably deserving of its own blog post. More generally, whether we should bend our workflow to the tools or bend the tools to our workflow is a constant tension and something we're always thinking about, so feedback is always appreciated.