One of the big problems for me is that my company installs all kind of nonsense for security that makes the whole system behave strangely. For example, when I click on a window to activate it, it will often jump across the screen. In over 20 years on the Mac, I’ve never experienced this on my personal system. However, it happens almost every day at work. The hard drive on my desktop also randomly disappears and reappears, but only on the work Mac, and it’s happened constantly, everyday, for 6 years. It’s probably JAMF, but I can’t do anything about it. There is a bit of learned helplessness when dealing with my work Mac.
Most of my focus issues are at work, so I have no idea what is a macOS issue and what is an issue with the stuff the company installed.
On my personal Mac and phone, I submit feedback to Apple all the time when things annoy me, since those issues are more clear cut.
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.
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.
Unlike images, audio signals are time-dependent and have complex temporal dynamics, making it more challenging to generate realistic synthetic data that captures the nuances of real-world audio. Meanwhile, the complex nature of audio signals, the scarcity of high-quality training data, and the subjective evaluation of audio quality collectively contribute to the ongoing challenges in building near-flawless audio separation 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.
Agreed, there’s a lot more design space to explore with prompt chains/flows. But a single prompt requires design too especially if it’s dynamically generated. You have to choose what information to provide, frame the question or task you want it to complete in a way that provides good answers and is also extractable from the completion, and fit within the token limits (32k tokens is a lot but expensive and still small for some tasks).
This article only covers the simplest type of prompting you might do.
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.
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.
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.
> Isolated each item is trivial in some context, its the exclusive set that is non-trivial, or at least uncommon.
I'm not just taking it in isolation for no reason. If you have static linking, you basically have HTTPS by consequence.
> 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 think you're taking our discussion as if it were about if the language is cool or not. I never argued against that.
> 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.
The convenience of building network clients in Go is heavily implied. Strictly you can say that assembly code can make standalone binary HTTPS endpoints, but that would be a bit silly.
To be sure you might write such a program in assembly, but you’d be doing it for fun or aesthetics. No engineering manager would commission such a thing.
Though of course this is inviting the trading maniacs to tell stories of hyper optimized clients…
HTTP doesn’t need to be in stdlib. Java and Python each had one but everyone long since switched to third-party reimplementations with better APIs. And HTTP will probably be replaced over the next twenty years, like FTP and Sun RPC and CORBA before it.
Ok, but it's not either Go or assembly. There's other languages. I listed 6 in a close-by comment. I wonder if Go's much more convenient at network clients than, say, Haskell or Common Lisp.
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.
You're not replying to the same person. In a separate comment, I asked for a clarification on that specific part of their comment. The other pros, they're not part of what I asked about.
In the comment I replied to you, I'm just stating that you're bringing up something that's not in discussion.
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.
> https is a part of the standard library and one of the elements that the op finds unique about Go.
Where do they say that it being part of the standard library is unique? I don't even see the words "standard library" mentioned.
EDIT: Look, this back and forth seems kind of pointless. This started with a statement about Go being unique for being able to be statically linked and talk HTTPS. If a language can be linked to compiled libraries, static or not, it's surely able to at least use libcurl, so I and the other commenter you replied to took it as Go is unique for being able to link statically. I assumed they meant, ignoring C/C++, static linking is rare, which I found interesting. I found other languages and asked for clarification. That's all.
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.
reply