HN user

estreeper

493 karma

I work with Revelry Labs in New Orleans and am the founder of Xerb in Santa Fe.

I love working with AI, web technologies, and anything involving the intersection of software and art.

Feel free to contact me for any reason!

eric.streeper@gmail.com

Posts16
Comments73
View on HN

Very exciting - I'm a long-time vim user but most of my coworkers use VSCode, and I've been wanting to try out in-editor completion tools like this.

After using it for a couple hours (on Elixir code) with Qwen2.5-Coder-3B and no attempts to customize it, this checks a lot of boxes for me:

  - I pretty much want fancy autocomplete: filling in obvious things and saving my fingers the work, and these suggestions are pretty good
  - the default keybindings work for me, I like that I can keep current line or multi-line suggestions
  - no concerns around sending code off to a third-party
  - works offline when I'm traveling
  - it's fast!
So I don't need to remember how to run the server, I'll probably set up a script to check if it's running and if not start it up in the background and run vim, and alias vim to use that. I looked in the help documents but didn't see a way to disable the "stats" text after the suggestions, though I'm not sure it will bother me that much.

This is a tough question to answer, because it depends a lot on what you want to do! One way to approach it may be to look at what models you want to run and check the amount of VRAM they need. A back-of-the-napkin method taken from here[0] is:

    VRAM (GB) = 1.2 * number of parameters (in billions) * bits per parameter / 8
The 1.2 is just an estimation factor to account for the VRAM needed for things that aren't model parameters.

Because quantization is often nearly free in terms of output quality, you should usually look for quantized versions. For example, Llama 3.2 uses 16-bit parameters but has a 4-bit quantized version, and looking at the formula above you can see that will allow you to run a 4x larger model.

Having enough VRAM will allow you to run a model, but performance is dependent on a lot of other factors. For a much deeper dive into how all of this works along with price/dollar recommendations (though from last year!), Tim Dettmers wrote this excellent article: https://timdettmers.com/2023/01/30/which-gpu-for-deep-learni...

Worth mentioning for the benefit of those who don't want to buy a GPU: there are also models which have been converted to run on CPU.

[0] https://blog.runpod.io/understanding-vram-and-how-much-your-...

A nice tradeoff in many cases is to have a separate schema rather than a separate database, which allows preserving referential integrity and using the database’s RBAC to restrict access to the schemas. This also means things like cascading deletes can still work.

We've built many production apps using LiveView. It has some limitations inherent to its design, namely the need to have a semi-reliable WebSocket connection to be able to effectively use the app, but with this tradeoff come a number of advantages:

  - code generation makes for an extremely productive experience that makes standing up an actually-useful application very fast
  - Elixir is a great language, especially for the web, and using it to render the frontend feels like having the full power of the language plus the simplicity of HTML (with little/no writing JavaScript)
  - it's extremely efficient since only tiny changes are sent over the WebSocket when data is updated on the server
  - you're already using WebSockets, so adding any kind of real-time functionality is very easy (chat, notifications, game state)
Because of the separation of concerns by convention (i.e. keeping business logic in Contexts), it's also a very viable pathway to build a webapp using LiveView first, and serve an API once you need other types of clients (native apps, API consumers) with minimal changes. Ecto is also great to use for validations, and having that available for "frontend" code is a pleasure. It's also great to be able to have backend and frontend tests in Elixir.

We've hit some bugs and gotchas over the years leading up to this 1.0 release, but it has long felt like a stable, well-built library that keeps our codebases simple and maintainable, which lets you move fast.

Congratulations to Chris, Jose, and all the other wonderful contributors!

Not to mention various other wars and random fires, such as the Ōnin War 応仁の乱 in the 1400s, a civil war between many feudal lords, which destroyed much of Kyoto among other areas.

The world's oldest extant wooden structure is the Kondō (main hall) of the temple Hōryū-ji 法隆寺 in Ikaruga, in the Nara Prefecture of Japan. It was initially built in 607 but completely burned down due to lightning. It was rebuilt in 670, but again nearly burned down by accident in 1949 [1].

It's interesting to contemplate how across these timescales war, disasters, and accidents make it so difficult for structures to survive.

[1] https://en.wikipedia.org/wiki/H%C5%8Dry%C5%AB-ji

I'm curious how people are handling multi-lingual embeddings.

I've found LASER[1] which originally had the idea to embed all languages in the same vector space, though it's a bit harder to use than models available through SentenceTransformers. LASER2 stuck with this approach, but LASER3 switched to language-specific models. However, I haven't found benchmarks for these models, and they were released about 2 years ago.

Another alternative would be to translate everything before embedding, which would introduce some amount of error, though maybe it wouldn't be significant.

1. https://github.com/facebookresearch/LASER

Energy use should be a concern, but it’s important to understand the magnitude of the problems and not simply conflate crypto and AI. To compare the technologies against each other:

Bitcoin: 145B = 145,000M kWh/year

ChatGPT: 0.5M * 365 = 182M kWh/year

Based on the numbers from the article, ChatGPT is using 3 orders of magnitude less electricity for something that provides high utility for vastly more people.

There are of course many other uses of AI aside from ChatGPT and more cryptocurrencies aside from BTC, but these are very different power consumptions.

For embeddings specifically, there are multiple open source models that outperform OpenAI’s best model (text-embedding-ada-002) that you can see on the MTEB Leaderboard [1]

embedding-based approach will be cheaper and faster, but worse result than full text

I’m not sure results would be worse, I think it depends on the extent to which the models are able to ignore irrelevant context, which is a problem [2]. Using retrieval can come closer to providing only relevant context.

1. https://huggingface.co/spaces/mteb/leaderboard

2. https://arxiv.org/abs/2302.00093

Great work and great concept - I found the copy to be clear and communicated the value proposition effectively, and I would certainly consider using this when selling my house since I could potentially get 10s of thousands of dollars more. I will also check back to see if there are different listings here than on Zillow, but will probably forget if you don’t send me a reminder.

One small UX bug: on mobile the hamburger menu obscures the Sign Up form, and I missed that I needed to click the X - closing the menu when I click an item would solve this. Other than that, it was pretty easy to use!

The idea of being able to get information directly from the person living in the house is appealing to me.

I understand the up front fee to sell, but wish I could de-risk by being able to get it refunded if I don’t sell.

Very interesting, I hope to keep an eye on your company!

I hate to recommend what is just another service provider, but there are many cloud hosting providers that offer email sending (i.e. AWS, GCP, etc.) and dedicated email companies (Sendgrid, Mailgun, etc.). The cost to send email via any of these services is a tiny fraction of the amount you would pay to Mailchimp.

The value in what Mailchimp does is not so much just sending email, but in all the things around it, like managing subscribers, tracking opens, easily creating nice-looking emails that look good in a variety of mail clients, etc.

Contrary to some of the replies you've received here, it definitely is possible to run your own mail server with good deliverability, and we routinely did this for companies, even fairly small ones, physically on-prem and in datacenters, and cloud. It is not trivial, but far from impossible, and will likely involve communicating with a human when getting a static IP to find a good one. With that being said, I do not recommend you run your own mail server starting out, that is probably not the problem you are trying to solve.

To add to this, also remember to do this for anything else you might use to send email: servers/cloud services providers you use for transactional emails, any provider you might use for marketing emails, etc.

The road to "tutorial hell" is paved with blogposts and missing fundamentals

Even worse is that blog posts can have incorrect, bad, or even dangerous information. If you've just found it in a search, you have no idea of the skill level of the author.

I recently came across a post about a JavaScript WYSIWYG editor which stated that you didn't need to worry about sanitizing the HTML output from it because it took care of that for you. An attacker could of course send malicious data straight to the server or manipulate the client code however they want, so without also sanitizing on the server (also a hard problem), this opens a huge security hole. Ten years ago I probably would have naively followed this and thought everything was okay.

Tutorials are often useful, but they also cannot be trusted, especially without other resources. I feel I've learned the most from reading in-depth sources like official docs, specs, RFCs, or the source code of high-quality, well-maintained libraries. It can be harder at first, but I learn things I wouldn't have thought to look for, and there is something of a consistency in presentation (at least by comparison) that makes each additional one easier to go through.

For testimonials from some of the people living in these Toronto tiny shelters:

https://www.youtube.com/watch?v=AdbmLKaGleg

Some interesting notes about the shelters from the video:

- they are on wheels, and because they're off the ground they stay warm and dry even when it's raining

- they can be locked from the outside or inside, which gives people a sense of safety (e.g. people's tents can get slashed up, but these are strong), and they can also safely leave possessions there

- they let people sleep much better (longer, more comfortable)

The amount having these things improves a person's psychological state is immense.

I spent 3.5 months backpacking in India and Southeast Asia. I saw incredible places and stood in a hundred postcards. For me though, people are what had the most impact.

Tens of thousands of Hindus come to die in Varanasi each year. If you die and are cremated there, you are freed from the cycle of rebirth and can attain salvation. I stood with an Indian friend on the edge of tears as I watched them burn the dead. He asked me why I was sad, and I told him I was sad for the dead. He said do not be sad, this is the way they wanted to die.

We were warned never to get a train ticket on Indian Railways below 2nd class. It wasn't safe. There were only enough 2nd class tickets for my friends, so I went to 3rd class alone, in the middle of the night, and went to sleep in a top bunk, the warnings echoing in my mind. When I awoke my 5 neighbors were speaking softly to each other. They shared food with me they had brought from their homes. We showed each other where we had come from and pictures of our families. I didn't speak the same language.

Cambodia had 25% of its people starved or murdered less than a decade before I was born: Year Zero. Anyone educated was the first to go. We hired a tuk-tuk driver to take us to the temples around Siem Reap. He was the son of farmers. At one temple we came out the entrance and snuck up on him while he waited for us. In his lap he held open a book in English, and tucked into it a smaller book. It was a Khmer-English dictionary.

I had a lot of good times meeting people at hostels and going to bars with other travelers, a few of whom have become dear friends. You could easily stay with tour groups, never leave the westernized areas of anywhere you go, and take lots of selfies in incredible places. It brings money to the local economy.

It's up to you though. If that's not what you want, getting away from it is as simple as walking 2 blocks in any direction.

The string output from the bcrypt function always contains a 22-character salt embedded within it, so these are salted. This is placed after an initial algorithm identifier (i.e. $2a$) and an adjustable cost used to generate the output string (i.e. 10$). There's an overview of the structure of the output string here if you're interested: https://en.wikipedia.org/wiki/Bcrypt

However, if your password is "password" or another very common password, then someone can just try those with the embedded salt and still find out that was your password.

For what it's worth, as a non-YC company, I found the GCP onboarding process to be far superior in every way, and my experiences were essentially reversed. For context, we started with GCP for Startups 1.5 years ago when we were just getting beyond a demo, and with AWS Activate 1 year ago, when we had almost no revenue and just about 1,000 users. We were based in the Santa Fe Business Incubator (NM, USA).

All in all, it had taken our incubator at least 1.5 years to get enrolled in AWS Activate, and 4 days in GCP for Startups.

When we applied for GCP for Startups, we were approved in a week, and were contacted right away by an account manager and a support engineer who offered us help with anything we needed. When we applied for Activate, it took a month with lots of followups, and being shuffled between 4 support team members who were communicating with the Activate team (there was no way to contact them directly).

It definitely felt like our business was important for GCP, and for AWS, it wasn't. It was an easy choice.