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

Honestly... I love it.

The whole website is just aggressively bad. The C suite cube faces, ugly color palette, spinny cube complete with a Jay-Z curated soundtrack, the misaligned text & links on the media kit page etc.

It reminds me a lot of aesthetic in the game Cruelty Squad - just an intentional rejection of design norms. Nothing worse than being boring right?

/default.aspx on every url

This is actually the investor relations tool they're using (Q4). If you follow the "powered by" link you can see that Q4's corporate website has the same thing

Also on the whole, it's a very unimportant website. It's just some investor relation website. There's no signup conversions to optimise for.

squareup.com is still a normal "boring" website.

> It reminds me a lot of aesthetic in the game Cruelty Squad

Would love to work for a company with full Cruelty Squad world branding, but I guess Consumer Softproducts isn't hiring.

it reminds me of the 'siren song' in Odyssey that would dash sailors across the rocks... except its ADHD Millenial/Zoomer developer/crypto enthusiasts

and hijacked scrolling

Even if Zillow had an algorithm that was 100% accurate at predicting current house prices, the housing market is just incompatible with market making. A market maker isn’t exposed to changes in the price, they clip the ticket on providing liquidity regardless of price direction. Zillow may have been able to successfully speculate on house prices with an accurate model, but they would not be a market maker.

Houses trade slowly, so would sit on Zillows books for a long time (days/months). Market makers on the stock market can have assets sit on the books for under a second. Houses are not fungible, which extenuates the slow trade problem.

Zillow wasn’t aiming to build a business making bets on the housing market. They wanted to become a market maker for housing, profiting off the spread and not caring about the underlying price movements. Being a (good) market maker is still profitable in a falling market.

The issue is that the housing market is just unsuitable for this strategy. Houses aren’t fungible, and they are very slow to trade. So Zillow ended up in a position where rather than clipping the ticket on spread, they were actually quite exposed to house price movements.

You are absolutely correct. But, in a different situation where sellers were willing to sell at a price that was likely to still look like a good idea in a few months, they would not have realized that this wasn't a good idea (yet). It was, I think, inevitable that they would get out of this, because (as you point out) the housing market is not suitable for a market-maker business. But I don't think it was inevitable that they got out at the top; they could have held on and given in to the inevitable six months or a year after the slide had begun. I think it's to the CEO's credit that they got out sooner than that.

A key part of the Oracle strategy is making it a breach of license to publish any benchmarking data. No performance data about Oracle's database is allowed to be published without their approval, which means no negative results are published.

They also sue you for so many other reasons. It's like the management hierarchy joke that Oracle is a litigious law firm with a sales team.


Also, if a sales rep or manager are struggling to make their numbers, they will audit customers.

Here's some background for those who are interested [0].

[0] A solution to DeWitt clauses. https://danluu.com/anon-benchmark/

Oracle Exadata is very fast but expensive. I bet it would beat a similarly sized cluster from these 2 vendors. The problem is price to performance and elasticity. Because DB and SF are in the cloud, they have a lot more options that Oracle doesn’t have. This is why Kurian left Oracle to go to Google, because LE would not allow Oracle to make cloud native products that would run in other clouds. The SF cofounders are ex Oracle engineers and LE was not interested in creating a cloud native DB from scratch. If he did, we wouldn’t have a SF computing right now.

Yeah, the biggest benefit something like Snowflake or Databricks or whatever AWS tools has over the more traditional technologies is the pay-as-you-go pricing.

We're are now trying to scale unnamed technology running on EC2 from 100 nodes to 200 cores and the process to buy larger license is pretty painful. If we were using Snowflake or Databricks, we could just scale it up and update our opex estimate.

I think this has been quite common clause in the license contracts. Databrics has a blog post about it: https://databricks.com/blog/2021/11/08/eliminating-the-dewit...

This is kind of understandable. Benchmarking complex software is complicated. It’s easy to give totally wrong picture of things either accidentally or deliberately.

It may be easier to develop one efficient process to extract CO2 from the atmosphere than to develop numerous efficient alternatives to every CO2 producing activity.

When you miss a quote or a brace in JSON, the JSON fails to parse. When you make a similar minor mistake in YAML, you often end up with a valid but nonsensical document with completely incorrect structure.

I don't want the language to be flexible enough that simple common errors go unnoticed - I WANT the parser to tell me at parse time if I screwed something up. It's a similar dynamic to dynamic/static typing.

YAML's lack of limitations is the source of much of the difficulty with the format. The numerous ways to represent basic data (arrays, strings etc) is a common source of error. YAML doesn't have enough limitations!

And you can't pick what config format a tool you need uses.

But, GitHub, specifically has very specific guidelines on what to write and how to format it, and will give pretty detailed error messages if it's badly formatted. Not to mention tooling to format and highlight. I'm not seeing how the proposed NestedText is inherently free from those same issues: the need for tooling, guidance, error messages. Is the claim that it's easier?

I think the important difference between NestedText and YAML is that NestedText does not try to convert the text to numbers or booleans. YAML converts on to True and 3.10 to 3.1, which in this case is undesired. NestedText keeps text as strings. The idea is that end application should be the one that determines if on is a string or a boolean and whether 3.10 is a string or a number.

Its all in the name. All leaf values are strings. It is literally nested text.

If programmers find getting YAML indentation correct difficult how are non-programmers going to fair?

If the HomeAssistant subreddit is anything to go by its their biggest complaint (HA configuration is in YAML).

With that said if they weren't complaining about white space they'd be complainit about missing semicolons, missing/extra commas, missig equals signs, missing closing )]} or whatever.

Are you arguing "braces are easier to get right than indentation" or is this a point specific to YAML's rules? Because I'm not defending the latter but I find it hard to understand I would need to argue against the former.

The true risk of leveraged ETF's like TQQQ is not so much the risk of large losses in a downturn, but rather that under extreme market conditions the fundamental mechanism that powers the ETF will break down in some unexpected way.

These leveraged funds are made up of complex derivatives, if the funds counterparties (UBS, Goldman, Societe Generale etc.) are unable to make good on their existing trades with proshares, or refuses to allow proshares to open new derivative positions it spells trouble for TQQQ and other leveraged ETF's.

In a 2008 style scenario funds like TQQQ would be hit particularly hard by 1. leveraged exposure to crashing markets and 2. bankrupt counterparties going bad on TQQQ's swaps.

See https://www.proshares.com/media/prospectus/tqqq_summary_pros...

I respect your position and certainly there is risk, but the intraday risk is not significantly greater than leveraging the index itself. For one, no complex derivatives are being used, you can see the exact summary of every asset held by the ETF here:


They consist of the securities themselves, futures contracts, treasury bills, and index swaps. None of these are considered remotely complex or out of the ordinary and the only security that has any real counterparty risk are the index swaps.

So yes, if Goldman Sachs, or JP Morgan, or one of the other nine institutions listed in the above linked document fail in such a way that no other institution bails them out, then TQQQ's price will fall greater than 3x index it's tracking.

I won't argue those institutions can not fail, but that's the case when you invest, you assume the risk that what you invest in will fail.

The greatest risk of investing in TQQQ is not the counterparty risk or that the fundamental mechanism behind index swaps will break down, that's a risk but it's much less likely than the elephant in the room... being leveraged in an investment during a stock market crash.

You say the swaps are the only component that has meaningful counterparty risk, it is worth noting that the swaps dwarf the other TQQQ holdings over 7:1.

But that's not true and wouldn't even make sense. I literally link to the CSV file detailing every single holding they have down to the dollar. You can open it up in Excel/Google Sheets and immediately tally up the values.

The swaps add up to 39325783771 and the other holdings add up to 25311807166. Even if you add in the futures contracts (NQZ1) you're still only at approximately 2:1 which is within the ballpark of what one would expect from a triple leveraged instrument.

I'm not sure how you got 7:1 but given that all of the numbers are right there, you are welcome to provide your calculations.

Ah sorry that's my bad, honestly misread the last row as a total when it's actually just "NET OTHER ASSETS / CASH".

This. I'm so tired of so many comments on Reddit that go something like "Exchange circuit breakers stop trading if a major index drops 15%, this would be 45% with 3x leverage meaning it's impossible for the ETF to hit zero." This is false for the reasons you mention above and has happened to leveraged ETFs in the past. No one seems to care though.

I think in general people don't understand counter party risk

Go is constantly being improved and refined compared to Java 1.44, there is a strong community of third party packages, you aren't shoehorned into the OOP box by basic language design, you get green threads in the form of goroutines while in Java land you are dealing with native threads & the issues they involve (curiously just learned Java <1.3 actually did use green threads, I suppose they were a casualty in the efforts to improve performance), the Go stdlib is much leaner but simultaneously much more useful compared to the Java 1.44 equivalent (even latest Java stdlib is missing basics like JSON!), date/time handling is sane compared to pre-Java 8 equivalent, etc. etc.

Java is getting green threads by means of Project Loom, and value types by means of Project Valhalla.

Not to mention it has sum types and pattern matching, something not available in golang. golang doesn't even have proper enums, quite astounding really.

Comparing a moving thing to a static one is quite meaningless, but regarding third-party packages the JVM is parallel only to the python and node ecosystems.

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