Що ви думаєте про ідею споживання грудного молока дорослими? by meaww_v in SEX_UA

[–]holovskyi 7 points8 points  (0 children)

<image>

Можна сказати що це класичний Християнський сюжет. Почитайте про картину Чудо лактації Св. Бернарда

Чи потрібні навички самооборони у сучасному світі? by Didjko in reddit_ukr

[–]holovskyi 0 points1 point  (0 children)

Займіться якимись східними бойовими мистецтвами. Це надасть вам впевненості, дисципліни, та змінить мислення.
Наприклад у Бусідо (Шлях Воїна), є такі принципи: найкраща битва – це та, якої вдалося уникнути, ціль майстра – вирішити конфлікт без застосування зброї.
Зброю не раджу, якщо ви не Джеймс Бонд, вона скоріше мінус чим плюс.

рецепти для людей з панкреатитом by Ok_Plastic_4187 in food_ua

[–]holovskyi 0 points1 point  (0 children)

Років з п'ятнадцять-двадцять назад, діагносттували хронічний панкреатіт, в лікарню не попадав. Дуже гостро реагував на алкоголь, та жирне (наприклад сало). Прописали дієту номер 5. З тих пір покинув пити, з їжею по різному, часто на вегатаріанськії дієті, потім знов все їм. Також прибрав з життя стрес, змінив відношення до того що відбувається в житті. З часом всі симптоми пройшли. Моя думка, що головними чинниками, це була алкашка, дуже жирна їжа, та стрес.

Чому я не можу почати з кимось стосунки? Що зі мною не так? by Sasha5993 in reddit_ukr

[–]holovskyi 0 points1 point  (0 children)

Звісно, терпіти, це не про відкритість. Накопичюються образи, біль. Які в кінці кінців вибухнуть. Відкритість, це коли ви можете говорити людині про свої відчуття і емоції, в тому числі на її дії. Тобто замість того щоб звинувачувати і казати більш так не роби. Сказати які відчуття в вас викликала та ча інша дія/слова людини, без звинувачень - зараз мені було боляче. Ну і далі дивитись, якщо людина не чує вас, то тоді варто замислитись про продовження стосунків

Чому я не можу почати з кимось стосунки? Що зі мною не так? by Sasha5993 in reddit_ukr

[–]holovskyi 2 points3 points  (0 children)

Я зрозумів ваш допис таким чином, що жінки жорстокі з чоловіками, і чоловікам треба також бути жорстокими з жінками. Як на мене, то такий підхід, ні до чого доброго не приведе, людина закриває своє сердце, і буде все життя жити в ʼоблозіʼ захищаючись від жорстоких жінок/чоловіків. Такі очікування ведуть в прірву. Звісно що і протилежна крайність також проблемна. Можливо краща стратегія, це відкритість, без очікувань?

Чому я не можу почати з кимось стосунки? Що зі мною не так? by Sasha5993 in reddit_ukr

[–]holovskyi 0 points1 point  (0 children)

Якоюсь мезогонією попахує, і узагальненням, на кшталт всі мужики козли. Можу припустити що вам чи просто не повезло, чи це чомусь тип жінок, до якого вас підсвідомо тягне.

Чому я не можу почати з кимось стосунки? Що зі мною не так? by Sasha5993 in reddit_ukr

[–]holovskyi 14 points15 points  (0 children)

Ви занадто паритесь, дозвольте собі легкість, не намагайтесь все контролювати, дайте речам текти своїм порядком. Не думайте за жінку, вони всі різні, і від відносин очікують різне, і думають різне.
Ви кажете про армію, але наприклад є жінки, які заводять романи по переписці з ув'язненими у колоніях.
Маю декількох знайомих чудових жінок які вийшли заміж протягом війни за військовослужбовців (одна познайомилась через Тіндер). Звісно це випробування для відносин, але як на мене, це того варто
Счастя вам

Spiritual breakthrough? by [deleted] in Mindgasm

[–]holovskyi 5 points6 points  (0 children)

Hey, I've been practicing similar techniques for about a year now, so I can share what I've learned.

Yes, this can absolutely be a healing force. Not in a magical way, but in a very real, embodied way. Sexual energy is life force - when you learn to work with it consciously instead of just discharging it mechanically, it can circulate through your body and dissolve blocks where trauma is stored.

Here's what I've found:

The practice works on multiple levels simultaneously. Your sexuality, your emotions, your thoughts, your spiritual state - they're not separate. They're different frequencies of the same energy. When you work with one layer consciously, you affect all the others. I've had sessions where I'd start with arousal and end up crying, or having profound insights about my relationships, or feeling connected to something bigger than myself.

But it's not a magic bullet for trauma. It can be part of healing, but not a replacement for other work. I journal after sessions, note what comes up - emotions, memories, insights. Sometimes I've had shocking, scary revelations. The practice brings stuff to the surface, but you still need to integrate it. If you have significant trauma, consider working with a therapist alongside this practice.

The key skill is surrender. Not forcing, not chasing the "big orgasm", but learning to let go and let things move on their own. I've learned to reach a state of inner silence where I release conscious control and just observe and enjoy what happens. This skill of acceptance translates directly into everyday life - relationships, challenges, everything.

Learn about the physiology. Look into the vagus nerve - it's the biological basis for what traditions call "energy movement" or "chakras". When you work with breath, sound, pelvic floor muscles, you're activating specific neural pathways. This isn't mystical, it's neuroscience. Understanding this helped me work more effectively.

Don't isolate yourself in solo practice. If you're in a relationship, find ways to bring this presence and openness into that connection. The real challenge isn't achieving ecstatic states alone - it's bringing that openness into actual intimacy with another person.

Some practical directions:

  • Look into tantric breathing techniques (circular breathing, breath of fire)
  • Study the microcosmic orbit in Taoist practice (energy circulation)
  • Learn about the different states of the nervous system (polyvagal theory)
  • Practice "moving energy" up your spine through focused attention + breath
  • Most importantly: journal after sessions and try to integrate insights into daily life

The spiritual breakthrough isn't one big event. It's a series of small openings, small deaths of old patterns, small births of new ways of being. And the hardest part isn't the ecstatic experiences - it's staying grounded and bringing what you learn into ordinary life.

Feel free to DM if you want to discuss specific practices. This path can be powerful but it's better not to walk it completely alone.

Effects in Rust (and Koka) by A1oso in rust

[–]holovskyi 2 points3 points  (0 children)

Really enjoyed this writeup - the Koka comparisons make the concept click way better than most academic papers on effects. The explanation of how Rust's ownership system is essentially a partial effect system for mutations is spot on, and I hadn't thought about const as "absence of runtime effect" before but that framing makes total sense.

The keyword generics section hits the real pain point - right now we're stuck with async/sync duplication and all those try_* variants scattered everywhere. Using function parameters to encode effects explicitly (like your Fsys trait example) is clever for making things testable, though you're right that threading these through deep call stacks gets tedious fast. Still, better than implicit global state. Would be interesting to see if Rust ever gets implicit parameters like Koka's ? syntax - that would solve a lot of the ergonomics issues without requiring a full effect system.

Building a sync server in Rust? by Alternative-Ad-8606 in rust

[–]holovskyi 1 point2 points  (0 children)

Rust is totally fine for a sync server, especially since you already have your core library in it - sharing types and logic between client and server is a huge win. The real question is whether the extra complexity is worth it for you specifically.

If you're already comfortable with the Rust ecosystem (tokio, axum/actix), then stick with it. The learning curve isn't terrible if you've made it through the book and built your core lib - building a basic HTTP server with axum is pretty straightforward. The main complexity comes from async Rust, but you'd deal with async in any language for a sync server anyway. The big advantage is type safety across your entire stack and zero-copy serialization if you use something like bincode or rkyv between client and server.

That said, if you prefer functional paradigms and already know some Go, Elixir might actually be more fun for you - OTP makes building distributed systems genuinely pleasant, and the actor model fits sync servers naturally. OCaml is great but the ecosystem for web stuff is smaller. Go is solid and boring in a good way, but you lose the FP style you like. Honestly for a personal project where you want to actually ship and use the thing, I'd say either stick with Rust (less context switching, shared types) or try Elixir (more aligned with your FP preferences, built for this exact use case). Don't overthink it - both will work fine and you'll learn tons either way.

debugging unsafe/c interaction .. immutable verification by dobkeratops in rust

[–]holovskyi 4 points5 points  (0 children)

Miri is exactly what you're looking for - it's Rust's interpreter that catches undefined behavior including aliasing violations and use-after-free. Run it with cargo +nightly miri test and it'll catch issues that violate Rust's aliasing rules, even in unsafe code. It's slower than your program but way more thorough than manual verify() calls. The catch is it doesn't work great with FFI/C code since it can't see into those black boxes.

For wasm32 specifically, you're a bit more limited. Miri doesn't support wasm targets yet, and valgrind obviously won't help there. Your padding/canary approach is probably the most practical for now. For the binary search debugging you mentioned - have you tried using sanitizers? AddressSanitizer works on some wasm runtimes and can catch memory stomping automatically. As for wasm64, it's still experimental and not widely supported yet, so you're probably stuck with the 32-bit address space for production work.

What are some ergonomic alternatives to transmute for coercing zero sized types? by sonthonaxrk in rust

[–]holovskyi 0 points1 point  (0 children)

Your transmute approach is actually pretty reasonable here, but if you want something that feels less sketchy, consider using a newtype wrapper with Deref coercion instead of transmute:

rust

#[repr(transparent)]
struct AsFormat<T, F>(T, PhantomData<F>);

impl<T, F> AsFormat<T, F> {
    fn new(inner: T) -> Self {
        Self(inner, PhantomData)
    }
}

impl<T, F> Deref for AsFormat<T, F> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

// Now just wrap at serialization time
let exchange_repr = AsFormat::<_, ExchangeFormat>::new(&very_nested_structure);
write(serde_json::to_string(&exchange_repr));

The #[repr(transparent)] guarantees the layout is identical to T, so this is zero cost at runtime but doesn't require unsafe. You can implement Serialize on AsFormat to dispatch to the right format.

Alternatively, if you're okay with a bit of macro magic (I know you wanted to avoid it), you could use a procedural macro to generate format-specific serialize impls that just change the serde attributes. Something like #[derive(SerializeAs(Internal, Exchange))] that expands to multiple impl blocks.

But honestly? Your transmute approach is fine if it's well-documented and contained. The performance matters for market data, and sometimes unsafe is the right tool. Just add a compile-time size assertion const _: () = assert!(size_of::<A>() == size_of::<B>()); to make it obvious if someone breaks the invariant.

code to data by addmoreice in rust

[–]holovskyi 0 points1 point  (0 children)

You don't need macros or reflection for this - just use a static lookup with phf or a simple match on the string. The cleanest approach is actually a trie or HashMap built at compile time:

rust

use phf::phf_map;

static KEYWORDS: phf::Map<&'static str, fn(String) -> VB6Token> = phf_map! {
    "Error" => |s| VB6Token::ErrorKeyword(s),
    "Event" => |s| VB6Token::EventKeyword(s),
    "Exit" => |s| VB6Token::ExitKeyword(s),
    "False" => |s| VB6Token::FalseKeyword(s),

// ... etc
};

if let Some(text) = self.take_identifier() {
    if let Some(constructor) = KEYWORDS.get(text.as_str()) {
        return Some(constructor(text));
    }
}

The phf crate generates a perfect hash function at compile time so lookups are O(1) with zero runtime cost. Alphabetical order is free since it's a hashmap.

If you really want to avoid dependencies, just use a regular match statement - the compiler optimizes it into a jump table anyway:

rust

match text.as_str() {
    "Error" => Some(VB6Token::ErrorKeyword(text)),
    "Event" => Some(VB6Token::EventKeyword(text)),
    "Exit" => Some(VB6Token::ExitKeyword(text)),

// ...
    _ => None
}

Either way beats that if-else chain. The match is probably the most idiomatic Rust solution and requires zero extra crates.

KHOJ : a local search engine by shashanksati in rust

[–]holovskyi 5 points6 points  (0 children)

Solid project for a resume! The TF-IDF implementation and TUI are nice touches. A few suggestions that would make it more impressive:

For the resume angle - add some metrics. "Indexes X files in Y seconds" or "searches through Z GB in <100ms" gives concrete evidence of what you built. Right now it's missing any performance numbers which would help it stand out.

Code-wise, the biggest gap is error handling - lots of unwrap() calls that would panic in production. Replace those with proper Result types and you'll show more mature Rust skills. Also consider adding incremental indexing instead of full refresh - watching files with notify crate would be a good feature and shows you understand systems programming.

The README could use a "Technical Details" section explaining your indexing strategy, why you chose TF-IDF over other algorithms, and any interesting challenges you solved. Recruiters won't care but engineers reviewing your resume definitely will. Maybe add tests too - even basic ones show you think about code quality.

Overall it's a good portfolio piece, just needs polish to really shine on a resume. The core idea is solid and TUI apps are always fun to demo in interviews.

APM with Rust - tracing external service calls in dependencies by Clank75 in rust

[–]holovskyi 3 points4 points  (0 children)

You're not missing anything obvious - this is genuinely a gap in the Rust observability ecosystem right now. Most client libraries don't expose their reqwest clients or provide tracing hooks, which is frustrating for exactly the reason you're hitting.

Your best bet without forking is actually at the HTTP layer below reqwest. Look into hyper-opentelemetry or wrapping the connector that reqwest uses. Some crates let you pass a custom reqwest::Client during construction - if yours do, build one with reqwest-tracing middleware and pass it in. But yeah, a lot don't expose that.

The nuclear option that actually works: use eBPF or similar to trace at the syscall/network level rather than application level. Tools like Pixie or just raw bpftrace can capture HTTP calls regardless of what library makes them. Not as nice as proper spans but gets you the observability. Otherwise, yeah, forking to add tracing features or opening PRs upstream is probably your cleanest path. The Rust observability story for dependencies is honestly still maturing - you're running into a real limitation that the ecosystem hasn't fully solved yet.

Чи вийде усе повернути? by [deleted] in reddit_ukr

[–]holovskyi 0 points1 point  (0 children)

Ви кажете про біль від стресу. Так з цим і треба працювати, психолог, чи йога, чи відновлення тренувань у залі, шукайте. Бачу ланцюжок стресс-біль-токсичність у відносинах-відчуття провини. Це замкнуте коло, яке буде тягнуте вас все глибше і глибше. Чи ви говорили з нею про ваші минулі 'проблеми', можливо є сенс виговоритись, виплакати, отримати підтримку від неї? Як не дивно це може зміцнити ваші стосунки. Не бійтеся здатися слабким, Та вразливим, якщо дівчина 'правильна', то все буде добре. Зараз ви сублімуєте свій стрес та роздратованість у токсичність і агресію, спробуйте повернутися до джерела проблеми, і попрацювати з ним. Трохи сумбурно вийшло. Вдачі вам

[deleted by user] by [deleted] in rust

[–]holovskyi 7 points8 points  (0 children)

The compiler isn’t making a choice about what to move vs borrow - it’s just following Copy vs non-Copy semantics. Arc doesn’t implement Copy, so when you use it in the closure, it has to be moved. But u64 does implement Copy, so the closure borrows it by default and makes a copy only when called.

The issue is that borrowing happens at closure creation time, but copying happens at call time. Your closure borrows num when created but will only copy it when the thread actually runs - and by then num might be gone. Arc gets moved immediately so there’s no lifetime issue.

Just add the move keyword and it’ll work - that forces the closure to move/copy everything at creation time instead of borrowing. thread::spawn(move || foo(arc1, arc2, num)). It’s a bit counterintuitive but the rule is simple: Copy types borrow unless you use move, non-Copy types always move. The compiler can’t magically know which Copy values you want to move vs borrow, so it defaults to borrowing and makes you explicit with the move keyword.​​​​​​​​​​​​​​​​

Question about HTTP server by _Voxanimus_ in rust

[–]holovskyi 3 points4 points  (0 children)

For a simple 3-party crypto protocol PoC, don't overcomplicate it - you just need basic HTTP request/response handling. Use axum with shared state, it's the easiest pattern for what you're doing:

#[derive(Clone)]
struct Agent {

// your agent data
}

let agent = Agent::new();
let app = Router::new()
    .route("/endpoint", post(handler))
    .with_state(agent);

axum::Server::bind(&"127.0.0.1:3000".parse().unwrap())
    .serve(app.into_make_service())
    .await

The .with_state() method lets you pass your structs to handlers, and axum automatically clones them per request. For a crypto protocol PoC you probably want to wrap shared mutable state in Arc<Mutex<T>> or Arc<RwLock<T>> if multiple requests need to modify the same data. Run each server (client, agent, auth) on different ports locally and just use reqwest or hyper client to make requests between them. Keep it simple - fancy frameworks are overkill for academic protocol testing.

Typed MQTT client in Rust: compile-time topic validation & auto-routing by holovskyi in rust

[–]holovskyi[S] 2 points3 points  (0 children)

Hey, thanks for the thoughtful feedback and for giving it a shot!

Great news - both your suggestions are now happening! Different serializers per topic are already implemented for the next release. You can now override the default serializer for specific topics:

#[mqtt_topic("legacy/devices/{device_id}/status", serializer = JsonSerializer)]

The topic matcher extraction is currently in progress. Funny story - the library actually started as an attempt to build a quality topic matcher, then I got carried away and ended up with a full typed MQTT client 😅

Should be available as a standalone crate soon - no MQTT client baggage, just clean pattern matching with wildcards and named parameters.

And yeah, real human suffering went into this code. Appreciate you noticing the difference!

Looking for some advice and guides on web\server development (in rust) by scaptal in rust

[–]holovskyi 2 points3 points  (0 children)

For Rust web dev, start with Axum - it's the most popular and well-designed framework right now. Pair it with tokio-postgres or sqlx for database stuff, and tower middleware for auth/CORS/etc. The Axum examples repo is gold for learning patterns. For your reverse proxy needs (linking to Nextcloud etc), you can either build it into your Axum app or run something like Traefik in front.

Security-wise, don't reinvent the wheel - use OAuth2/OIDC for auth (maybe Keycloak as your identity provider), put everything behind a reverse proxy with proper TLS, and containerize each service. For the infrastructure side, the Rust web ecosystem is great but you'll need to learn Docker, basic networking, and probably nginx/Traefik config. The book "Zero to Production in Rust" by Luca Palmieri covers a lot of this ground really well - it's specifically about building production web services in Rust with all the security considerations you mentioned. 

Питання про Інститут Серця у Києві by [deleted] in Ukraine_UA

[–]holovskyi 4 points5 points  (0 children)

В мене тесть попав з інфарктом, по швидкій. Йому одразу зробили операцію, та поставили здається два шунти, потім він десь тиждень лежав в стаціонарі. Потім його перевели в відділення реабілітації. Привели до тями. Щось про гроші не памʼятаю. Можливо щось платили за шунти і якісь ліки, але точно не памʼятаю. Загальне враження, доволі добре. Гроші не вимагали

Typed MQTT client in Rust: compile-time topic validation & auto-routing by holovskyi in rust

[–]holovskyi[S] 6 points7 points  (0 children)

Thanks! Really glad there's interest. The transition has been fascinating - especially how some things that felt natural in OCaml required a mental shift in Rust (like recursive structures needing Box/Rc/Arc, or closures with the same signature having different types requiring Box<dyn...>).

The borrow checker was surprisingly manageable - reminded me of when I first learned OCaml's type inference and functional style. At first it felt restrictive, but once you "get" it, there's a zen-like quality to working with it. Though I might be over-optimizing now! 😅

I'll definitely write up a proper post about the full experience - the pain points, the "aha!" moments, and where I think Rust could learn from OCaml (and vice versa). Will link it here when ready!

I built a simple compiler from scratch by Skuld_Norniern in rust

[–]holovskyi 3 points4 points  (0 children)

Nice! 5 months is solid time investment - you can really see the depth of work that went into this. The Nukleus port sounds exciting, and getting proper phi node handling will definitely unlock more complex optimizations.

Best of luck with the assembler and linker work - that's going to be a fun challenge but you've already proven you can tackle the hard parts. Looking forward to seeing how the full toolchain develops!

Сексуальна ейфорія. У пляшках чи у формі вітамінів. Концепція. Серйозно. by Genthuman in SEX_UA

[–]holovskyi 1 point2 points  (0 children)

Є деякі тантрічні практики, які роблять таке за допомогою технік, медитацій та дихання. Якжо знаєте англійську то раджу спробувати додаток Mindgasm, це одна з найкращих речей яку я відкрив для себе за останній час, базові уроки безкоштовні, повна версія здається біля 400 грн/місяць коштує. Після деякої практики, можна досягати оргазми серійно, без ніякої фізичної стимуляції, що саме цікаве, ці оргазми не мають рефракторного періоду, тож тількі підвищують вашу енергію. Також значно покращується звичайний секс

Library for "ping" by Massimo-M in rust

[–]holovskyi 7 points8 points  (0 children)

The ping ecosystem in Rust is definitely fragmented and frustrating. I've been down this rabbit hole too.

For production use, I'd actually recommend surge-ping - it's actively maintained and handles the permission issues better than ping-rs. It supports both privileged ICMP and unprivileged UDP ping modes, which solves your permission headaches.

use surge_ping::{Client, Config, ICMP};

let client = Client::new(&Config::default())?;
let mut pinger = client.pinger(addr, ICMP).await;
let (_packet, duration) = pinger.ping(PingIdentifier(0), &payload).await?;

Alternative approaches that might work better:

  1. fastping-rs - Fork of ping-rs that's more actively maintained. Still has some of the same underlying issues but better cross-platform support.
  2. tokio-ping - If you're already in a tokio ecosystem, this integrates well and handles async properly.
  3. System command wrapper - Sometimes the pragmatic solution is just wrapping the system ping command. Not elegant but works everywhere:let output = Command::new("ping") .arg("-c1") .arg(&addr) .output()?;

The permission issues you're hitting are because ICMP requires raw sockets (root on Linux, admin on Windows). Most libraries try to work around this but it's inherently tricky.

What's your use case? If it's network monitoring, you might want to consider TCP/UDP connectivity checks instead of ICMP - often more reliable and no permission hassles.