joshuak

It is also interesting to observe that your most valuable accounts in this kind of pricing model are the ones that are least used and therefore are not confronted by the limits. Heavy users canceling their accounts in frustration is a win for Anthropic not a punishment, at least a short term.

This is the problem I suspect. I think it has a negative impact on tons of users but people just curse and move on.

Thanks for your "not sure" comment. Very helpful. Perhaps I'm mistaken but I thought the formatting would make it more legible and scannable. I can see why that might come across as AI generated, but it isn't. I did use AI to reduce the formatting just now though. Do you find this more or less objectionable?

Olympic athletes don't exist because no one at my gym runs that fast.

You are right that typing speed isn't the bottleneck, but wrong about what AI actually accelerates. The 10x engineers aren't typing faster they're exploring 10 different architectural approaches in the time it used to take to try one, validating ideas through rapid prototyping, automating the boring parts to focus on the hard decisions.

You can't evaluate a small sample size of people who are not exploiting the benefits well and come to an accurate assessment of the utility of a new technology.

Skill is always a factor.

Agreed.

Adding black boxes on top of black boxes is not a good way to abstract complexity. Helm does nothing more than any template engine does, yet requires me to trust not only the competency of some random chart author but also that they will correctly account for how my k8s environment is configured.

When I inevitably have to debug some deployment, now I'm digging through not only the raw k8s config, but also whatever complexity Helm has added on to obfuscate that k8s config complexity.

Helm is an illusion. All it does is hide important details from you.

I would think that by comparison to image models synthetic data would be relatively easy to generate for audio model training. I’m curious then why it continues to be so difficult to build a nearly flawless audio separation model. Is synthetic data being widely used? Is it just too hard of a problem to train even with this data? I don’t have a good sense of what the most challenging aspects are of audio models.

It seems to me (at the moment) that the 'engineering' of "prompt engineering" happens at the level of taking a word prediction model AI and turning it into a Q&A AI, and the art of decomposing requests into state and behavior that can produce an A from a Q. Also the chaining of prompts, self prompting, etc.

It's functional composition that's interesting. A system of prompts. Not the phrasing of a single question, no matter how clever.

In Go that quote is literally true. If you do nothing on a new computer but download Go you can immediately build a statically linked application that can fetch from an https endpoint. There are no implied additional steps.

I don't believe this can be said of the other languages. I know that C, C++ and Rust do not include https in their standard libraries, so while they can be made to compile statically and use a library that provides https functionality, those are additional steps that must be taken by the developer, and it is the responsibility of the developer to choose the correct source and version of the https library to use. This will also include understanding and setting any additional compiler flags that the library may require, setting any optional defines or other library configuration settings and making the appropriate changes for every platform they wish to build for.

Go requires none of this.

> I'm not just taking it in isolation for no reason. If you have static linking, you basically have HTTPS by consequence.

Can you clarify what you mean by this because to me there is literally nothing about static linking that implies https as a consequence. The point about Go is centrally not that it uniquely has access to an https library.

The point is that it is included. This may not at first appear all that noteworthy, but this is a substantive quality of life improvement. The standard library not only provides a vary large set of common functionality it is packaged with the distribution, works on all the platforms supported by Go without user intervention, and is bound in lock step to the release version of the compiler.

I really hated this feature at first, but it's one of my absolute favorite things about Go now. In general Go communicates more information than other programming languages without nearly as much visual clutter. When reading code one rarely needs to check elsewhere to fully understand what is intended.

I just addressed this question more directly on your other comment.

I do not agree that it is incumbent upon a speaker to anticipate the listeners knowledge, so I do not think it is a reasonable expectation that every qualifier be included. It's simply not practical. But I do think this is an interesting conversation you bring up.

Then why not assume it is the static linking that is trivial? Isolated each item is trivial in some context, its the exclusive set that is non-trivial, or at least uncommon.

The fact https is included in the standard library means that you can give a new user a hello world tutorial that includes producing a web server. It's a huge boon to productivity in a programming language to have a default path for such libraries.

I also work in C++, and it is infuriating the amount of time that must be spent sorting out the correct libraries for all the various aspects of an application one is not inclined to write themselves. People who don't fully grok the Go ecosystem overlook this cost when they claim that you can do the same thing in some other language. What they are missing in the subtext is the fundamental quality of life improvement.

Sorry for the misattribution, my mistake. Nevertheless, the fact remains that https is a part of the standard library and one of the elements that the op finds unique about Go. It is unambiguously part of the conversation, and the ostensibly negative comment that focuses on static linking is missing the point.

But I didn't even make the assumption that I was right on that understanding. I simply asked for more detail. Which was so that either I would learn something new, or the parent would.

Well that's not on him man. You are the one calling him out for being unaware of static linking, when you don't even seem to understand the full set of pros he listed in his first sentience.

Wait, what prior programming language is compiled, can be statically linked, and has an https implementation in it's standard library?

Why would you need a Makefile? You have to run helm to apply helm charts, how is `kubectl apply -f .` any more complicated then that?

The entire existence of helm is superfluous. The features it provides are already part of Kubernetes. It was created (by /) for people who understand the package manager metaphor but don't understand how Kubernetes fundamentally works.

The metaphor is wrong! You are not installing applications on some new kind of OS. Using helm is like injecting untracked application code into a running application.

At best helm is just adding unnecessary complexity by re-framing existing features as features that helm adds.

In reality helm's obfuscation leads to an impenetrable mess of black boxes, that explodes the cost and complexity of managing a k8s cluster.

First off if you are packaging and/or publishing apps using helm charts, stop it!

There is purpose to the standardization of the Kubernetes configuration language. Just publish the damn configuration with a bit of documentation.... You know just like every other open source library! You're building the configuration for the helm chart anyway, so just publish that. It's a lot less work then creating stupid helm charts that serve no purpose but to obfuscate.

Here is your new no helm instructions: We've stopped using helm to deploy our app. To use our recommended deployment, clone this repo of yaml configs. Copy these files into your kubernetes config repo, change any options you want (see inline comments). Apply with `kubectl apply -f .`, or let your continuous deployment system deploy it on commit.

What have you lost?

A problem, however, is that subscriptions are desirable revenue streams regardless of continuous operating costs. A product I can buy for a largely concrete exchange in value, whereas subscriptions will (at best) go to value in the future that I may not have chosen to buy.

I notice that you feel bad for the devs of the podcast app, but not so bad as to give them the word of mouth marketing they no doubt hopped would be the fair trade value of early lifetime memberships.

Think of Kubernetes like a single application. The config files are the source for that application, the running cluster is the compiled application running on the users computer. By default Helm injects more "compiled" code unrelated to your applications source into the running application. Allowing any tool to alter active cluster state diffuses your single source of truth, your source code, to multiple sources of truth which will not remain in sync with your source unless great care is taken. Moving in sync matters, because that is how you roll back to a known good state when things break.

If you are using Helm to generate source code for your application you still have the added complexity of additional build step, but at least you can choose to add the generated code to your app in a way that tracks with the rest of your code.

Also most Helm chart authors are of varying skill level, and even skilled ones necessarily make incorrect assumptions about your deployment environment. It takes a lot of addition code in helm charts to support more flexibility, so it often get ignored, and you are left with a black box that doesn't quite do what you'd want it to do.

Yes, fixed. Thank you

The problem is that few people seem to understand the infrastructure as code concept, and essentially break the core k8s declarative architecture with imperative workflows that look just like the bash script install insanity we left behind. Workflows that are encouraged by tools like Helm and examples that create k8s objects on the fly without even creating much less retaining the "code" part of IaC.

It turns a tool that escaped the tyranny of endlessly mutating blessed servers with immutable, contained services and unified declarative life cycles, back into an imperative mess of magical incantations that must be spoken in just the right way.

Kubernetes is simple when used as designed, but staggeringly complicated when forced into the mutable imperative workflows it was expressly designed to prevent.

Thanks! That is the one I was thinking of. Notice how even at 10ms of latency rubberbanding is easily visible.

Sure there is. The need to introducing a unified delay across all game clients in the first place, reliable measurement and comparison of latency data, and the effects of latency, artificial or otherwise, on game state which is not strongly consistent. There could be many other areas in which this bug intersects with distributed consensus in the actual implementation as well.

In fact neglecting the impact of distributed consensus is one of the biggest challenges to mitigating it.

Distributed consensus is hard. Very hard. Anyone dismissing the problem as “should never have hopped,” hasn’t a clue as to how hard and error prone reliable distributed consensus is. 35 ms lag in overall responsiveness is an eternity in competitive game play.

There are videos floating around that show drawing on a tablet surface with various input latencies (perhaps someone has a link, I can’t find them at the moment). 35ms latency is very noticeable to anyone never mind professional competitors.

Because of the tricks game designers must pull off in lieu of proper distributed consensus which has hard requirements bound by the laws of physics, it is completely likely there are lots of bugs in the system. I think Riot did the best anyone could reasonably have expected of them, and the write up is particularly informative and helpful.

Is it just me or do others see a correlation between people who short Tesla, and posting on HN about investment tools that use questionable prediction models based on historical "patterns"?

These are starting to look like perpetual motion submissions to the patent office.

I find generics are overused in most languages. Go will be getting generics to handle the very few situations in which they are a genuine value. But the most common uses cases for generics in other langues are already handled by Go interfaces.

For example Go's `sort.Interface` provides a mechanism to implement generic sort, find and set operations on any type of collection that implements those three methods (Len, Swap, and Less).

I nearly never find myself having to use `interface{}` in my Go code, and those that do usually don't have to, they just don't want to define an appropriate interface.

I'm unclear on the benefit of NixOS vs container optimized os (aka coreos/flatcar). These systems have read only root partitions, no package manager, minimal services. The package manager is simply docker.

You have fooled them all. The fallacy of imposter syndrome is not that you are better than you think you are, but that others are worse.

You have fooled them, but you discount the fact that they have fooled you too.

There is no need to use Kubernetes if it slows down your velocity, just use docker or direct drive some VMs. If you NEED Kubernetes then you simply won't get most of the benefits it provides by learning some short cut tools. Tools like helm are easy to use, but do so at the cost of breaking core design elements and a massive increase in complexity just below the surface.

Here's the rule of thumb for Kubernetes use tools to manage the files not the cluster, the cluster description is the source of truth not the cluster.

The above is a false statement because if we say A is "true" then the statement becomes "true != true" which is obviously a false statement. In fact if we put anything in the place of A the results are the same.

If, however, you wish to communicate the evaluation of a function such as "now()", then you would express that as two invocations of that function

now() != now()

or

t != t'

or simply

A != B

So simply using 'A' to mean things not exclusively 'A' is unnecessarily ambiguous. This makes it not only useless for communication between people but also makes it useless for forming any meaningful conclusions.

Failure to be completely expressive about a paradigm is not itself a paradigm. Its just faulty reasoning.

You certainly may define your own symbology.

But if you want to communicate with others you’ll need to agree on your symbology.

In the common mathematical understanding A != A is defined as a false statement. In any example that one can contemplate it would become a true statement then you are replacing one of the ‘A’ symbols with something that is not ‘A’ in your mind.

Which is to say you are using the wrong symbols to represent the idea you intend to communicate.