Hacker News new | past | comments | ask | show | jobs | submit | pgwhalen's comments login

The Robinhood being discussed in this post is not a product, it's internal technology. The name clashing doesn't really matter.

There are near-infinite things they could name their software, but instead they copied an existing name of another software project.

Quite insufferable if you ask me.


Software developers who love their job generally are into fantasy worlds, RPG games, astronomy and whatnot. If we nitpick every name choice, then life will have no fun.

I have computers named after stars and galaxies. Some codenames of the applications I have developed myself has stupid connections to characters because of what they (the software) do are similar to characters themselves. I named a module "Scrat" because it was a state machine which changed thousands of states per second according to input it received from a file I/O module called Manfred (which carries things on his back or with its trunk).

I have my names clash with others, and others' names clash with mine. Who cares, it's fun and makes things enjoyable for everyone, plus it allows one to inspire themselves by setting a vision for their software.

Or, maybe we should start naming our software with UUID strings. That won't clash in a long time. :D


Why does every single thing need a unique name? Even trademarked names for businesses and products are scoped to business sectors - its why apple the computer company who took the name of apple the record label was just fine (until apple invented itunes and had to buy the record label).

Heck even code does scoped naming... the compiler can't really handle punctuation that is slightly wrong and even it allows me to reuse variable names in the same program.

I don't know why we'd need a univerally unique name for each piece of software ever created. The existing software called robinhood is unrelated to this load balancer, so even if I could download and use it, I doubt I'd have much of a problem distinguishing the two.


imo its your mindset that is quite insufferable, not the companies decisions of naming internal tooling.

> Why even consider ZK in 2024?

I'm no expert on these consensus-stores, but I guess my question would be "why not?" ZK is proven and works.


Great question

When one queries a table though, it's only query at one point in time. Querying a stream implies that your result set is a stream as well, which introduces a whole separate set of complexities to worry about both as an implementor of the query engine and a client.

I have the same question. Why should I care? It's not an extra cost to me, so the radiation would be the reason, but I assume it's quite minor.


I assume you mean it's covered by some sort of insurance (private or public) in which case you are paying for it you just don't really control how much you pay by individually opting in or out.


True, but dental insurance is so cheap relative to medical insurance.


If your teeth are in good health (no work done in years and none expected), paying out of pocket for dental appointments might still be cheaper. Though that assumes you could cover an unexpected expense - this is effectively self-insuring.


> Though that assumes you could cover an unexpected expense

Given how low the typical (non-DMO) coverage limits are for dental insurance, this is probably reasonable for many people.


> assuming even distribution

I don't work for Uber, but this is almost certainly the assumption that is wrong. I doubt there is just a single workload duplicated 2.1K times. Additionally, different regions likely have different load.


In my experience, as someone who has gone on a small weight loss journey, you can eat things that taste good, you just have to eat less of them and more rarely.


Weird, it seems to me the exact opposite is true. More and more people are spending longer periods in coffee shops and treating them as offices.


Ctrl-F for "Some motivations are as follows" under the "String view with short string optimizations" section here: https://docs.google.com/document/d/12aZi8Inez9L_JCtZ6gi2XDbQ...

Copying here:

> Having the 4-byte prefix directly accessible (without indirection through an offset into a separate data buffer) can substantially improve the performance of comparisons returning false. This prefix can be encoded with multi-column hash keys to accelerate aggregations, joins. Sorts would likely also be significantly faster with this representation (experiments would tell for certain)

> Certain algorithms (for example “prefix of string” or “suffix of string” — e.g. PREFIX(“foobar”, 3) -> “bar”) can execute by manipulating StringView values only and not requiring any memory copying of large strings.

This document was an early proposal for adding what is now called the StringView (and ByteView) types to the Arrow format itself.


Yes. It's not that the feature was previously known under a different name - Project Loom is the OpenJDK project, and Virtual Threads are the main feature that has come out of that project.


This comment is *not* an explanation of why the feature was problematic in its current form, and portraying it that way makes the JDK team look far more political than they actually are. The comment is just explaining why feedback from usage is better than comments just looking at syntax.

A sibling comment links to the actual technical discussion and reasoning.


I understand where you are coming from, but it is a very good signal for the team. The easiest way to get the desired feedback would probably be to adequately address to the current community concern.


It is very well addressed, in the right forum (on the OpenJDK mailing list). It's a bit uncharitable to cherry pick a reddit comment on a specific thing and portray that as the public messaging on the technical decision.

I want Brian et al. to comment more on reddit threads, not less, but this sort of interpretation is a reason for him not to.


I'm not taking a particular stance on the JEP. I am not sure what is being cherry picked. The comment explicitly called out the customers for creating antihelpful noise. In my eyes, that tells me there is deep value misalignment between the involved parties, which is worth reflecting on.


"We discovered, unfortunately quite late in the game, that the design was flawed."


That's an explanation of why the feature was pulled, not of why it was problematic in its current form.


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: