Why are all of the comments about the name? The author literally said this is a toy project for educational purposes... There are thousands of projects on github. This isn't even the only other project named "vanta" on github (I just checked and there is an animation library for javascript called vanta). So, seriously, who cares?
If OP was an actual company, that would be different. But this is quite literally a toy project.
Anyway, congrats OP! Your project looks really cool.
Most probably those other projects haven't been at #1 on HN or similar sites for long.
I agree that having discussion get consumed by the name is unfortunate and off-topic. It's also predictable, alas (https://news.ycombinator.com/item?id=44161041) but we have various tricks to try to dampen it.
Yeah, it's like if one writes a tiny calculator and names it Disney to learn how to program in Delphi, it's a learning exercise with 0 commercial intent so who cares. But for those who care about the name vanta, get the G from Go and rename it to Ganta, problem solved :-)
with the added benefit that the software family could be extended in the future with other learning exercises such as a Rust forum engine named Ranta
I agree. I was trying to use Vanta’s trust management platform to prepare for an audit but instead downloaded Vanta, the toy version of Wireshark. It's very easy to mix up 400 lines of go code on github with the security platform on vanta.com.
This article is insulting. It is trying to paint the picture that all of us who go against the mainstream are deluding ourselves if we think it is anything more than the digital equivalent of wearing a leather jacket.
Very often mainstream stuff really is actually worse than obscure stuff. I don't have to explain this to the HN crowd, I'm sure.
The article is pretentious (which is ironic since it is arguing for adopting mainstream technology).
The fact that this exists shows that there is a serious problem in the python ecosystem. I'm sure it solves a real problem, so I'm not knocking the author. It's more of a "state of our industry" problem.
The issue is you think pyenv has solved everything, someone else thinks poetry solves everything, I think uv solves everything, and someone else is apt installing things. And then there is installing torch and cuda...
I think having a very widely accepted and supported default would let the community rally around it and improve the experience and documentation (though I am not a fan of the centralized hosting that npm and cargo push, I much prefer the go approach, but we are already there with PyPI)
uv + poetry are a higher level in the stack than something like pyenv.
pip, uv, poetry are all analagous. they ensure the correct packages are installed. we have some internal apps that devs decided to start with poetry and it has some nice ergonomics ... but on the other hand I find the simplicity of a requirements file to be so ... simple. People get caught up on the file, too, but really its just a convention. you can call it whatever you want, deps.txt, deps.foo, packages.bar ... its just a plaintext file with newline delimited packages. since its "just a file" and "just unix" this has the added perk of being able to cat many files together and use that with pip. it's all just lines of text, pip does not care.
pyenv + pip works. pyenv + poetry works. pyenv + uv works. those become inconsequential decisions you can make on a case by case basis and try or forget as needed.
You're right not all of those need to be conflated but they aren't entirely orthogonal either, uv can install/manage python installations for you and poetry can manage environments as well if you want. On top of that, you have tools like mise that are more cross cutting.
I agree that there is a really nice simplicity to requirements.txt but I've myself enjoying uv enough to just fully embrace it (and not farm out to uv pip) and as a result I now find myself in pyproject.toml land.
I just install the libraries I need using the operating systems package manager. Works perfectly fine. In development I do use virtualenvs because I need to keep track of which dependencies are required, but in production I just apt-get install.
Probably, but it keeps my dependencies low and packages are automatically updated with backported security patches. So far it has never been an issue, but there has been frustrations when the features aren't available, because the Debian packages aren't the newest versions.
I wouldn't recommend it for something with hundreds of dependencies, but I also wouldn't recommend having hundreds of dependencies.
Poetry has messed up packages more often apt ever did, in my use cases. So far using apt as by package manager has failed me exactly zero times.
Absolutely, but that's true for pretty much all the package managers, for all languages. They all break at some point.
One thing I would note is: Don't install your dependencies with apt in a development environment, you need to have a clean environment to avoid dragging unneeded dependencies into your production environments. That does mean that you need to find the exact version of your dependency in Debian, but it's a good exercise and ensures that you're mindful of your dependencies.
Be mindful, be prepared is good advise, in all aspects of life really.
From the abstract: "Evidence links lifestyle factors with Alzheimer’s disease (AD). We report the first randomized, controlled clinical trial to determine if intensive lifestyle changes may beneficially affect the progression of mild cognitive impairment (MCI) or early dementia due to AD."
A whole foods minimally-processed plant-based (vegan) diet, high in complex carbohydrates (predominantly fruits, vegetables, whole grains, legumes, soy products, seeds and nuts) and especially low in harmful fats, sweeteners and refined carbohydrates. It was approximately 14-18% of calories as total fat, 16-18% protein, and 63-68% mostly complex carbohydrates. Calories were unrestricted.
Aerobic (e.g., walking) at least 30 minutes/day and mild strength training exercises at least three times per week from an exercise physiologist in person or with virtual sessions.
Stress management:
Meditation, gentle yoga-based poses, stretching, progressive relaxation, breathing exercises, and imagery for a total of one hour per day, supervised by a certified stress management specialist. The purpose of each technique was to increase the patient’s sense of relaxation, concentration, and awareness. They were also given access to online meditations. Patients had the option of using flashing-light glasses at a theta frequency of 7.83 Hz plus soothing music as an aid to meditation and insomnia. They were also encouraged to get adequate sleep.
Group support:
Participants and their spouses/study partners participated in a support group one hour/session, three days/week, supervised by a licensed mental health professional in a supportive, safe environment to increase emotional support and community as well as communication skills and strategies for maintaining adherence to the program.
> flashing-light glasses at a theta frequency of 7.83 Hz plus soothing music as an aid to meditation and insomnia.
How does the flashing light glasses is an help against insomnia? That sounds contradictory with the effect of light with sleeping and I'm curious to understand how that works.
I agree. I once attempted this on a javascript project (a personal project, not at work), after reading about APL/J/K people and their philosophy. My constraint was: I should never have to scroll. I also aimed to have as few files as possible.
The result was surprisingly pleasant, and it changed how I feel about this sort of thing. I think the Clean Code approach makes a lot of sense when you are working on a big project that contains lots of code that other people wrote, and you rely on IDE features like jumping to definition, etc. But if you can write code that fits on one screen without scrolling, something special happens. It's like all the negative aspects of terse code suddenly vanish and you get something way simpler and overall easier to work with and understand. But you really have to work to get it to that point. A middle ground (terse code but still spread out over lots of files, lots of scrolling) would be the worst of both worlds.
"john ousterhout's book is the only book on how to write software that has any actual evidence behind it."
This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example.
There are lots of other architecture/design books that use real world systems as examples. "Evidence" is definitely lacking in our field, but you can find it if you try.
> People have been building complex software for over sixty years, but until recently, only a handful of researchers had studied how it was actually done. Many people had opinions—often very strong ones—but most of these were based on personal anecdotes or the kind of "it's obvious" reasoning that led Aristotle to conclude that heavy objects fall faster than light ones.
in the 2024 retrospective:
> Conclusion
> The comedian W.C. Fields once said, “If at first you
don’t succeed, try, try again. Then quit. There’s no
point in being a damn fool about it.” Thirteen years
after our first post, it is clear that our attempts to
bridge the gulf between research and practice haven’t
worked. We look forward to hearing what actionable
plans others have that will find real support from both
communities.
