A simple C implementation to stream H.264 to browser using WebRTC | Hacker News Reader

A simple C implementation to stream H.264 to browser using WebRTC

github.com

296 pointssepfy124 comments

This would be interesting to integrate into https://github.com/openmiko/openmiko which is a firmware for the T20 based ip-cameras.

Right now, I am not aware of any cheap ip camera that can stream its H264 video to a regular web browser, with sub 500 ms latency. All manufacturers seem to have moved to an app, I guess they can show an RTSP stream in that way.

Older ip cameras had MJPEG which you could view in the browser, but that is really inefficient w.r.t. bandwidth.

The stock Wyze and Xiaomi firmware for their T20 based cameras both use WebRTC to stream the video to their apps.

Any background info/links to this? The Wyze forum comes up empty, only some discussions on WebRTC being complex to add.

When the Pan cam was initially released I bought a couple of them and hacked on them for a while. examining the original firmware quickly revealed they were using WebRTC for the video. At least at the time almost all the cameras based on the Ingenic T series chips used the same backend service. It has been a couple of years so my memory fails on the name. The marketing material for the service mentioned the use of WebRTC.

Nice, this looks like a simple and clear proof of concept!

In practice, the dependency on libnice, which depends on glib, can be a problem for embedded devices.

That's actually why I developped libjuice [0] as the default ICE backend of libdatachannel [1].

[0] https://github.com/paullouisageneau/libjuice

[1] https://github.com/paullouisageneau/libdatachannel

I'm not very familiar with WebRTC & how the browser pulls video usually, in what way is this better?

Also, what benefits does WebRTC give over other protocols?

People mostly do this for lower latency.

WebRTC is generally for video conferencing as that requires real time communication.

Live streams or videos on the web are most commonly hls or dash protocols. Just mp4 file play while download also works.

Hls/dash are not built for lower latencies. They are built for easy CDN distribution and flexible switching between different resolutions and bitrates. Live streams generally are at least a few seconds behind.

What other protocols do you know that offer low latency almost real time video and all that in the browser?

There is RTSP but that does not work in browsers.

MPEG1 over WebSockets: https://jsmpeg.com/

The perf test page doesn't go over WS at all, it's just get requests.

How is it better than what?

My understanding: Most IP cameras only have an RTSP stream, which would need to be proxied expensively by some server if you want to view it over the internet or be exposed directly to the internet. WebRTC would allow the server to help negotiate a connection directly from client to camera, thereby bypassing having to host expensive proxy.

Not any more with IPv6 ?

If you have the time give WebRTC for the Curious[0] a read. I try and explain what WebRTC is and how it actually works. The big advantages that I see are.

* Can do P2P (and Client/Server)

* Mandatory Encryption

* Handles codec/track negotation. You don't need to know ahead of time what is being sent.

* Data channels. Can also be configured to be lossy/unordered for kind of performance needed for gaming.

* Uses existing protocols. Really easy to bridge with SIP/RTSP. This software/hardware goes all the way back to the late 90s

* Multiple implementations and available in the browser. No other protocol comes close in availability.

[0] https://webrtcforthecurious.com/docs/01-what-why-and-how/

Excellent website btw, thank you.

In complete sincerity, how is this better than ffmpeg

https://trac.ffmpeg.org/wiki/StreamingGuide

WebRTC with STUN is pure p2p where ffmpeg it requires a rtmp or rtsp server

Ahh I see

... how is STUN pure p2p ? you still need to have a STUN server somewhere no ?

You can just use google stun servers they are free to use

Here's a list of public STUN servers (non google too) https://www.voip-info.org/stun/

STUN is just for punching holes in your NAT router, and also discovering what is your public IP address. Both things will be needed for the other peer to know where to reach you. And the other way around.

Once this NAT thing has been done by both parts, and the actual communication has started directly P2P, STUN is not needed any more.

> STUN is just for punching holes in your NAT router, and also discovering what is your public IP address.

I know, but what I mean is that "true P2P" on our current internet architecture is not possible, you always need the help of a third party

If we are still in the 90's that definition of "true p2p" would be: two computers with both having public IPs and transferring packets via TCP. But nowadays we are always behind NATs so we became less strict with the definition of what is true p2p

Then bittorrent is transcendent p2p?

IPv6 is slowly taking over, hopefully in the near future being behind a NAT will be considered abnormal (just like happened with Unicode, we're around 35% = "Unicode 2009", popularity-wise).

You'd also need a TURN server if both peers are behind NAT without UPnP, which is very common. STUN alone wouldn't be enough.

That is partially incorrect, STUN can punch a hole through even when both sides uses NAT in many cases. That is what I would classify as STUN’s main feature.

Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.

Punching holes doesn't work only when network devices in between are broken or are actively preventing it.

From the network point of view it looks the same as two hosts starting an outgoing TCP connection through nat - if that works then hole punching should work too.

Not TCP. UDP - there are no connection in UDP, so the routers / firewalls don't really differentiate between a new connection and packets that happen to have the correct ip+port.

Some are trickier than others, as there are 2 IPs and 2 ports in a packet (at any point), and it can be hard to match all of them for the stricter devices, esp. on NATs that do source port randomization.

> when network devices in between are broken or are [maliciously] actively preventing it.

Those are called "middleboxes" (IIRC) and they're unfortunately somewhat pervasive.

Go read about stun.

You send outgoing packets simultaneously from both sides. Causing both sides to add nat translation entry’s to their nat tables. When the packets arrive both sides already have nat translation entries and the packets go right through the nat.

Your p2p nodes might not be behind NAT. In a lot of populations you can rely on everyone having working v6 for example.

I think the question of what's "pure" p2p is somewhat academic. If your app uses DNS, is it p2p, isn't DNS just a distributed p2p database? Does p2p require that every aspect of your app right down to discovery is distributed among nodes running your app? Is it cheating to use an existing DHT? etc.

Just for completeness sake this is what docs [1] state:

"For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). <...>"

[1] https://webrtc.org/getting-started/turn-server

It’s a little more nuanced than this.

https://medium.com/the-making-of-whereby/what-kind-of-turn-s... fippo pulled the stats and saw 17%

This also depends on your clients network. You can determine your NAT mapping type[0] and now ahead of time if you need a TURN server.

To understand NAT behaviors more check out [1]

[0] https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...

[1] https://webrtcforthecurious.com/docs/03-connecting/#nat-mapp...

Modern networks use IPv6 only, so don't have NAT.

Careful! P2P streaming video is a (completely non obvious, according to the courts) infringement of the VirNetX patent that for example Apple just had to pay a few billions of dollars for.

If you implement p2p video streaming chances are no company will want to touch it with a ten foot pole.

Um, shouldn't the patent have expired by now ?

Probably not or it would have been on the news and you would start seeing p2p communications again. It’s not rocket science, after all.

But p2p streaming has been around since the mid 2000's ?? (Pre-Microsoft Skype, Miro, Joost, Tribler...)

And for some recent examples : what about Popcorn Time ? Or PeerTube ?

EDIT : Oh, I guess that most of those are technically not "streaming", but "watching while downloading" like YouTube or FTP+VLC ?

The court does not agree with you. A peer to peer communication service, like FaceTime was originally, violates the patents.

Ok, so : when was this patent approved, and when does it expire ?

I think this year but I suggest you look it up yourself, they probably are mentioned in the court documents and the dates are public.

I can't find any specific dates (and I'm not going to go fishing into court documents), but wow, this has been going on for more than a decade now !

https://en.wikipedia.org/wiki/VirnetX

> Separately, in December 2014, Microsoft and VirnetX settled patent disputes over Skype technology for $23 million.

It's certainly not better than FFmpeg. But I had a look through the source code and the author seems to have a fairly good grasp of WebRTC. The library looks really useful for anyone that wants to quickly understand WebRTC and how to use librtp and libsrtp. It's mostly a bare-bone wrapper around those libs.

Maybe it would be a good starting point for someone integrating it into ffmpeg

Yep, it looks easy to replace the function h264_get_next_frame(). I think you could get really decent performance if you used ffmpeg to pre-extract all of the frames into sequential files and serve them statically.

If you're using ffmpeg with rtp, you can use Pion to make it a WebRTC stream: https://github.com/pion/webrtc/tree/master/examples/rtp-to-w...

I've seen a few WebRTC server implementations pop up recently but the only clients I have seen are web browsers. Does anyone know of any WebRTC client implementations apart from the browser? Or am I misunderstanding the WebRTC architecture completely?

Windows, https://github.com/microsoft/winrtc

At a low level, webrtc interoperates with VoIP. But because webrtc doesn't mandate a signalling protocol and VoIP uses SIP, generally you need a browser to run whatever proprietary signalling the site decided to implement in JS.

Matrix can also function as a signaling layer for WebRTC.

Anything can function as the signaling layer since all you need is to exchange pieces of text. I think the point was that most sites choose to implement it using JS and browser API's like ajax, websocket or SSE.

The official one, pion (go) and webrtc-rs (rust) can all be used on both sides.

pion link: https://github.com/pion/webrtc

Is webrtc-rs usable? There are ticks missing for Media or DataChannel and PeerConnection. Aren't these required to do anything useful?

I think webrtc-rs is still in early development. libdatachannel has Rust bindings though: https://github.com/lerouxrgd/datachannel-rs

libdatachannel (C/C++) can also be used on both sides: https://github.com/paullouisageneau/libdatachannel

Because webrtc came from the chromium source code so you got it installed already on your browser. Then Google took it out there and made it stand alone library so you can use it on apps. I see webrtc projects occasionally here on Show HN threads

The Python library aiortc, https://github.com/aiortc/aiortc, enables client and server side communication via WebRTC.

Gstreamer. Example at https://github.com/centricular/gstwebrtc-demos/tree/master/s...

A lot of video call applications use WebRTC, I'm pretty sure slack uses it (although not in P2P mode, they use a SFU).

If you are interested in desktop implementations, you can access the telegram desktop source code, which also uses WebRTC: https://github.com/telegramdesktop/tdesktop/blob/a506e9b9eb7...

I believe that clients are available for most native MobileMe platforms as well.

https://webrtc.github.io/webrtc-org/native-code/android/

https://webrtc.github.io/webrtc-org/native-code/ios/

There are lots of implementations now! Here are the ones I know about.

* https://github.com/aiortc/aiortc (Python)

* GStreamer’s webrtcbin (C)

* https://github.com/shinyoshiaki/werift-webrtc (Typescript)

* https://github.com/pion/webrtc (Golang)

* https://github.com/webrtc-rs/webrtc (Rust)

* https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded)

* https://webrtc.googlesource.com/src/ (C++)

* https://github.com/rawrtc/rawrtc (C++)

* https://github.com/sipsorcery-org/sipsorcery (C#)

* https://github.com/paullouisageneau/libdatachannel (C++)

Also check out https://github.com/sipsorcery/webrtc-echoes for how they work together

What about Node.js clients??

To record meetings without sacrificing end to end encryption

Just a nitpick: RAWRTC is actually written in C (also I think it focuses on data channels only).

Can you provide an example that streams from a v4l device?

How the world has changed that running something on a raspberry pi counts as "embedded".

I was expecting this to be on some microcontroller...

For how many years do you want to keep defining embedded as single core, no MMU with a relatively low clock?

And in the same vein : settopboxes are considered embedded. TiVo's are.

For how many years do you want to keep blurring the line between running on top of a cushy OS and running on bare metal with no OS at all?

"Embedded" is a property of how the box is deployed, not what's inside it. The lines are blurring because the word "embedded" has been overloaded with an interpretation it doesn't merit for too long. If you mean "bare metal", say "bare metal". Mind you, if you're going to argue "no OS at all" is part of the criteria, FreeRTOS and the like are banned, right?

Personally, I'd say that FreeRTOS is just on the line, but others may draw that line differently. However, I do take your point about changing interpretations.

No way! The only way to be on the baremetal side of the line is manual activation of transistors using a telegraph key powered by a lemon...

> For how many years do you want to keep defining embedded as single core, no MMU with a relatively low clock?

All of the years; all of them forever.

Nothing has changed. Small Linux systems have been a staple of the embedded systems world for a long time.

> How the world has changed...

Was this before of after the release of Windows XP Embedded?

Admittedly, I'm no expert on this subject, but this code looks like it could run on an embedded device. I don't see any system calls, and it looks to rely mostly on the standard library. glib.h is used in dtls_transport, but I suspect you can replace the certificate mechanism with something else.

It's time to move on I think. There are still plenty around but the world is going toward bigger and more.

The code contains things that make any modern C++ or Rust developer cringe: naked pointers, unsafe type casts, raw loops, using malloc/free to manually allocate memory for buffers, and calls to unsafe free functions like strcat. So much slow boilerplate is required to do things like handling memory allocation. The increased source code size for even the simplest things becomes harder to maintain.

Danger is waiting around every corner for you to commit a buffer overflow or type confusion error after a long day of work. Infinite chances are offered for you to leak memory. The alternative is that you could be using a language that uses highly optimized RAII types on the stack which are impossible to leak, and written by some of the best programmers in the world so you don’t have to juggle chainsaws.

C invites disaster through seemingly normal use of the language. Just embrace modernity; your code will be smaller, more expressive, more performant, and you’ll be grateful.

> The alternative is that you could be using a language that uses highly optimized RAII types on the stack which are impossible to leak, and written by some of the best programmers in the world so you don’t have to juggle chainsaws.

Please, tell "the best programmers" that it's "impossible to leak" memory. Apparently they do not know this.

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Leak can mean different things. None of those types in the link are stack allocated, I think.

Thanks for sharing, I’m unfamiliar with the nuances of Rust’s implementation of RAII as I’m primarily a modern C++ developer. Modern C++ mostly guarantees against leaks since it encourages the stack as much possible.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

It's the same deal as creating a circular references using `std::shared_ptr` in C++.

Ownership semantics in rust largely prevent circular references, so it's not the same deal

Sorry, I'm not a Rust pro, but from the docs about reference cycles linked above:

> We can see that Rust allows memory leaks by using Rc<T> and RefCell<T>: it’s possible to create references where items refer to each other in a cycle. This creates memory leaks because the reference count of each item in the cycle will never reach 0, and the values will never be dropped.

This sounds a lot like what happens when you create a circular reference with std::shared_ptr ?

Yes, it is the same thing.

Yes, but grep for `Rc::new()` in actual rust code bases compared to `shared_ptr` in C++. Interior mutability is cumbersome and not a natural pattern in practice.

C with Asan or Valgrind is faster to write and just as performant (usually better) as Rust or C++. There's a reason the world runs on C, and only part of it is historical.

I just can’t recommend using it for new code in light of the sexy new alternatives that can compile down to the same binary with source code that’s way more intuitive and readable.

I do have nostalgia for C since it was my first language, and I think a lot of people are in the same boat, which is a problem. That’s why I think we need to stop teaching C. Kate Gregory has a good cppcon talk on the topic: https://youtu.be/YnWhqhNdYyk

I... don't even know how to start answering this.

"C" is glorified assembly and learning assembly is *fundamental* to understand how computers work. "C" *should* be the first language programmers learn when they get serious (ex: first year computer science classes).

When I write "C" I know exactly what is going on with each of my CPU cycles and where my variables are being allocated. The compiler is a dead simple translator who doesn't play funny tricks behind my back.

"C" is the perfect language to learn and have fun with the underlying architecture.

"C" is very easy to learn and not that hard to master. It is fast to compile, fast to run and available everywhere.

I don't like "C++". All code bases maintained by more than one single developer (no matter the language it is written in) become rotten with time but, from my experience, the larger the amount of features a language has, the worst this becomes. All big "C++" projects I have worked on (except for one) were horrendous. This also happens in "C", but in "C" I can just "grep" the keyword and immediately know where it comes from.

I don't like "Rust". I've tried to learn it twice and failed. There are too many places where I lose track what the compiler is doing, the (formal?) specification is big and complex and keeps growing (approaching "C++" absurdity levels). There is never an "obvious" way to do one thing. I get "Rust" is a test bench for language designers, but they are creating an over-engineered monster that is not easy to use (think "low gravity ink injection pen" vs "pencil")

So... "C" is perfect for me (and many others). It's simple, fast and as powerful as it gets, which means it is also fun. As others have mentioned on this thread, together with "cppcheck", "valgrind", "electric-fence" and friends it is also as secure as any other.

"C" is here to stay.

> "C" is glorified assembly and learning assembly is fundamental to understand how computers work. "C" should be the first language programmers learn when they get serious (ex: first year computer science classes).

I agree that a CS education may include an understanding of low level details, but if you want to learn assembly and understand assembly, use assembly.

> When I write "C" I know exactly what is going on with each of my CPU cycles and where my variables are being allocated. The compiler is a dead simple translator who doesn't play funny tricks behind my back.

It really depends on what you tell the compiler. And if you’re using GNU, g++ compiles both C and C++. The compiler will aggressively optimize your code down to practically nothing, and you’ll find that the resulting machine code has high probability of being identical whether you wrote it in C or C++, so it’s a matter of choosing the language that is shorter and easier to read/understand.

I really do respect where you are coming from, but in my opinion one should use the tool that’s most appropriate for the job in light of what’s available. Just because we can keep using lead paint in buildings, or wire wrapping/vacuum tube amplifiers in electronics, doesn’t mean we should. Maybe for fun, maybe as a hobby, but not professionally, and that’s the mindset I approached this with.

> The compiler is a dead simple translator who doesn't play funny tricks behind my back.

When did you last look at the assembly your compiler produces at O2 or higher? Because decades of C compiler development would very much like to disagree with that statement.

> As others have mentioned on this thread, together with "cppcheck", "valgrind", "electric-fence" and friends it is also as secure as any other.

Where do all the memory safety problems in any nontrivial C or C++ codebase come from then? Do you think that for example the Chrome team is just incompetent? It is certainly possible to write safe C, but that involves _a lot_ more effort than using valgrind. You could for example write MISRA-C. Together with extensive manual checking those rules lead to fairly save C, but the effort needed is really big.

Now you just need to also write a testsuite that covers every possible path through your code and you've proved the absence of errors that Valgrind can find. I'm not sure that building such a test suite is less work than using a safer language.

C is very fun to write. You get down to the machine level (nearly). Op did so because he probably wanted to just use it. Maybe to study it, maybe to learn how to write in an unsafe language.

You can program Rust if you want and all you want and feel safe by doing so. Feel free. But this reply really does not contribute anything of value. Especially not for Op. Ofc there are languages with better abstractions reg memory and concurrency. But who cares? its Op's freedom to use whatever he wants to use.

and btw. this attitude is precisely why so many people think Rusters are fucking annoying.

Yeah I've been using rust for more and more small projects at work (we are a c++ house but rust is "ok") and love it. However, it's annoying to hear rustaceans constantly pushing their wares

Thanks is, as the GitHub title says, for iot and embedded devices.

There’s a whole class of these that don’t have the resources to run C++ or rust. Source: develop on a Linux system with 7 megabyte roofs and 16 megs of ram. Oh! We have a 1 meg application partition.

If it can run C, it can run C++ (or rust I guess). The majority of abstractions have little to no overhead. Also 16 megabytes were enough for a very decent desktop computer in the '90, enough to run very complex C++ applications with ease.

I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.

There are ways around all of these:

* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.

* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.

* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.

* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.

but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.

Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security history is horrible, and I'd like their security future to be better...

[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...

[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

Really? You have megabytes of memory but can't run C++? Which architecture is this?

lol none, someone who says that doesn't really know what they're talking about. You can use zero overhead subset of c++ just fine and it will take barely any more room than C. Now if you pull in the std library it's over :)

Space is so cheap these days, it doesn't matter much unless you're on a really low budget. That said I still get a kick out of programming specialty cases with 8 and 16 bit micros. It's nice to have just about everything you need on a chip (a2d, d2a, CAN, I2C, SPI, timers, tons of general I/O). All you kids should do at least one project like that, you'd be surprised at how fun it can be to pick and choose exactly what the hardware is doing down to the clock cycle :)

Perhaps you'd like to point out an actual bug you've found...?

This sort of dogmatic cargo-culting paranoia-rant is exactly why people are getting sick of hearing about the "modern" BS.

I already have to debug C/legacy C++ code (“C with classes”) on a daily basis for my day job, so I sure certainly am not going to waste my free time doing it. The best I can do is be an evangelist for better practices, a fly on the ass of people who still pump C into the garbage stream of the internet.

Since the text in your parent post is more or less the same of your last comment from 10 hours ago, I agree you are in a sort of "keyword oriented" evangelization crusade against good'ol C. The question would be, why caring so much?

Hey, as long as people keeps writing C and C with classes, you'll have a day job.

Yeah, it’s shocking that almost every day I log onto HN and see either (1) security exploits in legacy C code or, (2) new C code being introduced into the world that invites the same exploits to the untrained programmer. The same way people keep repeating the same mistakes, I will keep repeating my criticisms. We’re stuck in an infinite loop.

The modern C++ techniques being referred are 10 years old at this point already and have stayed in consensus. No need to get salty.

Oh man, wait till you see the Linux source code...

Bit of a difference between a kernel and video conferencing.

One of these absolutely needs raw memory management and all the unsafe-if-not-very-carefully-done features that C(++) offer, the other definitely does not.

You literally go from thread to thread posting the same pro-Rust anti-C drivel, derailing every thread.

Sorry to be crude, but can you people take this self-righteous bs elsewhere? Not every thread needs to be about the superiority of Rust or your gripes with C.

This cancer is ruining every thread on HN now.

As far as I can tell, this is an open forum. If people keep repeating the same mistakes when they use C, I’ll keep promoting the alternatives.

I’m not trying to eschew flamebait, it just so happens that people get upset when their ideas are challenged. If it makes people uncomfortable, then that’s fantastic, because no one who was comfortable ever learned anything.

I get it: learning new things and new languages is hard. But like I said before, it will pay dividends, and save time for the people in the future who come hunting down your bugs.

It seems you think their mistake was using C in the first place, and not the way they used C.

Calling people out for not using a language that you prefer is not helping them learn, nor is it bitter medicine to those who find learning your preferred language "hard".

To me, this is not a simple matter of preference like your choice of editor or the way you prefer to have it configured, to be used by you and you alone.

Software, especially open source software, is often collaborative. The programming language is a way of expressing yourself not only to your compiler, but also to other human beings.

Would you write a book today in Middle English, when the rest of the world is expecting modern English?

> It seems you think their mistake was using C in the first place, and not the way they used C.

I mean, guns are restricted in all countries, while of course it's the way guns are used that is truly what people take issue with. If you hang it up on your own wall and never take it off, nobody has an issue with your gun, but enforcement of that is nigh impossible and so we restrict the ownership to policemen and allow only things like hunting rifles for the small group that still likes to go hunting.

As someone working in security, I'd make a similar though obviously less extreme case for unsafe languages like C. If you don't need it, then why use something that you can shoot yourself in the foot with? You put other people at risk through using it incorrectly and it's nigh impossible to enforce secure coding. Many people seem to think that you need C++, C, or assembly to write fast code whereas nowadays there are plenty of alternatives without some of C's biggest issues.

"Eschew" means "to avoid habitually especially on moral or practical grounds".

> As far as I can tell, this is an open forum

Your original point may very well still stand, but I'd like to point out that there's actually a whole bunch of guidelines for posting here:

https://news.ycombinator.com/newsguidelines.html

Let's not call genuine opinions 'cancer' please. If this were some viagra spam bot, then maybe though it would still not be constructive, but let's keep in mind there's a human on the other end of the line.

Dude. The alternative is that the author would not have written the project. Not everyone has hundreds of hours of free time to throw away at learning the next hot programming language.

There's definitely an argument to be made for sticking with stuff you know and love rather than investing in the latest fad. There also comes a point, though, where the solution you know of has clear disadvantages and there are various alternatives with good support and third party libraries available to use.

Also consider that it also impacts other people if you put unsafe code out there or if others want to contribute or build upon it (even if your C is better than even the chromium team, that doesn't mean your contributors' or developer-users are).

In my opinion C has reached a point where using a project like this as a learning opportunity to try out another language, if you don't know one already, would be worth considering.

Or do what you want. However I think c++ with just RAII and smart pointers brings so much more safety than C I don't know why it doesn't get more attention. You don't have to use all the rest, just those couple of things can bring a lot of safety to a project

> Be me

> Rewrite h.264 in rust

> Depends on swap_bits crate by Wladimir Jinping Jr.

> NIH hacked by unknown people

> NYT title next day "Cargo cult package manager behind NIH hack"

Very true. This is why I appreciate C++’s lack of a universal package manager.

Reply on news.ycombinator.com