Hacker News Reader

Comment by SwellJoe | Hacker News Reader

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing?

I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the foot with C are seemingly beyond counting. Are threads and async easier and/or safer now than 10-20 years ago, and with more direct language or standard library support? Is memory management in the standard library safer today? Are there concurrency primitives (beyond low-level interacting with epoll or kqueues or even fork or whatever)?

I mean, it's obviously possible to write reliable, safe, secure, software in C (Linux, Git, SQLite, all come to mind), but how much easier has it gotten? Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

View on HN

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter.

Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years.

Some current reasons to continue to prefer C over Rust:

(1) Rust is new and shiny and evolving. For a long-term project like SQLite, we want old and boring and static.

(2) As far as I know, there is still just a single reference implementation of rustc. I'd like to see two or more independent implementations.

(3) Rust's ever-tightening interdependence with Cargo and Git is disappointing.

(4) While improving, Rust still needs better tooling for things like coverage analysis.

(5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".

Pragmatism over "Oooh Shiny", one of the reasons I have huge respect for the sqlite project ;).

Rust looks pretty decent but I'm still in the wait and see stage as well.

I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google.

I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version that the syntax that worked is now obsolete in favor of a new operator.

What are you missing from the up-to-date API reference[1]?

[1] - https://doc.rust-lang.org/std/

I was trying to read a file one line at a time (reading only the first few lines of a very large file), and it turned out to be somewhat difficult as the built-in functions seemed to be really keen on operating on the entire file at once.

The docs should never be "out of date" as in not working, though some parts don't have more than type signatures yet. Working on it. Please file bugs if something is not working, or swing by #rust-beginners, we love to help!

Really? I read the documentation for file I/O directly out of the Rust online docs and put together a complete serialization module for a project I'm working on. It was actually quite straightforward.

You still have to be a bit careful about finding old posts and old docs on the internet about Rust, given that many APIs have only been stable for a short while.

In general, unless you know your source is up to date, I'd recommend ignoring the internet at large completely when it comes to Rust APIs and just focusing on the official docs for the release that you're using. They're plenty good enough, though you do have to get used to navigating them.

>The omission of assert() makes Go a non-starter.

A small syntactic sugar you can trivially implement yourself makes Go a non-starter?

Go doesn't include assert in the language because you're supposed to do better than assert. Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. Go prevents you from compiling with unused variables, and that combined with the Go documentation goes a long way towards teaching new Go programmers how they're expected to work.

And neither Go nor Rust could possibly be good fits for SQLite. A Go hello world is bigger than all of SQLite while an idiomatic Rust one is on par, and neither's nearly as portable as the current C implementation, one that is both programatically and battle-tested like pretty much nothing else in the world.

> Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions.

This is what he meant by misuse. Properly-used assertions are meant to document and check conditions that were thought to be impossible by the developer. Not just unlikely, or illegal, but impossible. If a condition is possible, and you check it with assert, that's a bug.

Those are panic territory, which carries a different connotation than the word assert (which has very likely influenced in its very widespread misuse).

The biggest problem I've seen with assert[1] is putting functioning code inside one and then not knowing why your code no longer works with NDEBUG.

[1] http://en.cppreference.com/w/c/error/assert

I came to detest assert when I was working on a project with another guy, who used it generously, as a substitute for assertions in (non existing) unit tests. Nothing would annoy me more than working on my code, running it, and having all sorts of weird assertions pop up all over the place from this guy's code.

>Go prevents you from compiling with unused variables, and that combined with the Go documentation goes a long way towards teaching new Go programmers how they're expected to work.

Things like this make me not want to use a language. Want to comment a=b; to a=3;//b temporarily? Too bad, either assign b to 3 or comment out b too, and if b was the only variable to make use of c, same for c, and so on. Same obnoxious nonsense as Java not letting unreachable code exist, making me have to comment out the rest of the function body if I want to put in a return in the start to test something, which happens often enough that it's a pain.

You can always use the black hole variable _

That mild inconvenience (which I almost never face while writing Go code after getting accustomed to the language and getting my editor to run goimports on save) has a big RoI in safety and program quality, which are much loftier goals than short term code-writing convenience.

I doubt the RoI is much more than if these were just suppressible warnings instead of errors, which work out great in C#.

>which work out great in C#.

They're greatly ignored in the real world.

> Rust has "immutable variables". Seriously? How can an object be both variable and immutable?

"Immutable variables" is frequently used, true, but the official term is "immutable bindings".

Reassuring news. Thanks.

To elaborate slightly, there's three components here:

    let x = 5;
    let mut y = 6;

The let statement binds a variable to a value:

  * x and y are the variables
  * 5 and 6 are values
  * let does the binding

You can have an immutable binding, like x, or a mutable binding, like y. But most people turn "a bound variable" into "a variable" (or "an immutable variable") and "a mutably bound variable" into a "mutable variable".

> (3) Rust's ever-tightening interdependence with Cargo and Git is disappointing.

I can see the latter, but why the former? Package management that has understanding of language dependencies is a huge productivity booster.

> (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".

A variable/binding is mutable, the object is not. I don't see the problem.

> (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable?

Variables have been called variables since the dawn of time, i.e., the lambda calculus, which doesn't even have assignment. The name derives from the idea that for every invocation of a function, a variable in its definition may be bound to a different value, hence it "varies" at runtime.

Furthermore, it's terminology from mathematics, where, just like the lambda calculus, mutation isn't a thing: https://en.wikipedia.org/wiki/Variable_(mathematics)

That's an interesting take. I don't think I've heard that complaint about go from anyone (other than you, I think, in a previous HN conversation). I've worked on code that had assert (Squid before the C++ rewrite, and it used assert correctly to the best of my knowledge), but I never considered it vital to the end result.

Have you read about panic (https://blog.golang.org/defer-panic-and-recover)? I'm not meaning to assign you homework, as I know you know more about this than I do, I'm just curious what about assert makes it mandatory for you...panic in go does require you to write your own error check (presumably just an if, for assert-like behavior, but you could do more complex error-handling).

All of your other comments are certainly valid reasons to choose C. Though I like cargo, and I suspect C would be well-served by something similar.

> It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing?

Well, I've done C off-and-on, sometimes heavily, since the days of VT-100s and DEC-Writers. Modern C has always been a thing since the 1970's. Its just that the definition of "modern" keeps changing :)

Yes, things are easier. It is possible to use the compiler features to write code that can be compile-time checked better than in the old days. A good IDE can use that to advantage to flag a lot of errors before you even compile. Yes, memory management can be easier. That said, most of the C I do now is for embedded microcontrollers with no OS underneath -- so memory safety and threads are DIY, and fork() is not a thing.

As someone once said to me about 30 years ago, "C doesn't get in your way." Also, with C, I can, if I wish, get extremely fine-grained control over memory layout. So currently I tend to use C on bare metal, and Python 3.5 whenever I can get away with it, with wee, tiny, C extensions to Python where necessary. C still has a place, but since the advent of Python my motto is: "Life is too short for C++".

> "Life is too short for C++"

I've said for many years "Life is too long to write C++ for a living." And I haven't written C++ for many years.

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means.

I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons.

Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditional setup.

I know everyone is gung-ho about rust, but for the traditional systems programming crowd, its very new. Given how much it changes I would NOT want to bet on using it for at least 5 years. You don't switch just because something is better on memory safety. That is a nice to have thing. But changing 40ish years of things isn't something that you do without planning.

Also, in my opinion Rust doesn't go far enough. I'd rather we move to things like Idris where I can prove much more than just memory safety. Rust is basically Ada/Oberon/Modula for the modern age. Nice, but ultimately not the first time this has happened.

Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?

Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS.

Idris is closer to ocaml in that regard.

I cough may have already tried using idris in a kernel module. (for fun, not for serious)

And how did it go?

It worked surprisingly enough, well enough to make me consider trying out some gpio stuff to play around with.

From there I'll let you know, I'm still learning Idris and dependent types so I'm a fairly boring test case. This was more of a: lets try it and see what goes kaboom test.

I'm not thinking of Haskell. Idris compiles to C but there is an open question there, with regards to how memory will be handled now and in the future. Swift does not need a runtime either, since it uses automatic reference counting for everything; but it has not gone as far as Rust, which defaults to stack allocation everywhere.

This is not to say I doubt the ultimate approach of Idris: with dependent types you can do everything Rust is doing, and more. It's just a matter of project focus and ergonomics.

Which is why I am more willing to bet on Swift and .NET Native getting more widely used than Rust.

Not to misrepresent the work the Rust guys are doing, it is great what they are doing and I have lots of fun dabbling on it.

But new system programming programming languages tend to be adopted when an OS vendor tells devs, either use it or go code elsewhere.

On OSes that have significant market share, devs tend to learn the new language instead of waving it away.

> Given how much it changes I would NOT want to bet on using it for at least 5 years.

Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.

Sorry should have been more clear, my meaning was more around things like cargo and tooling rather than the language proper.

Don't take any of my criticism too harshly either, I do like and use Rust for side projects. But it is about 3 years away from where I'd consider using it for anything. I'm a bit more conservative than most here seem to be. Funny part is I'm the maverick in using new stuff compared to the people I work with.

Keep on trying to improve things either way!

Sure, "systems programming" has a variety of meanings. But, there are a lot of areas where C was the obvious choice in the past but Go might be a suitable replacement today. Areas where concurrency and safety is maybe more important than raw performance: Databases (and there are many now written in Go, including alternative types of databases like time series, key/value, etc.), servers, etc. I tend to consider those systems level, even if they are not kernel level or running on bare metal.

Obviously, if one defines "systems programming" more strictly than that, and only mean code that directly interacts with hardware or has hard realtime requirements (which also probably means it must interact directly with hardware), then Go does not make sense in that category. But, C has given up a lot of territory over the past several decades. When I first started programming, C was the language you used for writing almost any real application...if you weren't using assembly. That has changed a lot in the intervening years, and almost no one would think to use C for GUI apps today, for example.

Databases have been written in Java, too; but the combination of performance unpredictability (not something Go has addressed, since it is also garbage-collected) and a bad C compatibility story has proven to limit the reach of these projects.

True. Even very successful database projects in Java have some issues with GC pauses.

Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?

> Basically, how would you build Java today if you could do it again?

Take Modula-3 (1986), change the keywords to lowercase and re-brand it as "Cool Language X".

Still better Go than C.

> Databases have been written in Java, too;

Your comment seems to imply that java hasn't been successful for db development. HBase, Cassandra and ElasticSearch would all disagree.

Yes, there are situations where GC is not appropriate. But I think those situations aren't as common as they are made out to be.

Well, I'm thinking of RDBMSes, of which there are some written in Java -- but I think you would agree, they have never gained much traction relative to Postgres and MySQL (or Oracle in enterprise).

HBase and ElasticSearch, and even Cassandra can be seen as somewhat niche today. This doesn't mean they aren't doing something of value; and it doesn't mean using the same platform for OLTP and OLAP is the way of the future; but it does mean the competition in their space is more limited and less indicative. There are ground-up rewrites of Cassandra in non-GC'd languages out there, for what it's worth.

Given that Go is quite similar to Oberon, I don't fully agree.

http://www.projectoberon.com/

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

http://www.astrobe.com/default.htm

http://wiki.osdev.org/Go_Bare_Bones

It just needs someone to port that Oberon code to Go, maybe people will then stop discussing how suitable Go is for systems programming.

As pjmlp said, Go was a partial clone of Oberon-2 per Pike. Modified to suite modern requirements and whatever other designers put in. Oberon's were used in numerous operating systems. Latest was A2 Bluebottle which seemed faster than my Linux desktop despite being a GC language and running in full virtualization on Linux. The original language in that family, Modula-2, was even hosted on a PDP-11 like C.

Therefore Go is closer to that space than people want to admit. A change of its runtime or compiler would let it do operating systems. Even Java (JX) and Haskell (House) do operating systems. I'm sure one could that is derived from and similar to a language designed for implementing OS's. :)

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

While Rust might be feasible, Go can't really provide libraries like SQLite: Go's C compatibility story is disappointing and awkward.

Having written a project that loads Go plugins to a C app (namely redis), it's not great but in recent Go versions it's not too bad as well.

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

I imagine it is easier to hire C programmers than Rust programmers, at the moment, especially in fields like embedded development.

Also Rust doesn't support compiling to certain architectures like the Xtensa ISA used in the popular ESP8266 and ESP32 wi-fi chips.

Also, Rusts standard library is simply too big for many embedded systems.

Last time I checked the compiler didn't support bare-metal and resource constrained builds without using crazy hacks. Although the situation may have improved since then.

I think it now amounts to adding a line to the file that tells it to not use the standard library. I've seen smaller projects that did it, and it was nothing like crazy hacks.

Fair enough, but it didn't used to be like that:

https://scialex.github.io/reenix.pdf

Which part of this paper is the part you're worried about?

The second half of the paper is mostly about challenges in using Rust. Some were related to the way the language handles data (i.e. challenges of sharing data among threads without using unsafe code), but there was also some that are related to the compiler and the standard libraries.

The authors mentions allocation in particular (to be honest I did not really understand his problem). He also writes about the standard library being too large while the tools don't support bare metal projects out of the box and that the compiler emits a lot of code that depends on the standard libraries.

Of course, the paper is more than a year old so all these issues can have been fixed by now. Maybe you can comment on that?

Yeah, that's why I asked! It's been a while since I read the paper, and skimming it, it wasn't clear which part you were asking about. Seems like mostly 3.2 and 3.3?

3.2.1 is about inheritance. That still may or may not be coming, exactly. It's just not a huge deal to more experienced Rust programmers, though we can and will be doing a better job of explaining alternative design strategies.

3.2.2 is about anonymous enums. The author is right that this is a little boilerplate-y today.

3.2.3 is about static data. The answer is the lazy_static crate, which is compatible with no_std; I use it in my own OS a lot. It works almost exactly how the author wants it to, though it doesn't literally use Option<T>.

3.3.1 is about allocation, which is where you said you didn't really understand. So let's back up a minute: Rust's standard library is built in layers: the foundation is libcore, and then libstd is layered on top. Libcore is suitable for OS development, and includes nothing about allocation at all. Libstd includes heap allocation. This is referencing Box, which is in libstd. If there isn't sufficient memory, the the implementation of heap allocation in libstd will abort. That's still true today. However, this is one of the reasons that libstd isn't meant for this kind of development; it's meant for general application development. So, while the author's point is still sort of true today, I'd argue that it's going about it wrong, and it's also not a limitation of Rust generally.

3.3.2 goes on about this some more.

There's some stuff about Cargo in 2.8.3. Many OS dev projects augment Cargo with a Makefile, but depending on context, you can use only Cargo today. My (still toy) kernel does, for example. This section is extremely unclear as to what problems they faced, so it's hard to tell what's changed between then and now.

Other than that, I'm not totally clear on the "standard library being too large" and "emits a lot of code that depends on the standard libraries" bits you're talking about. I don't have time to fully re-read the entire paper right now, if you could give me specifics, happy to elaborate further.

A lot has changed since April 2015, including the release of Rust 1.0 :)

Thanks for the answers!

> Other than that, I'm not totally clear on the "standard library being too large"

IIRC their Rust kernel hit some size barrier (for the bootloader?). The author tried to build a smaller standard lib to overcome this, which was a bit of work.

No problem!

I didn't see that from skimming; if it was bootloaders, well, they have a max size of 512 bytes (on x86) so virtually all bootloaders load in stages, with a tiny bootloader that loads the "real" bootloader.

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

From a professional standpoint, you might as well be asking if I have infinite money and time. Nothing happens in a vacuum

But ignoring that, I would say, for me, it boils down to:

1. How important is performance? Is this a case where all that really matter is that it works? That I have a decent algorithm? Or am I going to be doing "real" optimization, even if only for a single platform? Even at just the "is my algorithm good?" stage I would lean toward C/C++ for systems work.

2. And this is the important one: Do I need this code to exist and be usable in one year? Five? Ten? Stuff like Rust might be fine for the one year frame, but for even as few as five I am going to want something established that I know will have support. And that means C/C++ for systems development (python, ruby, and js for scripting, and so forth).

Reply on news.ycombinator.com