Attummm

This is incredible and still one of the best RTS games available. However, the old rendering engine somehow looks more appealing a similar issue with Shogun 2.

Sounds interesting, but there isn't any description or readme to go by.

Well you have our attention, could you explain the backstory?

Incredibly sad news. His contributions to the foundations of computing will remain relevant for generations to come.

There is evidence that exceptionally high intelligence can work against someone in the normal world and is linked to negative school outcomes.

During the first few hours, it was great product. However since then it seems that products are currently downgraded.

Anthropic really nailed this release.

There had been a trend where each new model released from OpenAI, Anthropic, etc. felt like a letdown or worse a downgrade.

But the release of 4.5 break that trend, And is a pleasant surprise on day one.

Well done! :)

The title is clickbait, unfortunately.

The article states the opposite.

> Writing fast algorithmic trading system code is hard. Measuring it properly is even harder.

A post like this hitting the HN front page feels like a monthly occurrence. Normally I think of commenting in your support but never post it.

While I agree with your technical points, the constant criticism seems less about the specifics and more rooted in either a tendency to go after the incredibly successful, or classic tall poppy syndrome [0].

While we can't control how others react, reframing these kinds of posts as an indirect acknowledgment of your work's significance might be a healthier approach.

P.S. Appreciate the LinkedIn connection.

[0] https://en.wikipedia.org/wiki/Tall_poppy_syndrome

It sounds very intriguing indeed. However, the README makes some claims. Are there any benchmarks to support them?

> Built for performance we're currently 1000x faster than Neo4j, 100x faster than TigerGraph

This sounds great.

Python is really great for quickly developing applications.

However, maintaining them is a real pain point—especially when it comes to packages and their dependencies.

Furthermore, because there isn’t a compile-time checker, function or method signatures can change unnoticed. Compilers are great for catching such issues at compile time rather than at runtime. Python does have mypy, which can play that role, but the package must support it. Currently, you are dependent on the package maintainer regarding their adherence to semver.

Maybe this project will be able to fill that hole.

I'm working on a small project for managing settings in Golang.

I found that boilerplate code needed for handling defaults, environment variables, and CLI variables could become unreasonably large and error prone. I just wanted to have a struct hold the settings needed for the project, with sane defaults, helpful messages, and handling of environment and CLI variables at the same time.

So I created Settingo.

Settingo is a unified solution to handle defaults, environment variables, and CLI arguments. Settings are a boring aspect of a project, and Settingo will allow a dev to focus on the project. https://github.com/Attumm/settingo

Tested the new model, seems to have the same issue as october model.

Seems to answer before fully understanding the requests, and it often gets stuck into loops.

And this update removed the june model which was great, very sad day indeed. I still don't understand why they have to remove a model that is do well received...

Maybe its time to switch again, gemini is making great strides.

Hi Boris,

Would it be possible to bring back sonnet 2024 June?

That model was the most attentive.

Because we lost that model this release a value loss for me personally.

I've been a proponent of pair programming since the early days of Agile, when it was still seen as part of extreme programming. Unfortunately, it’s not often employed in workplace settings.

With that said, would your perception of the interview remain positive if the outcome had been negative?

A common challenge across all interviews is a mismatch in personal dynamics, which can significantly impact the experience for both participants.

Consider a scenario where a senior developer, who prefers simplicity, is paired with a mid-level developer who is still captivated by complexity.

That is great news.

Redis remains my favorite database. I've had the opportunity to work extensively with it, not only professionally but also through open-source projects like redis-dict[0], a Python dictionary with Redis as the backend.

How can we follow your progress on the vector set feature?

[0] https://github.com/Attumm/redis-dict

Great in-depth article, unveiling a lower level of Golang previously unknown to me.

To add to your point.

The food industry, like any other industry, focuses on numbers. Consumer spending favors new varieties of fruit with sweeter taste (e.g., increased glucose/fructose content). This process has led to our current comical situation where fruit, which is perceived as natural, has become unfit for consumption by animals.

>Fruits have gotten too sweet for some animals and zookeepers have had to find alternative foods.

https://weather.com/news/news/2018-10-03-fruit-so-sweet-zoo-...

The ideas presented are great, and I can see myself adopting them in the future. However, the tone of the accompanying text feels off-putting, which makes me hesitant to share it. I hope this aspect improves over time

This isn't a gotcha, it's an important aspect of how Go runs. While it's not highlighted enough concurrency isn't magic, and GOMAXPROCS is important to control your Go app, especially within production environments.

Although it's not well known benchmarks for programming languages would show even faster results for Go with GOMAXPROCS set to 1.

This lets single-threaded benchmarks run with less overhead.

A real missed opportunity in communication. Because this isn't the first time we see articles like these pop up.

It's ironic even after 150 years, the person is still facing the same issue.

For me, the issue with error handling is that while errors are explicitly stated, they are often poorly handled. Rarely have I seen the handling of multiple reasons for why an error might occur, along with tailored approaches to handle each case. This is something very common in older languages like Python or Java

suffix the language name plus name would give us redis-py.

Which in turn would create the filename redis_py.py

Which would immediately raise the question why not a dot.

redis.py

> There are only two hard things in computer science: cache invalidation and naming things.

I have to disagree with your premise.

The goal of many software engineers is to build software / systems they can be proud of. They love software and the machines it runs on.

Many people here have Arduino projects, 3D printers, home servers, and similar hobbies.

A few weeks ago, I was looking for compression algorithms for a particular use case and came across Brotli[0]. I was surprised to learn it was developed by Google. That realization hit me hard. Google used to be a hub for this kind of innovation. Projects like Brotli aren't built to maximize personal profit; they're driven by passion and a genuine love for software engineering.

It's clear that the industry is shifting from being geeky and nerdy to being more business and management focused.

[0] https://github.com/google/brotli

The "what/how" distinction is fundamental. If the "what" is getting healthy and fit, that is a very high-level goal. Within your example, you choose the "how" through running It could've been walking in nature, going to the gym, or doing calisthenics. all of them different "hows".

But since your example made a choice, we are now one level deeper and more concrete than before. The what/goal has in this level become to run a 5K, and the how/method is how you will train to achieve that goal.

"How" and "what" can be very conceptual, especially at a high level, and just like the 5 Whys technique, it could take a few levels to become concrete. Top-down programming is often taught by separating the "how" and the "what." For example:

customer = get_customer(id=id)

The "what" is getting the customer.

The "how" is not revealed, yet its intent is clear. Within the function get_customer we could have another 'what' for example run_query Top-down programming will often first skip the "how" and focus only on the "what" by writing the functions, methods, and classes later on.

https://en.m.wikipedia.org/wiki/Bottom%E2%80%93up_and_top%E2...

Although how and what are connected, they are not the same. For example, 'I would like to become fit and healthy.' 'What' is getting fit and healthy, but 'how' has almost endless possibilities, each with their own success level and compatibility with you and your lifestyle. Just like nouns and verbs are connected, they are not the same.

API keys and certs must be removed from git even if compromised. Many firms use in-house GitLab, Bitbucket, etc. GitHub has enterprise support for removal of sensitive data.

Force pushes occur for various reasons. Sensitive data includes customer and employee personal info.

Other cases involve logs, DB backups, cache, PDFs, configs, and binary files.

Maintenance and performance needs form another category.

Team dynamics and varying git expertise can lead to accidental or uninformed force pushes, especially challenging in a monorepo with 50+ contributors.

In summary, reasons range from personal data (GDPR compliance), security requirements for logs/configs, to resolving merge conflicts and performance issues.

Your question regarding the need to communicate between 50 or more devs, there was no need but monorepo idea forces unnecessary communication and team effort when none was needed if there would be more repositories.

The example was just to illustrate a point about a forced push.

You’re correct about keys/certs once uploaded, they should be treated as compromised, especially when the repository isn’t self-hosted. However, replacing API keys and certificates can take time, and within a large corporation, it could take months.

The issue you faced stemmed from the previous best practice of "everything in its own repository." This approach caused major issues. Such as versioning challenges and data model inconsistencies you mentioned. The situations it could lead to are comedy sketches, but it's a real pain especially when you’re part of a team struggling with these problems. And it’s almost impossible to convince a team to change direction once they’ve committed to it.

Now, though, it seems the pendulum has swung in the opposite direction, from “everything in its own repo” to “everything in one repo.” This, too, will create its own set of problems, which also can be comedic, but frustrating to experience. For instance, what happens when someone accidentally pushes a certificate or API key and you need to force an update upstream? Coordinating that with 50 developers spread across 8 projects, all in a single repo.

Instead we could also face the problems we currently face and start out wirn a balanced approach. Start with one repository, or split frontend and backend if needed. For data pipelines that share models with the API, keep them in the same repository, creating a single source of truth for the data model. This method has often led to other developers telling me about the supposed benefits of “everything in its own repo.” Just as I pushed back then, I feel the need to push back now against the monorepo trend.

The same can be said for monoliths and microservices, where the middle ground is often overlooked in discussions about best practices.

They all reminded me of the concept of “no silver bullet”[0]. Any decision will face its own unique challenges. But silver bullet solution can create artificial challenges that are wasteful, painful, and most of all unnecessary.

[0]https://en.m.wikipedia.org/wiki/No_Silver_Bullet

RedisDict is built exclusively as a dictionary, without focusing on other collections.

This means that all features are available as they build on top of each other. RedisDict has namespacing by default, allowing users to avoid unintentional collisions in production, which are really difficult to debug. Learned that lesson the hard way.

RedisDict also has more support for different types, relying not just on json encoding/decoding but passing those to json so even nested types such as list, dictionaries there type support.

Let's say you would like to build a cache to store webpages for 60 minutes.

```

cache = RedisDict(expire=timedelta(minutes=60))

cache['gone'] = 'in an hour'

```

And RedisDict only makes use of a single dependency, redis.py.