Live data from Hacker News

Learning C3

alloc.dev

111–120 of 163 posts

Re: Learning C3

#111
post #51

Most of these features have been used by countless C++ developers for the past decades -- I really don't see the point in adopting a language that's mostly C++ but without some of the warts. Either pick C++ or something like Rust.

I would prefer a "lightweight" C++. C++ is fine, but it's insanely slow to compile. I generally like C++, but I could trade anything to make it faster to compile, and most of the time, I just use a small subset of C++ that I feel okay with.

C++ is not slow to compile. The Standard Library is.

Re: Learning C3

#112
post #95

Earlier quoted context omitted.

oof. To me switch/case mentally implies constant time matching and routing, I wonder if that is the case (it could be if arrays have compile-time known length).

You have both in C3: switch (x) { case 0: ... case 1 + 1: ... } This will behave in the normal way. But you can also have: switch { case foo() > 0: ... case bar() + baz() == s: ... } In which case it lowers to the corresponding if-else.

I am not a fan of this design in a low level language. The first version of switch does exactly one thing and is very clear. The second now is forcing me to think both about branching logic and control flow. I understand the surface level appeal of the syntax, but if I encountered code written with this feature in the wild, I would think something must have gone wrong in the program design.

Re: Learning C3

#113
I wish C3 has simple RAII/object/class built-in(no inheritance needed, no Polymorphism is fine, just some Encapsulation better than c's struct with function pointers), then it becomes a more powerful c, and a much simpler c++, really a sweet spot in the middle of both and works for 90% of the c/c++ use cases.

Re: Learning C3

#114
post #94

a nitpick: a bit down the page there is stuff on the case syntax. The fact that "you can't have an empty break" is a good choice, but the fact that having two cases do the same thing has syntax case X: case Y: is footgun waiting to happen. I would strongly suggest the authors of C3 make stacking cases look like this: case X, Y:

"case X, Y" works for 3-4 values, but for something longer problems accumulate: case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE: foo(); int y = baz(); Placing them on the next row is fairly hard to read case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE, AND_NUMBER_FOUR, AND_NUMBER_FIVE, AND_THE_LAST_ONE: foo(); int y = baz(); In C I regularly end up with lists that have 10+ fallthroughs…

> In C I regularly end up with lists that have 10+ fallthroughs like this [...]

Frankly, that seems like a code smell, not a problem that needs a solution within the language.

Re: Learning C3

#115

Most of these features have been used by countless C++ developers for the past decades -- I really don't see the point in adopting a language that's mostly C++ but without some of the warts. Either pick C++ or something like Rust.

C3 is "mostly C++" in the same way that my bicycle is "mostly a motorbike".

Re: Learning C3

#116
I only wish that the syntax was changed to make it easier to search/grep for the definition of functions and types. Odin makes this so nice, you can search for “ ::”. Maybe moving the return type to after the closing parenthesis would be enough?

2 more wishes: add named parameters and structured concurrency and I think it would be a very cool language.

Re: Learning C3

#117
post #27

After using Rust on a couple of projects, I understand the appeal of simpler languages like C3, Zig, and Odin. As one commenter very aptly put on the Zig subreddit ... "I used Zig for (internal tool) because I wanted to quickly write my tool and debug it, and not spend all my time debugging my knowledge of Rust."

Is Zig really that common at this point that you'd feel comfortable using it for a work project? Its not just going to piss off the next person and have them need to rewrite it? I guess Rust has the same problem to some extent but there is a lot of resources for writing Rust out there now

I wouldn't use Zig for something production critical, but other people like TigerBeetle have decided its good enough for them, and they seem to be doing fine commercially, so I just refrain from saying its not production ready.

But one things for sure ... there's just not a lot of sample Zig code out there. Granted its simpler than Rust, but your average AI tool doesn't get how to write idiomatic Zig. Whereas most AI tools seem to get Rust code okay. Maybe idiomatic Zig just isn't a thing yet. Or maybe idiomatic Zig is just like idiomatic C ... in the eye of the beholder.

Re: Learning C3

#119
post #92
post #88

Based on this comparison : https://c3-lang.org/faq/compare-languages/ One would argue that the best C/C++ alternative/evolution language to use would be D. D also has its own cross-platform GUI library and an IDE. I wonder for which reasons D doesn't have a large base adoption.

I can only speak for myself: 1. It is so big. 2. It still largely depends on GC (less important actually) It keeps adding features, but adding features isn't what makes a language worth using. In fact, that's one of the least attractive things about C++ as well. So my guess: 1. It betted wrong on GC trying to compete with C++. 2. After failing to get traction, kept adding features to it – which felt a bit like there…

The dmd compiler not being open source until 2017[1] made it more or less a non-starter for a great many use cases. That would have been okay in the 80s, but with tons of languages to choose from since the 90s/00s, your language needs something very special to sell licenses.

[1]: Specifically: "The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license, please contact Digital Mars."

Re: Learning C3

#120
post #112
post #95

Earlier quoted context omitted.

You have both in C3: switch (x) { case 0: ... case 1 + 1: ... } This will behave in the normal way. But you can also have: switch { case foo() > 0: ... case bar() + baz() == s: ... } In which case it lowers to the corresponding if-else.

I am not a fan of this design in a low level language. The first version of switch does exactly one thing and is very clear. The second now is forcing me to think both about branching logic and control flow. I understand the surface level appeal of the syntax, but if I encountered code written with this feature in the wild, I would think something must have gone wrong in the program design.

i think hlls sometimes distinguish between these situations with a different keyword.
Post reply on HN