Ankit Pariyar - Full-stack Developer

AgentLoop

Unknown — Tue, 31 Mar 2026 00:00:00 +0000

Construction Twin

Unknown — Tue, 31 Mar 2026 00:00:00 +0000

Golang, the Halting Problem, and the Beauty of Unsolvable Questions

Unknown — Fri, 20 Feb 2026 00:00:00 +0000

What if we could write a Go function that tells us whether another function will run forever?</h2>

This question has a beauty to it.

As a programmer, I like the control. I like to design the system that behaves predictably. I reason about the inputs and the outputs. So it feels natural to ask:

Can we build a program that predicts the behavior of another program? </blockquote>

For example: Can we detect the infinite loop?

Lets try this with Golang. Here is the harmless looking function.

func</span> Infinite</span>(</span>)</span> {</span></span>
  for</span> {</span></span>
  }</span></span>
}</span></span></code></pre>
Now imagine we want to write</p>
func</span> Halts</span>(</span>program</span> func</span>(</span>)</span>)</span> bool</span></span></code></pre>
This Halts function will return true if the program will run forever and false if it will finish or halt.</p>
At first glance, this feels doable. After all, Go gives us goroutines, channels, timeouts. We’re not powerless.</p>
But in 1936, long before Go existed, Alan Turing proved something astonishing:</p>

No algorithm can universally determine whether another program halts.</p>
</blockquote>
This is known as the Halting problem</a>.</p>
What The Halting Problem Actually Says</h2>
Given:</p>

Any program P</code></li>
Any input I</code></li>
</ul>
Is there a function Halts(P, I)</code> that can always correctly answer:</p>

true → if P(I)</code> eventually stops</li>
false → if P(I)</code> runs forever</li>
</ul>
Turing proved: such a function cannot exist.</p>
This isn’t about Go. It isn’t about syntax. It isn’t about hardware limitations.
It’s about the fundamental limits of computation itself.</p>
Before diving into theory, though, let’s try to cheat.</p>
Attempt by using timeout</h2>
In Go, we might write something like this:</p>
func</span> Halts</span>(</span>program</span> func</span>(</span>)</span>,</span> timeout</span> time</span>.</span>Duration</span>)</span> bool</span> {</span></span>
	done</span> :=</span> make</span>(</span>chan</span> bool</span>)</span></span>
</span>
	go</span> func</span>(</span>)</span> {</span></span>
		program</span>(</span>)</span></span>
		done</span> <-</span> true</span></span>
	}</span>(</span>)</span></span>
</span>
	select</span> {</span></span>
	case</span> <-</span>done</span>:</span></span>
		return</span> true</span></span>
	case</span> <-</span>time</span>.</span>After</span>(</span>timeout</span>)</span>:</span></span>
		return</span> false</span></span>
	}</span></span>
}</span></span></code></pre>
We launch the program in the goroutine and wait for it to finish or timeout. If it finishes, we say it halts and return true.
If it times out, we say it runs forever and return false.</p>
But this is not solution but the guess, what if The program halts but after whatever timeout we set?</p>
The Paradox.</h2>
The real magic of Turing’s proof is self-reference.</p>
Suppose our function is perfect and always returns true if the program halts and false if it runs forever.</p>
func</span> Halts</span>(</span>program</span> func</span>(</span>)</span>)</span> bool</span></span></code></pre>
and we have this program:</p>
func</span> Paradox</span>(</span>program</span> func</span>(</span>)</span>)</span> {</span></span>
    if</span> Halts</span>(</span>program</span>)</span> {</span></span>
        for</span> {</span>}</span> //</span> loop forever</span></span>
    }</span></span>
}</span></span></code></pre>
Now what happens if we call:</p>
Paradox</span>(</span>Paradox</span>)</span></span></code></pre>
Lets reason about this:</p>


Case 1: Halts(Paradox)</code> returns true
That means Paradox</code> halts. But inside the Paradox</code> if Halts(program)</code> is true it will loop forever.
Which is a contradiction.</p>
</li>

Case 2: Halts(Paradox)</code> returns false
That means Paradox</code> runs forever. But inside the Paradox</code> if Halts(program)</code> is false the loop will skipped and Paradox</code> will halt.
Which is another contradiction.</p>
</li>
</ul>
So no matter what Halts returns, it will be wrong, only conclusion can be function like Halts</code> cannot exist.</p>
And this is what I like about the programming, we can even encode the paradoxes.</p>
Closing the loop</h2>
I started with simple question</p>

Can I write a Go function that detects infinite loops?</p>
</blockquote>
We can do approximate by doing something like timeout. But answer is no.
Not because Golang is weak or I am not smart enough. But structure of logic itself forbids it.</p>
And I find that beautiful.</p>



Preloading data with Rails: Includes, Preload, and Eager Load
Unknown — Sun, 14 Sep 2025 00:00:00 +0000
The N+1 query problem is one of the most common performance issues when working with ORMs. Rails' includes</code> method is the go-to solution for this.</p>
Includes</h2>
Rails' includes</code> method is smart. it dynamically chooses between different approaches based on our query structure.</p>
Under the hood, includes</code> typically delegates to preload</code>, but this behavior can change depending on the circumstances. This intelligence makes includes</code> the best way to solve the N+1 issues</p>
Preload</h2>
When we use preload</code> directly, or when includes</code> chooses it internally, Rails executes separate queries for each association:</p>
books</span> =</span> Book</span>.</span>preload</span>(</span>:</span>authors</span>)</span></span></code></pre>
This approach generates distinct queries: one for the primary records and additional queries for each association. For a book-author relationship, we would see something like:</p>
SELECT</span> *</span> FROM</span> books</span></span>
SELECT</span> *</span> FROM</span> authors </span>WHERE</span> id </span>IN</span> (</span>1</span>, </span>2</span>, </span>3</span>, ...)</span></span></code></pre>
The beauty of this approach lies in its simplicity and efficiency. Each query is straightforward, optimized, and Rails handles the data stitching in memory.</p>
Eager Load</h2>
The eager_load</code> method takes a different approach, combining everything into a single query using LEFT OUTER JOINs:</p>
books</span> =</span> Book</span>.</span>eager_load</span>(</span>:</span>authors</span>)</span></span></code></pre>
This generates a more complex query:</p>
SELECT</span> books.</span>*</span>, authors.</span>*</span> </span></span>
FROM</span> books </span></span>
LEFT OUTER JOIN</span> authors </span>ON</span> authors</span>.</span>id</span> =</span> books</span>.</span>author_id</span></span></code></pre>
While this reduces database round trips, it comes with trade-offs. The query becomes more complex, potentially slower, and can consume significantly more memory with large datasets.</p>
Joins</h2>
There's a third method that often causes confusion: joins</code>. This method creates INNER JOINs but critically doesn't load associated records into memory</strong>.</p>
books</span> =</span> Book</span>.</span>joins</span>(</span>:</span>authors</span>)</span>.</span>where</span>(</span>authors</span>:</span> {</span> published</span>:</span> true</span> }</span>)</span></span></code></pre>
This is perfect for filtering records based on association attributes, but if we try to access the associated data later, we will trigger the N+1 problem we were trying to avoid.</p>
When Includes Makes the Switch</h2>
Here's where includes</code> demonstrates its intelligence. When we add conditions that reference associated tables, includes</code> automatically switches from preload</code> to eager_load</code>:</p>
Book</span>.</span>includes</span>(</span>:</span>authors</span>)</span>.</span>where</span>(</span>authors</span>:</span> {</span> name</span>:</span> '</span>Stephen King</span>'</span> }</span>)</span></span></code></pre>
Rails makes this switch because it needs the association data available in the same query to apply the WHERE condition effectively.</p>


G-CRM API
Unknown — Mon, 01 Sep 2025 00:00:00 +0000



Language Scientific Platform
Unknown — Fri, 01 Aug 2025 00:00:00 +0000



Leave Balance
Unknown — Tue, 01 Jul 2025 00:00:00 +0000



PZNCheck
Unknown — Sun, 01 Jun 2025 00:00:00 +0000



Nettowelt Portal
Unknown — Thu, 01 May 2025 00:00:00 +0000


Set up RSpec, Shoulda matchers and FactoryBot on Rails 7
Unknown — Sun, 27 Apr 2025 00:00:00 +0000

This was originally published on Dev.to</a></p>
</blockquote>
Rspec</h2>


Add rspec-rails</code> on development and test group of Gemfile</p>
group </span>:</span>development</span>,</span> :</span>test</span> do</span></span>
  gem </span>'</span>rspec-rails</span>'</span></span>
end</span></span></code></pre>

Then install it with command bundle install</code></li>
</ul>
</li>

Run command rails generate rspec:install</code> for generating boilerplate config files. you can see following outputs:</p>
create  </span>.</span>rspec</span></span>
create  spec</span></span>
create  spec</span>/</span>spec_helper</span>.</span>rb</span></span>
create  spec</span>/</span>rails_helper</span>.</span>rb</span></span></code></pre></li>

Verify RSpec is correctly installed and configured by running bundle exec rspec</code> you should see following outputs:</p>
No</span> examples found</span>.</span></span>
Finished</span> in</span> 0.0002</span> seconds </span>(</span>files took </span>0.0351</span> seconds to</span></span>
load</span>)</span></span>
0</span> examples</span>,</span> 0</span> failures</span></span></code></pre></li>
</ul>
Shoulda Matchers</h2>


Shoulda Matchers provides useful one-liners for common tests.</p>
</li>

Add shoulda-matchers</code> to test group of Gemfile</p>
group </span>:</span>test</span> do</span></span>
  gem </span>'</span>shoulda-matchers</span>'</span></span>
end</span></span></code></pre>

Then install it with command bundle install</code></li>
</ul>
</li>

To integrate it to spec add following to bottom of the rails_helper.rb</code></p>
Shoulda</span>::</span>Matchers</span>.</span>configure</span> do</span> |</span>config</span>|</span></span>
  config</span>.</span>integrate</span> do</span> |</span>with</span>|</span></span>
    with</span>.</span>test_framework</span> :</span>rspec</span></span>
    with</span>.</span>library</span> :</span>rails</span></span>
  end</span></span>
end</span></span></code></pre></li>
</ul>
FactoryBot</h2>


Add factory_bot_rails</code> to Gemfile. We want this gem to available on all rails environments, add this gem on outside of any group blocks.</p>
gem </span>'</span>factory_bot_rails</span>'</span></span></code></pre>

Then install it with command bundle install</code></li>
</ul>
</li>

To use FactoryBot</code> inside the spec file require it in spec_helper.rb</code> file</p>
require</span> '</span>factory_bot_rails</span>'</span></span></code></pre></li>

Then in same file, inside of RSpec.configure</code> block add following line to use FactoryBot</code> methods without FactoryBot</code> namespace. For example we have to do FactoryBot.create</code> we can instead just use the create</code> method directly</p>
config</span>.</span>include</span> FactoryBot</span>::</span>Syntax</span>::</span>Methods</span></span></code></pre></li>

we want Rails model generator to use FactoryBot to create factory file stubs whenever we generate a new model. For this, require FactoryBot</code> on the top of config/application.rb</code></p>
require</span> '</span>factory_bot_rails</span>'</span></span></code></pre></li>

Then in the same file add following code inside the Application</code> class</p>
config</span>.</span>generators</span> do</span> |</span>g</span>|</span></span>
  g</span>.</span>test_framework</span> :</span>rspec</span>,</span> fixture</span>:</span> true</span></span>
  g</span>.</span>fixture_replacement</span> :</span>factory_bot</span>,</span> dir</span>:</span> '</span>spec/factories</span>'</span></span>
end</span></span></code></pre></li>
</ul>
Now RSpec, Shoulda Matchers, and FactoryBot are all set up and ready to help test your Rails application!</p>


GoForge
Unknown — Fri, 01 Mar 2024 00:00:00 +0000



ERB Commenter (VS Code Extension)
Unknown — Thu, 01 Feb 2024 00:00:00 +0000



Automate Me
Unknown — Mon, 01 Jan 2024 00:00:00 +0000