[drschwabe]

When I first read the source for his original QuickJS implementation I was amazed to discover he created the entirety of JavaScript in a single xxx thousand line C file (more or less).

That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.

[kvemkon]

SQLite 3.51.1

  $ wc -l ...
  265908 sqlite-amalgamation-3510100/sqlite3.c

Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.

[nine_k]

The sqlite3.c file is generated from more finely-grained real sources, see https://www.sqlite.org/src/doc/trunk/README.md

[qznc]

SQLite is only deployed as a single file but the original sources are multiple files. They call it "The Amalgamation".

https://sqlite.org/src/doc/trunk/README.md

[kvemkon]

Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.

[nine_k]

From my daily-use utilities, ripgrep and bat seem to have zero dependencies.

[kzrdude]

I believe ripgrep has only or mostly dependencies that the main author also controls. It's structured so that ripgrep depends on regex crates by the same author, for example.

[kvemkon]

Looking at Cargo.toml, ripgrep seems to have some dependencies and bat has a lot.

[zdragnar]

I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.

I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful.

Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you organize your thoughts, digging through thousands of lines of code all in the same scope can be exceptionally painful.

[antirez]

C has no problems splitting programs in N files, to be honest.

The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.

At some point you mainly split for compilation time and to better orient yourself into the file, instead of having to seek a very large mega-file. Pointing the finger to some program that is well written because it's a single file, strlongly correlates to being not a very expert programmer.

[neomantra]

The file granularity you chose was at the perfect level for somebody to approach the source code and understand how Redis worked. It was my favorite codebases to peruse and hack. It’s been a decade and my memory palace there is still strong.

It reminded me how important organization is to a project and certainly influenced me, especially applied in areas like Golang package design. Deeply appreciate it all, thank you.

[uecker]

I split to enforce encapsulation by defining interfaces in headers based on incomplete structure types. So it helps me with he conceptually separated module boundaries. Super fast compilation is another benefit.

[inopinatus]

Reminds of one time when I was pair programming and the other chair said “let’s chop this up, it’s too long” and when I queried the motivation (because I didn’t think it was too long), it was something like, “I’m very visual, seeing the file tree helps me reason about internals”. Fair enough, I thought at the time, whatever makes us more productive together.

On reflection, however, I’m unsure how that goes when working on higher-order abstractions or cross-cutting concerns that haven’t been refactored, and it’s too late to ask.

[lelanthran]

> complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.

You probably don't need this, but ...

https://www.lelanthran.com/chap13/content.html

[sfpotter]

C's support for modularity is actually rather strong. This PDF gives a good overview of the basic techniques available: http://www.metamodulaire.org/Computing/modular-c.pdf

It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).

I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.

[drschwabe]

Unironically JavaScript is quite good for single file projects (albeit a package.json usually needed)

You can do a huge website entirely in a single file with NodeJS; you can stick re-usable templates in vars and absue multi-line strings (template literals) for all your various content and markup. If you get crafty you can embed clientside code in your 'server.js' too or take it to the next level and use C++ multi-line string literals to wrap all your JS ie- client.js, server.js and package.json in a single .cpp file

[lelanthran]

> I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.

You don't program much in C, do you?