BCHS stack – BSD, C, httpd, SQLite
learnbchs.org
learnbchs.org
That said, you mention PHP, I wonder how PHP running in HHVM compares to a more bare metal solution (or regular interpreted PHP).
https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
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++ certainly wont die in another 20 yers, so you happy using it for long-term projects.
The concern is less the death of C++ and more exposing C over the web, which exponentially increases the damage of any mistake you make (likewise C++ though likely with a lower exponent).
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?
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.)
Yes. I don't need any micro-freezes.
> Are you seriously implying that C was not designed for large projects?
C was designed to move from asm to something highlevel. C made possible to write larger projects than in ASM. That's all. There is no absulute measurement of project size, only relative: larger->smaller. Go goes to "smaller" direction compared to C++.
All that arguments about safe/bugs etc is old. In modern C++ you write with no controlling memory allocation at all and you dont write your own arrays with can be overflown.
People say this, but they never point to any large, popular projects that demonstrate it.
If you write any serious project in Rust, you'll quickly realize how unsafe "modern" C++ is. There's just no comparison. I'm happy for people to pick whatever memory safe language meets their needs, and most of those are garbage collected. Garbage collectors are fine for most software, but Rust exists for situations where they aren't fine.
> C was designed to move from asm to something highlevel. C made possible to write larger projects than in ASM. That's all. There is no absulute measurement of project size, only relative: larger->smaller. Go goes to "smaller" direction compared to C++.
By your definition, everyone should be writing Haskell, because a single line of Haskell can take tens of lines of C++ to express the same code. Haskell is immensely powerful in this way.
The simplest and most straightforward way to access an std::vector item allows OOB read. Literally every smart pointer an be empty and will UB with no warning if deref'd in that state (that includes the brand new std::optional). The rules of X remain a tarpit lined with shit-smeared stakes, Chrome got bit by a GDI leak just a pair of years back because of that (a refactoring in an RAII object removed an operator= overload and started leaking GDI handles by the hundred when using chrome remote desktop).
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.
On the contrary, one of the motivators for building Go was for large (millions of LOC) codebases; build speed and how fast a developer is comfortable in the codebase were big motivators for its build pipeline and code style.
Go is / feels a lot more minimalistic, much less drama and more direct code. Less opportunities to be clever.
My build system is a makefile, and it feels like I'm parodying myself and the entire industry.
Is this the same?
I still use httpd as the proxy but use compiled Go executables for CGI.
> Yes. But some folks confused humour with levity.
Time to fire up the Wayback machine ;)
Last time I checked httpd didn't support http/2.
httpd's config syntax is mostly sane and error messages are mostly legible, and that it's written by OpenBSD's core devs inspires confidence. I recommend that system admins at least give it a try, especially if they've already decided to use OpenBSD. It can't do everything but I think it does enough to meet the needs of 80% of the web's sites.
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.
Some would argue that's a feature.
"Worried about performance issues? Not when your site LAGS!"
Has a nice ring to it. Maybe advertised as BACHS - a truly baroque stack
I think the best use case would be some static content delivery coupled with a few dynamic pages and APIs backed up by SQLite here and there ...
Some references would be cool I guess. Anyone?
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).
Seriously, how are you supposed to pronounce BCHS?