To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and build a number of dotnet packages for various things, but for an ecosystem that's supposedly cross-platform, almost none of them seem to just work by default when I run `dotnet build` and instead require at least some fixes in the various project files. I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done. The list of dependencies is just about the only thing in there that effects the default build; if there's any other configuration other than that and the basic metadata like the name, the repo link, the license, etc., it almost always will end up being specifically for alternate builds (like extra options for release builds, alternate features that can be compiled in, etc.).
> The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO.
In the interest of pedantry, locating source files relative to the crate root is a language-level Rust feature, not something specific to Cargo. You can pass any single Rust source file directly to rustc (bypassing Cargo altogether) and it will treat it as a crate root and locate additional files as needed based on the normal lookup rules.
Interesting, I didn't realize this! I know that a "crate" is specifically the unit of compilation for rustc, but I assumed there was some magic in cargo that glued the modules together into a single AST rather than it being in rustc itself.
That being said, I'd argue that the fact that this happens so transparently that people don't really need to know this to use Cargo correctly is somewhat the point I was making. Compared to something like cmake, the amount of effort to use it is at least an order of magnitude lower.
> I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done.
For most crates, yes. But you might be surprised how many crates have a build.rs that is doing more complex stuff under the hood (generating code, setting environment variables, calling a C compiler, make or some other build system, etc). It just also almost always works flawlessly (and the script itself has a standardised name), so you don't notice most of the time.
True, but if anything, a build.rs is a lot easier for me to read and understand (or even modify) if needed because I already know Rust. With something like cmake, the build configuration is an entirely separate language the one I'm actually working in, and I haven't seen a project that doesn't have at least some amount of custom configuration in it. Starting up a cargo project literally doesn't require putting anything in the Cargo.toml that doesn't exist after you run `cargo new`.
Oh sure, build.rs is (typically) a great experience. My favourite example is Skia which is notoriously difficult to build, but relatively easy to build with the Rust bindings. My point was just that this isn't always because there's nothing complex going on, but because it still works well even though there sometimes are complex things going on!
But you are specifying source files, although indirectly, aren't you? That's what all those `mod blah` with a corresponding `blah.rs` file present in the correct location are.
Yeah, my instinct is that we're naturally going to have emotions resulting from anything we interact with based on language, and trying to suppress them will likely not be healthy in the long run. I've also seen plenty of instances of people getting upset when someone who isn't a native speaker of their language or even a pet that doesn't speak any language doesn't understand verbal instructions, so there's probably something to be said for learning how to be polite even when experiencing frustration. I've definitely noticed that I'm far more willing to express my annoyance at an LLM than I am another actual human, and this does make me wonder whether this is a habit I should be learning to break sooner rather than later to avoid it having any affect on my overall mindset.
There are times when trying to use Claude for coding that I genuinely get annoyed at it, and I find it cathartic to include this emotion in my prompt to it, even though I know it doesn't have feelings; expressing emotions rather than bottling them up often can be an effective way to deal with them. Sometimes this does even influence how it handles things, noting my frustration in its "thinking" and then trying to more directly solve my immediate problem rather than trying to cleverly work around things in a way I didn't want.
What are the odds that Anthropic is building a psychological profile on you based on your prompts and when and how quickly you lose control over your emotions?
I guess if they think they can monetize the fact that I get upset when I ask it make a certain change to the code and it doesn't do it several times in a row, they probably already are
Yeah, it's unfortunately part of the hype. Talking about how close you are to having a truly general AI is just a way to generate buzz (and ideally investor dollars).
The way I've tried to explain to family members about LLMs is that they're producing something that fits the shape of what a response might look like without any idea of whether it's correct or not. I feel like that's a more important point than "box of numbers" because people still might have assumptions about whether a box of numbers can have enough data to be able to figure out the answer to their question. I think making it clear that the models are primarily a way of producing realistic sounding responses (with the accuracy of those responses very much being up to chance for the average person, since there likely isn't a good way for a lay person to know whether the answer is reflected in the training data) is potentially a lot more compelling than explaining to them that it's all statistics under the hood. There are some questions where a statistical method might be far more reliable than having a human answer it, so it seems a bit risky to try to convince them not to trust a "box of numbers" in general, but most of those questions are not going be formulated by and responded to in natural language.
Oh, I agree, I was mostly calling it that here just as shorthand. My actual explanations in the past to family members has been that it's trained on a ton of data and its output is it regurgitating things based on your input and things that are plausibly related. But my "box of numbers" mostly focuses on explaining to them that it doesn't "remember", it doesn't "learn", just different things are injected into the context ("Memories", other chats, things you've told it about yourself explicit or implicitly). Really driving home "there is no conversation, each message sends everything from scratch for a fresh instance of this to process". Trying in various ways to pull back the curtain, show that there is no magic here, it's predictably unpredictable which is what makes it "lie" or "hallucinate" and what makes it so useful when used as a tool.
I think it really helps to have them ask questions in which they are a domain expert, and see what it says. Expose them to "The Plumber Problem" [0]. Honestly, I think seeing it be wrong so often in code or things about the project I'm using it for it what keeps me "grounded", the constant reminders that you have to stay on top of it, can't blindly trust what it says. I'm also glad I used it in the earlier stages to see when it was even "stupider", it's better now but the fundamental issues still lurk and surface regularly, if less regularly than a year or two ago.
Agreed. One thing I’ve found striking is how far LLMs can get with pure language and the recognition that humans often operate with a similar kind of abstract conceptual reasoning that is purely language based and pretty far removed from facts and tenuously connected to objective reality. It takes a certain kind of mind to be curious and unpack the concepts that most of us take for granted most of the time. At best people don’t usually have time or patience to engage in that level of thinking, at worst it can actively lead to cognitive dissonance and anger. So of course a consumer chatbot is not going to be tuned to bring novel insight, it must default to some level of affirmation or it will fail as a product. One who is aware of this can work around it to some degree, but fundamentally the incentives will always push a consumer chatbot to essentially be junk food for the brain.
Sort of, but you need to separate the model from the interface. The base models pretty much think they’re you, and the chat stuff is bolted on top. It’s kind of a round peg square hole thing, or i.o.w. the whole may be less than the sum of the parts.
Longer term I dunno if statistics or “fits the shape of what a response might look like” is the right way of thinking about it either because what’s actually happening might change from under you. It’s possible given enough parameters anything humans care about is separable. The process of discovering those numbers and the numbers themselves are different.
Six decades later and we're still trying to explain to people the same things[1]:
> Some of ELIZA's responses were so convincing that Weizenbaum and several others have anecdotes of users becoming emotionally attached to the program, occasionally forgetting that they were conversing with a computer. Weizenbaum's own secretary reportedly asked Weizenbaum to leave the room so that she and ELIZA could have a real conversation. Weizenbaum was surprised by this, later writing: "I had not realized ... that extremely short exposures to a relatively simple computer program could induce powerful delusional thinking in quite normal people."
I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful; it should be unambiguous now get back to the unabbreviated form. For whatever reason, people seem to love trying to optimize for character count with abbreviations that actually make things more confusing (like `res` in a context where it might mean either "response" or "result).
I just don't get the obsession with terseness when we have modern tooling. I don't type particularly fast, but autocomplete makes it pretty quick for me to type out even longer names, and any decent formatter will split up long lines automatically in a way that's usually sane (and in my experience, the times when it's annoying are usually due to something like a function with way too many arguments or people not wanting to put a subexpression in a separate variable because I guess they don't know that the compiler will just inline it) rather than the names being a few characters too many.
Meanwhile, pretty much everywhere I've worked has had at least some concerns about code reviews either already being or potentially becoming a burden on the team due to the amount of time and effort it takes to read through someone else's code. I feel like more emphasis on making code readable rather than just functional and quick to write would be a sensible thing to consider, but somehow it never seems to be part of the discussion.
> and any decent formatter will split up long lines
Any decent editor can wrap long lines on demand. But it's even better not to have to do either of those if not necessary.
> I've felt strongly for a while now that abbreviations should be "lossless" in order to be useful
This is how we got lpszClassName. The world moved away from hungarian notation and even away from defining types for variables in some contexts (auto in cpp, := in Go, var in Java). Often it just adds noise and makes it harder to understand the code at a glance, not easier.
I'd argue there's a stark difference between abbreviating words and adding extra ones. `p` as a shorthand for `person` is silly to me, but that doesn't mean that `personObject` would also be silly to me. I fundamentally don't agree with the premise that it's possible to be too verbose means that terseness is its own goal; the goal should be clarity, and I don't think that lossy abbreviations actually help with that except when someone already knows what the code is doing, in which case they don't need to read it in the first place.
Yes, you will. This is what the setting says on my account when I clicked the link:
> model training
> Allow GitHub to collect and use my Inputs, Outputs, and associated context to train and improve AI models. Read more in the Privacy Statement
Are you seriously trying to claim that the code isn't input, output, or associated context of Copilot operating on a private repo? What term do you think better applies to the code that's being read as input, used as context, and potentially produced as output?
I don't like that they are training on any interactions with Copilot by default but training on something that you've put through Copilot yourself is much different than them just shoving all the private repos currently on Github into the training data.
I don't use Copilot, and I don't have anything I particularly care about in private repos on my account on Github. My reaction here is entirely based on principles, not how I'm going to be personally affected.
reply