bschmidt1

Feature requests:

- Let me save coffees I normally drink on file so I can just choose my regulars: "Temple pour over", "Starbucks Americano", etc. and it knows the ounces and mg of caffeine in that drink.

- Let me define my wake/sleep times, or like the coffees keep a few saved times to easily choose from later.

- After I drank the first coffee, it should ask me if I want another one at the optimal peak (unless it's too near to my sleep hour). Partner with DoorDash to fulfill the order.

- The important part: Because DoorDash drivers will occasionally no-show, or drink the coffee themselves, you'll need some extra cash to cover costs, comp angry customers, etc. so you'll need a Series A. So we need to convert your UI into a ChatGPT wrapper that converses with the user in a friendly way, rather than in the VB6-esque UI I see here (as slick as it is).

Point stands they weren't doing well over here either during those years.

"Omega-3" is to "cannabinoid" in your analogy. "Marihuana" would be on the level of saying "Fish Oil".

During their growth years when they arguably did the shadiest stuff they also had record-breaking quarterly losses in the billions while their counterpart DiDi in China was doing well enough to acquire Uber China (who according to Travis Kalanick was losing over $1b a year).

Didn't say MFA, said state of username / password (useState is fine for that).

Also said "use hooks", not "don't use hooks" and never said don't re-use functions.

Would hate to be on that team, I bet those PRs are brutal.

This one seems like a blatant GPT wrapper. Why not just use 4o?

For example, "Ask any question" the use case shown is:

> "What specific python scripts are users running inside HubSpot?"

I could just ask ChatGPT that too, why would I need this product to answer the question?

Seems like everyone is just wrapping ChatGPT, creating even the identical UI down to the icon on the send button, and then making a Loom showcasing essentially white-labeled OpenAI functionality.

Running Linux on a computer? I could understand your comment if the display was something very non-conventional like a series of lightbulbs instead of digital output.

It's a cool project don't get me wrong, but Nobel Peace Prize? What is this thread? I would consider something like a strandbeest to be more award-worthy - but it too is just a neat invention, not contributing to world peace or anything near it.

Awesome, works great! Love the modes "Real-time", "progressive", etc.

> I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works.

React hooks obsoleted most use of state management tools years ago (there is even a native useReducer now so you don't have to install Redux just for that), especially if they're using SSR (Next.js) where state management has been moved to the server. There are still some cases for installing a global state management library in the FE, but usually useState / useEffect and custom hooks is enough for most React projects.

The problem is you came up with a heuristic in your mind that "global state management is pro, useState is amateur" but that isn't true.

Lets use a real example: If I worked on your team and pushed a <LoginForm /> component that captured email/pass with useState, you would tell me to move the username and password to a global state management library? Why? Dogma? It would be the wrong call.

Looks incredible. Snappier than real Windows tbh

No need for a dark web, Twitter and GitHub have both leaked user passwords stored in plain text on their own platforms right here on the corporate web.

Twitter who struggled to turn a profit (but not to pay its investors who became wildly rich off it) hired artists who chose technology like Ruby on Rails. They should have hired capitalists who breathed jQuery and ate pieces of sh*t like Active Record for breakfast

> break apart programs into object files and reusing them

So, libraries?

I think you missed the point that it wouldn't actually be shittier code in that case.

Some ugly 4 space indented, wrong kind of loops, old Node version, mongo as the main db, no linter, callback hell SaaS platform in 1 file called "server.js" could still be more reliable and yield higher profits and sooner than your masterpiece in Rust.

> must be about irrelevant things like 'art' or 'poetry'

If by "bad code" you mean something related to syntax, convention, or code that "might have bugs" (wtf), there is still a case it's actually "good code" if it's more readable, was a quicker solution that yields higher profits, is a less error prone approach to the larger management of the codebase albeit less performant etc.

> one difference between crappy code and good code is that in crappy code one is quite sure there are lurking many bugs

Sounds too superficial/judgmental and not evidence-based. If there is a bug there is a bug. Even perfectly written code to the best possible standard can still be code that does the wrong thing.

Is code more like poetry or more like a recipe? If the former, then yes we should be allowed the time and space to craft the highest syntactic art imaginable. But if it's the latter, it should just be quick, correct, readable, and extensible.

If it's art - how dare you ruin my masterpiece?

If it's business - we had a solution deployed for the customer in less than an hour.

If syntax (poetry) is your #1 take your time. If money is your #1 you wouldn't call it "crappy code" at all. Even code that is not as performant as it could be is only "crappy" if it's affecting the bottom line (which it often does). But so-called bad code that is yielding higher profits, hard to call crappy.

React -> React Native

Tailwind -> Tailwind Native ?

is what I would have named it :D

`embeddings.json` this makes me happy

Vercel too?! What are you using for SSR + serverless, Amplify?

Vercel seems pretty great for a React-centric app with a couple of one-off backend calls to cloud services, super convenient, deploy previews in GitHub etc. why not?

What about S3, you don't really need a file storage provider either?

> are javascript devs really that afraid

You might be afraid of JS devs :P Anyway has nothing to do with language, even if it was a super c0ol Ruby-on-Rails app with Active Record and SQL db on a server you manage it's still common to have some stuff in NoSQL for fast access to live data, caches, logs, etc. Most companies at scale will have both SQL and NoSQL dbs in areas. So if you're already using S3 for files, code on GitHub, storing keys in 1Pass, why not use a Firebase or MongoDB for high traffic live data? Especially if they offer built-in scaling and geo deploy options.

This scenario I laid out is kinda to your point of "don't anchor your entire company on it" - the only point I'm trying to add is that you can also use these tools without the company being "anchored" on it, and they could have still ran into the same issue as Arc.

Like Instagram and Slack they intentionally make the web experience bad so you use the native app where they can track more.

Only if using DOM right? If someone ported a WebGL game to Electron the same 3D engine would be at play. Or 2D canvas for that matter. I think you're specifically referring to the overhead of browser DOM and how elements therein load, focus, apply styling, etc.

It was in reply to a dishonest comment that was taken down. It's normal to use elevated rhetoric when correcting the record about a false idea being put forth and made public.

Furthermore saying "probably because the CTO is a dick" to a random person online - in response to a question about why their startup is blacklisted - is definitely fair game. How many people have said "{insert CEO name} is a dick" on these forums?

https://hn.algolia.com/?q=is+a+dick

I think you guys are way too sensitive, unless "reputation management" is part of the YC offering it's a bad look to even be involved in my comments like this. Let people say what they want within reason.

Yes, like most MMOs the game client can be downloaded for free so you can play on multiple devices. It's the account that you pay for. Unlike conventional MMOs it's a one-time fee and not a monthly subscription.

> you wrote it using a stack that could be web-based

Not really because of the memory usage. This has nothing to do with the stack but the file size of the 3D assets used, which directly translates to memory used at run-time. As a desktop app you can fully take advantage of your gaming PC's available RAM and VRAM.

> Asking people to download and run an .exe

Understandable. Because of this, and that the download size is so large I should probably use a downloader/installer so it doesn't feel like just downloading an exe. Thanks for your feedback!

Well, it's an app that users access all their online info through - bank, email, search, work, social - everything. Even an open-source, decentralized, blockchain, grass-fed, organic, extra virgin, written in nothing but HTML, released by W3C itself browser could monetize just ~5% of market share if users are downloading their build (or if its baked into the source), considering how much a browser reveals about its user and to the extent the user can be retargeted for: Ads, marketing, surveillance, analytics.

The biggest opportunity has to be driving search traffic to the major search providers all these browsers partner with.

Could also get acquired by a major browser vendor if you have a better product and people are downloading it more than the major ones, especially if both are based on the same underlying engine. Even Firefox still sucks to this day. I'm using it right now (Waterfox) the product still sucks! I know of some browser vendors acquiring others, especially as mobile took off and it was hard to get it right.

Seems like the opportunity is similar to that of social media but slightly more modern because nobody uses new social media anymore but people are trying out new browsers (and you get richer user/usage data).

No Linux version prevented me from trying it, didn't even get to the account wall, who knows if there's a pay wall. Perhaps the "moat" concept was misunderstood.

The next Linux King will be happily merging pull requests until one day his keyboard will begin to speak to him...

"Arthas..."

The super promise died with crypto, now you have to add no backsies. My site uses No Backsies Proofs (NBPs) which are encrypted to prove that all my super promises are backed by a no backsie which is stored in the no backsie vault in Antarctica.

The main thing is choosing the right technology that will allow scaling if it's part of the plan. It's not that you need to build Twitter-level traffic scale from Day 1, but you should of course choose a tech stack and platform that you can scale if you need.

(Twitter famously learned this the hard way)

If I loved Ruby, why would I choose Rails for a high-traffic social media app? If I loved Python, why choose Django for an API-first service that doesn't have an Admin dashboard? Yet I see it all the time - the developer only knows PHP/Laravel so everything gets built in Laravel. Point is... why lock yourself into a monolithic setup when other options are available even in those languages? You can definitely choose the "wrong stuff" and for bad reasons, even if it works today. "Doing things that don't scale" seems frankly stupid whenever scaling is a big part of the plan for the company, especially when there are plenty of options available to build things in a smart, prepared way.

But go ahead, install your fav monolith and deploy to Heroku for now, it will just be more work later when it has to be dismantled in order to scale parts independent from others (an API gateway that routes high traffic, a serverless PDF renderer, job scripts like notifications, horizontal scaling of instances, etc.).

It's smarter though to just choose a more future-proof language and framework setup. The Node setup on my rpi4 has been on GCP, AWS, Heroku, Render in various forms (as a monolith, as microservices, in between) - repo-wise, it's a "mono server" of 15+ APIs, apps, and websites that separate businesses in town rely on, yet I can work in it as one piece, even easily move it around providers if I want, horizontally scale as needed with no code changes, and because of essentially the folder structure of the app (I copied Vercel) and how Node require works, any export can be either imported to another file or deployed as a serverless function itself.

There's nothing about the codebase that forces me to choose "not scale" or "scale". I even have platform-agnostic code (libraries) that can run in either a browser or a server, talk about flexibility! No other language is as fast and scalable while also being this flexible.

This is mindblowing. It's like the missing piece of blockchain that was needed for dev adoption. I can see it also being used for modern bank/payments apps including those in games and other simulated economies.

Now let's see a "ContentScript" for posting content to ledgers :D

    send [Image "tacos.jpg", Text "taco 2sday!"] (
      source = @bschmidt1
      destination = @us-west-relay
    )

I searched far and wide for this a few years ago for a disastrous React codebase I inherited that had a lot of unused components, never found anything.

This looks great, particularly the `skip` and `mode` options (which I'm guessing several commenters here missed).

I suppose it should work just as well with monorepos or any other directory hierarchy right? It only "knows" files are unused because they're never referenced in any code within the defined `projectRoot, and it only knows exports are unused whenever they're never imported?

Cool project, will definitely try it soon.