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

BCHS stack – BSD, C, httpd, SQLite

learnbchs.org

Post reply on HN
Print view View original

41–50 of 59 posts

Re: BCHS stack – BSD, C, httpd, SQLite

#41

Post by coder543 »

sobakistodor wrote: post #35
masklinn wrote: post #31

Earlier quoted context omitted.

> Of if you planning to serve lost of requests AND want users to feel low latency responce, you have no options: Rust, Go, C++, maybe something else. That sounds like a lot of options. While I don't exactly like Go, that's very much the sort of things it was designed for, "stdlib-only" go will give you everything you need with pretty much guaranteed safety. > Main fight must occur on the "C++ vs Rust" scene, but C++…

As I remember, Go was "invented" to allow writing SMALL projects, where people previously used Bash/C/Perl. Like all these small command-line utilities and scripts to solve Site-Reliability-Engineer-tasks or DevOps-tasks. Using Go in projects larger than "multithreaded custom-binary-format to CSV converter" or "daemon watching sensors and inserting ROWS to some DB" is not very good. Big thing about GO is lots of libs…

> As I remember, Go was "invented" to allow writing SMALL projects

Absolutely not. It is an opinionated language that is designed to make it easier to build large projects.

Go is used for tons of large-scale web backends. It's a far better choice for writing network-connected services than C++, let alone C!

> Big thing about GO is lots of libs available for everything (but in that view Python is better).

Except that Go runs circles around Python, just like most compiled languages.

Based on what you've written, I don't believe you have any experience with Go, so why are you writing large comments about it?

Re: BCHS stack – BSD, C, httpd, SQLite

#43

Post by sobakistodor »

coder543 wrote: post #41
sobakistodor wrote: post #35

Earlier quoted context omitted.

As I remember, Go was "invented" to allow writing SMALL projects, where people previously used Bash/C/Perl. Like all these small command-line utilities and scripts to solve Site-Reliability-Engineer-tasks or DevOps-tasks. Using Go in projects larger than "multithreaded custom-binary-format to CSV converter" or "daemon watching sensors and inserting ROWS to some DB" is not very good. Big thing about GO is lots of libs…

> As I remember, Go was "invented" to allow writing SMALL projects Absolutely not. It is an opinionated language that is designed to make it easier to build large projects. Go is used for tons of large-scale web backends. It's a far better choice for writing network-connected services than C++, let alone C! > Big thing about GO is lots of libs available for everything (but in that view Python is better). Except that…

Have experience with GO. Feels like C in terms of lack of templates, and feels like Java in terms of "how I avoid world-freezes by GC". Go seems semantically less rich than C++ language makes you write MORE code for the same thing you would write in C++ using your HTTP-framework.

Re: BCHS stack – BSD, C, httpd, SQLite

#45

Post by fleetfox »

Cthulhu_ wrote: post #37
dangerface wrote: post #17

Doing web development in c and getting that sweet performance boost is very tempting but the time it takes to develop even a simple website is just not worth it. I would rather spend a few pound extra on servers and goto the cinema than the hours of developer time it would take to build PHP sites in C++

You can get the same performance boost without the footgun of C if you use e.g. Go, I've done so for a while now and I'm quite enamoured by it. Possible downside is that it ships with a runtime, so binaries are at least 10MB (before optimizing for size). That said, you mention PHP, I wonder how PHP running in HHVM compares to a more bare metal solution (or regular interpreted PHP).

Today there is little reason to use HHVM since modern PHP comes with JIT

Re: BCHS stack – BSD, C, httpd, SQLite

#46

Post by coder543 »

sobakistodor wrote: post #43
coder543 wrote: post #41

Earlier quoted context omitted.

> As I remember, Go was "invented" to allow writing SMALL projects Absolutely not. It is an opinionated language that is designed to make it easier to build large projects. Go is used for tons of large-scale web backends. It's a far better choice for writing network-connected services than C++, let alone C! > Big thing about GO is lots of libs available for everything (but in that view Python is better). Except that…

Have experience with GO. Feels like C in terms of lack of templates, and feels like Java in terms of "how I avoid world-freezes by GC". Go seems semantically less rich than C++ language makes you write MORE code for the same thing you would write in C++ using your HTTP-framework.

> feels like Java in terms of "how I avoid world-freezes by GC"

No… that’s not Go’s GC that you have experience with. I don’t know what language you used that you confused with Go. GC pauses in Go are notoriously tiny, since Go prioritizes consistently low latency. I’ve worked on many Go projects, and GC is not something that I worry about.

> Feels like C in terms of lack of templates

Are you seriously implying that C was not designed for large projects? That it was designed for tiny projects only? Because that’s not what history shows us, and C is used in massive projects like the Linux kernel. (Which causes innumerable CVEs related to human errors that C doesn’t attempt to prevent, unfortunately.)

It also doesn’t matter how fast you can churn out code if it’s Swiss cheese full of memory safety vulnerabilities. No one has ever pointed me to a popular C or C++ project that hasn’t been rife with vulnerabilities that would have been trivially avoided by using any memory safe language… so it’s a fair assumption that any C++ that you’re churning out has problems.

You mention Rust, and that’s a perfectly valid option if you have such a passionate hatred of garbage collectors. But, using C++ for a web service in 2021? No thanks. We need to be minimizing attack surface these days. (Memory safe languages can’t prevent all vulnerabilities, but neither do seatbelts. You should still wear a seatbelt when driving. Unbuckling doesn’t make the car go faster, and seatbelts do prevent certain classes of injuries.)

Re: BCHS stack – BSD, C, httpd, SQLite

#47

Post by MisterTea »

Cthulhu_ wrote: post #40

Makes me wonder what my stack would be abbreviated to. LAGS? (linux, apache, go, sqlite? Apache is optional. As is Linux.)

I like LAGS in as it's both comically ironic and self self-deprecating. You can then make all sorts of performance puns and jokes. e.g.

"Worried about performance issues? Not when your site LAGS!"

Re: BCHS stack – BSD, C, httpd, SQLite

#48

Post by 0x10c0fe11ce »

LAC-Tech wrote: post #9

Any one use open BSD to host servers? Last time I checked httpd didn't support http/2.

I’ve been running caddy on a FreeBSD jail proxying to another one running uwsgi+python3 and it has been a breath of fresh air.

Though, it comes with a somewhat steep learning curve.

But, in the end you can throw away that pesky search foo hat, and have some deserved peace of mind.

Re: BCHS stack – BSD, C, httpd, SQLite

#49

Post by masklinn »

sobakistodor wrote: post #35
masklinn wrote: post #31

Earlier quoted context omitted.

> Of if you planning to serve lost of requests AND want users to feel low latency responce, you have no options: Rust, Go, C++, maybe something else. That sounds like a lot of options. While I don't exactly like Go, that's very much the sort of things it was designed for, "stdlib-only" go will give you everything you need with pretty much guaranteed safety. > Main fight must occur on the "C++ vs Rust" scene, but C++…

As I remember, Go was "invented" to allow writing SMALL projects, where people previously used Bash/C/Perl. Like all these small command-line utilities and scripts to solve Site-Reliability-Engineer-tasks or DevOps-tasks. Using Go in projects larger than "multithreaded custom-binary-format to CSV converter" or "daemon watching sensors and inserting ROWS to some DB" is not very good. Big thing about GO is lots of libs…

> As I remember, Go was "invented" to allow writing SMALL projects

You remember wrong. Go was designed to allow quickly onboarding grads onto large projects.

> Like all these small command-line utilities and scripts to solve Site-Reliability-Engineer-tasks or DevOps-tasks.

I don't know what you're thinking about but it's certainly not Go: half the language is centered around concurrency, which is not very useful for this, especially going through the pain and costs "green" threads otherwise impose.

Go was designed to build network services and servers.

Re: BCHS stack – BSD, C, httpd, SQLite

#50

Post by 10000truths »

numlock86 wrote: post #21
pyuser583 wrote: post #7

Does anyone actually use this?

While I think quite a few people use this, I question the actual benefits. People often argue with performance, but unless you spend a lot of work into doing things right, the general "C backend" won't outperform even simple things like nodejs ... at least once you reach the realm of ten-thousands of requests per second coupled with more than just a static page, "hello world" and a for-loop. Same goes for the "DBMS"…

You can easily serve 10000 static requests/second per core on a modern server grade CPU over TLS with nginx, which is written in C. Slap node.js and express on top and you might dip to something like half of that.

But the real win with using C (or rather, using direct syscalls) comes from how much of that throughput you can retain while serving dynamic content. At least on Linux, performantly serving a static file would have a syscall flow similar to the following:

file -> splice -> pipe -> splice -> kTLS socket

The performance increase comes from copying the file to the socket without any detouring of the data via userspace. This can easily be adapted for the case where you need to inject portions of that file with dynamically retrieved content, by using offset fields in the splice call from the file being served, and manually writing to the pipe to inject the dynamic content. You cannot easily replicate this construct in any other dynamic-content server framework I know of - you have to do it manually in C (or any language that allows you to directly invoke system calls).

Post reply on HN