Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BCHS: OpenBSD, C, httpd and SQLite web stack

learnbchs.org

Post reply on HN
Print view View original

101–110 of 158 posts

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#101

Post by widdershins »

xondono wrote: post #90
1ris wrote: post #38

Earlier quoted context omitted.

It totally is, as long as you don't use C instead. There are plenty of good, less complex languages than C++ out there: Java is quite close and way, way less complex, for example. But C is non of them. Pointers are more complex in C than in C++ (pointer provenance). Casts are more complicated in C than in C++, as C++ named casts are less powerful and therefore give you less opportunity to shoot yourself in the foot.…

> There are plenty of good, less complex languages than C++ out there […] But C is non of them. To this day I cannot understand how anybody can claim that. C++ is so ridiculously complex that it’s not a superset of C mostly because of added keywords and rules , some of them implicit . > I suggest using a c++ compiler to write C with enum classes, std::span, either a typed std::span wrapper for malloc or std::vector ,…

You can think of simplicity in various ways - some subset of which are valid. For example, you could say that using std::unique_ptr is simpler than manual memory management, because it automates much of the process, making it less likely that a developer will make a mistake. Or you could say that the 1000s of lines of C++ std code that you will pull in represents an increase of complexity, because the mechanics are hidden under layers of abstraction.

I'm open to both views, and most importantly to trade-off one against the other according to other constraints and context. For me, using C++ allows me to do that, because it's (mostly) a superset of C. Acknowledging, of course, that this brings a trade-off of its own, because decisions must continually made (and enforced) about what std/external libraries to use and when.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#102

Post by LeFantome »

_ofdw wrote: post #56
littlestymaar wrote: post #24

Earlier quoted context omitted.

> Pair it with a better, more modern, and safer native-compiled language and get the same effect. Zig, Nim, Go, hell even Carp. I love how trollish it is not to talk about Rust in that context.

If we'd just rewrite all of the things in Rust we could solve computer bugs forever, and world hunger too.

This having to re-write things is obviously Rust’s fatal flaw.

I cannot wait for the next great language, the one that brings all Rust’s advantages which is a pure superset so that it can still compile existing code. Surely something like that ought to end all these petty language rivalries forever!

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#104

Post by tharne »

dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

It does seem sometimes that a lot of folks use C for philosophical rather than practical reasons.

That being said, I love seeing a push for simple stacks like this.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#105

Post by pull_my_finger »

zephyr9 wrote: post #27
dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

Is there a good string-manipulation C library?

Can't vouch for any in particular, but they do exist. https://github.com/oz123/awesome-c#string-manipulation

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#107

Post by enriquto »

da39a3ee wrote: post #96
josephcsible wrote: post #35

Earlier quoted context omitted.

> On my MacOS system I can’t rely on man x being the man page for the right version of x. But isn't that an issue with macOS, not an issue with man pages?

Yes, it is. But MacOS (and Windows) are popular OSs for laptop users. I'm the maintainer of a command line tool that is reasonably popular and I believe that the majority of my users are MacOS. So the question is quite concrete for me -- should I provide documentation in the form of a man page? I do not currently, for the reasons I gave above (although I made a mistake in saying Linux when I meant Linux and *BSD for…

> should I provide documentation in the form of a man page?

Yes, and this may be a much smaller effort than you suspect. Only by writing the output of --help in a certain order, you can use the "help2man" tool to generate a beautiful manpage automatically. Notice that your users do not need to have help2man installed, you run it yourself as part of your build process, to create the manpage from the latest source code.

It is very likely that if your tool already has a --help option, you don't really need to do anything to have a manpage. Just call help2man from your makefile.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#108

Post by [deleted] »

Zababa wrote: post #78
jimbob45 wrote: post #21

Earlier quoted context omitted.

Why would you ever choose C anymore? The killer feature of C++ is “you don’t pay for what you don’t use”. There’s virtually no reason ever not to use C++.

> The killer feature of C++ is “you don’t pay for what you don’t use” In what way C makes you pay for what you don't use?

[deleted]

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#109

Post by harryvederci »

jim_lawless wrote: post #91
harryvederci wrote: post #63

Interesting CGI content linked on there. I've been reading about / hacking on CGI recently, and it's been kinda fun! Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But hasn't ther…

It's not just the start-up and shut-down costs. A CGI process might need to attain connections to databases or other resources that could be pooled and re-used if the process didn't completely terminate. You might want to look at using FastCGI: https://en.wikipedia.org/wiki/FastCGI Basically, the CGI processes stay alive and the servers supporting FastCGI ( like Apache and nginx ) communicate with an existing FastCGI…

Thanks! That's a good point, about re-using connections.

For my current use-case* that wouldn't be an issue, so CGI could probably be OK there, then!

* A side project that uses SQLite (1 file per user), and no other external resources.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#110

Post by ascendantlogic »

_ofdw wrote: post #56
littlestymaar wrote: post #24

Earlier quoted context omitted.

> Pair it with a better, more modern, and safer native-compiled language and get the same effect. Zig, Nim, Go, hell even Carp. I love how trollish it is not to talk about Rust in that context.

If we'd just rewrite all of the things in Rust we could solve computer bugs forever, and world hunger too.

This is what the Rust Evangelism Strike Force™ told me and by God, I believe them.
Post reply on HN