That definitely wasn't the intention! 
It's a tongue-in-cheek word play on the Rust's crab mascot (which is the opposite of gross, as I believe) & the critter from the Half-Life universe, which uhh... attaches itself to a host - and that's something we do with debuggers, too. You can find an attempt at our own mascot on the website.
Indeed, there are at least a couple of them: goblin and gimli. We use the latter.
My 10 cents: I think it's cool, and the mascot is cute.
And I really need a debugger.
Rust's crab mascot is fine. It's all about context and juxtaposition.
I'm old school, I have no idea what "half life" unless it's about radio active decay. "headcrab" just conjures up head lice and crabs in my mind. Grossness I'd rather be reminded of.
What you describe about the Half-Life critters makes them sound like Toxoplasma gondii https://www.discovermagazine.com/planet-earth/meet-the-parasites-that-control-human-brains. Even more gross!
Half Life is a game series, first game was released way back in 1998, that's pretty old school by now.
I have heard of it.
The first and last computer game I bought was Starglider for my Atari ST 520. In 1987. https://en.wikipedia.org/wiki/Starglider
After many hours of tenaciously playing Starglider I hit it's maximum score of 100,000. At that point the game ended and it gave me a ranking of "Cheat".
I lost interest in games after that.
I see Headcrab is still making the buzz.
That name is genius!
I was wondering if you would have a syntax checker for imports in the toml file? I made a spelling error there and the compiler, very helpfully pointed me to faulty imports, but I did not understand that it was originated in the toml file.
Awesome project. The premise sounds really ambitious. Looking forward to where this project will go.
Love the name and the symbolism behind the name too 
Please file gdb bug reports for problems you find. There's a "rust" component there that you can use. Thanks.
Hi!
The problem was that gdb was not codesigned. Could be solved by following those instructions until point 9, and then those instructions from 1.3 (since the drag to systems keychain did not produce a cert file on Desktop)
I am pretty sure many people reported that already, but if you want I can file a report 
Classic!
Thanks for working this. The debugging experience in Rust could definitely be better.
You mention async in your blogpost. It's indeed really hard to debug deadlocks in tokio, for example, with GDB. Hope this will improve in the future
Hi everyone,
This month has flown by already, and we have another project update!
To highlight just a few changes, here's what's been improved this month:
You can find a full list of changes in the newsletter on our website, along with a demo for the command line example.
It is fantastic to hear your progress. I am waiting for your release. I love rust but I am not able to propose it as an alternative lang due to its debugger support. I use VSCode in windows and I have tried vscode-lldb and vsdbg. Out of these two, I felt the latter is better but not the best. Some points I hate with current debuggers,
struct.read().field1 == 1 is not supported)
The problem here is that serious optimization involves significant code transformation, including assigning values to registers, potentially in a computationally-altered form, and moving loop-invariant subexpression computations out of loops and control-flow-invariant subexpressions out of if/then/else and match structures. Such optimizations do not leave artifacts that the debugger/programmer can directly relate to source program variables and expressions.
You are right @TomP. However, why is it so slow compared to other lang (C#, pascal etc)? For proving the capability of Rust, I tried porting a pascal code. I am definitely getting 25% improvement in release which is great. However, I am having slow debug which is almost x5 times slower than the pascal. From other sources, I could see praise for pascal in its debug performance but x5 times slower is really unacceptable in my case. Now I am having hard time in convincing my team .
Just to clarify, is it slow both when you run the code in debug mode normally (i.e. cargo run from the command line) and under the debugger, or only under the debugger?
Rust uses lots of abstractions which only become zero-cost after optimisation. The debug mode contains next to no optimisations (deliberately, it's hard to debug optimised code) and is well known for generating slow code.
It's not uncommon that newbies come to this forum saying "my rust code is slower than this Python equivalent" because they've just done cargo run, then are blown away when they are told to use cargo run --release and the code is 1000x faster.
If this slow down only happens under the debugger, then I'd make an issue upstream.
This doesn't just happen to newbies and is actually a very valid concern. I think it is wrong to make dev mode the default for cargo build and cargo run; not just is the debuggability of Rust programs very limited in general but dev also has a number of serious issues such as:
dev mode enables debug assertions unconditionallyoff is often not an option, e.g. in embedded it is quite typical that a program without optiomisations will not even fit into the flash of a MCU, if you have a tiny MCU even a LED blinky will not even link due to size problems. Also things which are "guaranteed" to be zero-cost like a compiler_fence() will suddenly turn into real code including a panicking branch: https://github.com/rust-lang/rust/issues/68208. Also trivial things will suddenly be so inefficient and slow that using some peripherals (e.g. USB) will simply not work in that setting.Other languages do a whole better here and people are not only used to that ability but it can actually be a show-stopper for Rust usage.
Personally, I couldn't care less about classical debuggers, but there's a whole lot more attached to the ability to generate debuggable code and Rust really is very sub-par here.
I'm curious to know what you feel is missing here.
Reaching for a "classical debugger" has been my last resort in all kind of languages, including assembler, for decades having often found that when a bug is hard proving hard to find then building for and using a debugger hides the bug, make stings worse or cannot even be used. As you point out for embedded systems.
Luckily the need to reach for such a debugger is greatly reduced in Rust as it eliminates all those insidious memory and type errors.
In a nutshell what I wrote above wrt to light optimisations. But Rust has additional challenges due to the lack of language support within the usual debuggers which is hopefully what headcrab is going to rectify. In the last few months the embedded folks have massively stepped up their game with respect to tooling, e.g. via https://probe.rs.
Now all we need is a usable debugger. 
I fully agree, people around me appreciate that because they know when I reach for a debugger, the shit has just hit the fan and things are about get ugly in my vicinity... 
My personal experience with debuggers so far has been the following:
println! is easier than a debugger. Pretty much only when a program hangs do I use a debugger to get a backtrace.#[derive(Debug)] equivalent and many of my bugs are caused by memory corruption.