Live data from Hacker News

150k lines of vibe coded Elixir: The good, the bad and the ugly

getboothiq.com

31–40 of 91 posts

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#31

"It writes 100% of our code" - Silently closes the tab, and makes a remark to avoid given software at any cost.

You're not missing much. Seems to me like they wrote 150k lines of code for some glorified photo app with ChatGPT in the backend for image processing. Oh and some note-taking it seems.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#32
post #25
post #11

> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists. And it confuses Claude. This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they w…

Why not just write to the db? Just make every test independent, use uuids / random ids for ids.

[deleted]

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#34

It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.

Think of it as 60 man-years of work.

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#35

It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.

[flagged]

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#36
post #11

> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists. And it confuses Claude. This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they w…

I did too, and I've had a challenging time convincing people outside of those ecosystems that this is possible, reasonable, we've been doing it for over a decade.

[flagged]

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#37

It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.

[flagged]

Genuinely hard to tell if satire.

Just in case not, consider whether the short function

   def is_even(x):
      return (x%2) == 0
Handles a wider range of input conditions than the higher LOC function

   def is_even(x):
     if x == 0:
       return True
     if x == 2:
       return True
     if x == 4:
       return True
     ...
     return False

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#38

It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.

[flagged]

Yes, as we all know, when evaluating which programming language to use, you should get a line count of the compiler's repo. More lines = more capabilities.

Why would I ever want a language with less capabilities?

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#39

It's the second time today when I see that the higher number of LoC is served as something positive. I would put it strictly in "Ugly" category. I understand the business logic that says that as long as you can vibe code away from any problems, what's the point of even looking at the code.

[flagged]

> to the extent that our systems' world models are effectively indistinguishable from the real world.

https://genius.com/Jorge-luis-borges-on-exactitude-in-scienc...

Re: 150k lines of vibe coded Elixir: The good, the bad and the ugly

#40
post #25
post #11

> In Elixir tests, each test runs in a database transaction that rolls back at the end. Tests run async without hitting each other. No test data persists. And it confuses Claude. This way of running tests is also what Rails does, and AFAIK Django too. Tests are isolated and can be run in random order. Actually, Rails randomizes the order so if the are tests that for any reason depend on the order of execution, they w…

Why not just write to the db? Just make every test independent, use uuids / random ids for ids.

> Just make every test independent

That's easier said than done. Simple example: API that returns a count of all users in the database. The obvious correct implementation that will work would be just to `select count(*) from users`. But if some other test touches users table beforehand, it won't work. There is no uuid to latch onto here.

Post reply on HN