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

Show HN: Sum (algebraic) types for C in one 100 line header

github.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#41

Post by ironman1478 »

natsucks wrote: post #5

Question: is C gaining in popularity? If so, why exactly? Are their good reasons to be using C in product development rather than more modern languages?

C is the lingua franca for embedded and I think embedded is becoming bigger, both in community and in literal size. There are lots of new devices that are bigger than a small arduino (and even bigger than my pc from a decade ago) and require a lot of software written for them. This requires huge teams working on them, but the only languages available is C or in some cases some limited form of C++. Because there are new people coming to these spaces, they are taking ideas from outside of the firmware world and applying them to the pseudo-firmware world because they want to use them.

Thats my observation at least. I also think C is just so frictionless, that even if it is dangerous people will use it anyway. Yes there are a thousand footguns like people have said, but in the end you can get something compiling and running pretty easily, which is enough I guess.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#42

Post by hgs3 »

natsucks wrote: post #5

Question: is C gaining in popularity? If so, why exactly? Are their good reasons to be using C in product development rather than more modern languages?

> Question: is C gaining in popularity?

Did C ever go away? The computing industry is built on C. It is the foundation underpinning everything.

> Are their good reasons to be using C in product development rather than more modern languages?

Even if you use a "modern" programming language you'll be building on C at some level. Linux, Postgres, Redis, CPython, etc. are all written in C. Most programming languages have a C FFI for a reason. It is worthwhile to familiarize yourself with C if only to have an understanding of what underpins everything. Besides, you never know, you might need to write a native Python module or Postgres plugin one day.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#43

Post by samatman »

rwbt wrote: post #36
wolfspaw wrote: post #18

Earlier quoted context omitted.

C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…

> Nah, just use Arenas/Pools. Or don't use heap at all. This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.

Custom allocators are pretty useful, yes. And slices, although it would be nice to have an easy syntax for using them.

Still have null pointers though. So an optional type would be useful too. Billion dollar mistake and all. Oh, and you have to check errno, might want a better way to handle errors so that you have to check them, or at least acknowledge that they exist. Probably need a linter to make those stick, you really do want violating a nullability constraint to fail at compile time.

And yeah, you have to avoid libc now, but it has so much useful stuff! So we'd want a library that offers all that useful stuff, but uses our fancy custom allocators, and optionals, and error checks, and slices.

While we're dreaming, wouldn't namespaces be nice? Like you have a function do_bar on a struct Foo type, so there's this foo_do_bar function (almost like a method), it'd be nice to be able to just say foo.do_bar, y'know?

Of course, at that point, you've almost got a whole different language! But it can compile and link with C, so yeah, best of both worlds.

What if I told you...

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#44

Post by rwbt »

samatman wrote: post #43
rwbt wrote: post #36

Earlier quoted context omitted.

> Nah, just use Arenas/Pools. Or don't use heap at all. This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.

Custom allocators are pretty useful, yes. And slices, although it would be nice to have an easy syntax for using them. Still have null pointers though. So an optional type would be useful too. Billion dollar mistake and all. Oh, and you have to check errno, might want a better way to handle errors so that you have to check them, or at least acknowledge that they exist. Probably need a linter to make those stick, you…

Err.. Why does one need to even use a different language to implement Arenas and Slices? Yes having syntax level support for them would indeed be nice (something like new languages like Odin and Zig are trying) but you can start using them today and make programming in C an order of magnitude better.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#45

Post by bidune »

OskarS wrote: post #40
TwentyPosts wrote: post #28

Earlier quoted context omitted.

> that's necessary if you don't want it to allocate. Wait, what does one have to do with the other?

I'm not totally 100% on this, but: valueless_by_exception happens when the move assignment operator throws (which should never happen in good C++, but is not disallowed by the language). That means, the variant used to hold value X, we were moving value Y into it, but the move assignment operator failed. What is now the state of the variant? It's not X, since we started running the move constructor, which could have…

Yes exactly. Maybe being able to select the implementation strategy would have been nice, but I personally prefer noexcept constructors to an allocating variant

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#46

Post by Gibbon1 »

chongli wrote: post #13
feb wrote: post #3

Nice system built with only a couple of C99 macros. That small header also achieves matching for specific C types over the "sum types". In the context of C99, isn't tagged union the more usual name instead of sum type?

It's interesting but not very practical. It's an "algebra of types" with only constants, no variables, since C does not have type variables. Thus it misses much of the point of algebraic data types in a language like Haskell (deep composability and generics with very little code to write). Take one of the most basic sum types in Haskell's base library, Maybe: data Maybe a = Nothing | Just a This simple construction g…

I got to say adding type variables to C would be super duper. And to me actually feels rather C like as well.
Post reply on HN