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

Learning C3

alloc.dev

Post reply on HN
Print view View original

101–110 of 163 posts

Re: Learning C3

#101

Post by GoblinSlayer »

lerno wrote: post #92
Daril wrote: 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…

Indeed, first get traction, then add as many features as you want and become perl. That's the real carcinization.

Re: Learning C3

#102

Post by lerno »

aidenn0 wrote: post #75
lerno wrote: post #69

Earlier quoted context omitted.

I don't quite see what you mean. As an example, let's say you use ZII and allocate 100 objects in a single allocation. These are now zero initialized and so either invalid (which should not happen) or do not hold non-null types. Can you explain how you intend this scenario to be resolved in your case? Otherwise it's quite straightforward that they have an uninitialized state (zero) and are then wired up when used. Tr…

> As an example, let's say you use ZII and allocate 100 objects in a single allocation If you want to do that you can always use a nullable type. You can always assign it to a non-nullable type after initialization if you plan on using the aggregate a lot. Usually you provide a vector type though, which has an underlying nullable array, but maintains a fill-index such that for all i < fill-index it the value is initi…

This could make sense for a from-scratch language, but C3 is trying to be an evolution of C, and such constraints would make it so much of a different language that it would be way out of scope.

I think Rust and similar languages fill that niche already, so there is no real need to try to offer that type of alternative.

Re: Learning C3

#103

Post by pjmlp »

lerno wrote: post #92
Daril wrote: 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…

I think the biggest issue has been trying to always chase the next big thing that eventually could bring mindshare to D, while not finishing the previous attempts, so there are quite a few half baked features by now.

Even Andrei Alexandrescu eventually refocused on C++, and is contributing to some of the C++26 reflection papers.

Re: Learning C3

#104

Post by stevefolta »

lerno wrote: post #73
plainOldText wrote: post #37

Earlier quoted context omitted.

Indeed. There’s a port for macOS though. And yet out all these newer C-like languages, it looks like Hare probably takes the crown for simplicity. Among other things, Hare uses QBE[1] as a backend compiler, which is about 10% the complexity of LLVM. [1] https://c9x.me/compile/

The downside of QBE is that it then requires an assembler and a linker. And QBE's only input and output is still text. Plus the "frontend -> QBE -> assembler -> binary" process is slower than "frontend -> LLVM -> binary". And LLVM is known for being a fairly slow compiler.

The downside of QBE is that it doesn't have a way to generate debug symbols. But I still love and use it.

Re: Learning C3

#105

Post by fuzztester »

pjmlp wrote: post #103
lerno wrote: post #92

Earlier quoted context omitted.

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…

I think the biggest issue has been trying to always chase the next big thing that eventually could bring mindshare to D, while not finishing the previous attempts, so there are quite a few half baked features by now. Even Andrei Alexandrescu eventually refocused on C++, and is contributing to some of the C++26 reflection papers.

>while not finishing the previous attempts

I agree, and that applies to many software projects, and not just programming languages only.

>so there are quite a few half baked features by now

what are some of those half baked features?

Re: Learning C3

#106

Post by pjmlp »

jokoon wrote: post #51
SuperV1234 wrote: post #41

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.

Pre-compiled headers, binary libraries, avoid header only libraries, if lucky to be on latest clang/VC++, modules.

Re: Learning C3

#107

Post by Rochus »

dgellow wrote: post #100
Rochus wrote: post #47

Earlier quoted context omitted.

This is a completely valid and reasonable argument; I don't understand why people are downvoting it.

Because it seems fairly obvious you can use a standard `for` if you need more control over the iteration.

The argument is still reasonable. The OP didn't claim that there is no "for" loop, but that the "foreach" is a high-level construct which is not intuitively comprehensible and thus doesn't fit to the C3 language design.

Re: Learning C3

#108

Post by pjmlp »

fuzztester wrote: post #105
pjmlp wrote: post #103

Earlier quoted context omitted.

I think the biggest issue has been trying to always chase the next big thing that eventually could bring mindshare to D, while not finishing the previous attempts, so there are quite a few half baked features by now. Even Andrei Alexandrescu eventually refocused on C++, and is contributing to some of the C++26 reflection papers.

>while not finishing the previous attempts I agree, and that applies to many software projects, and not just programming languages only. >so there are quite a few half baked features by now what are some of those half baked features?

The new allocators, some corner cases of the destroy and destructors, not everything on Phobos is @nogc friendly, BetterC still chockes on many common C extensions, DIP 1000, the whole set of @live semantics.

Now there is a new GC being redesigned, and there are discussions about a possible Phobos V3.

Re: Learning C3

#109

Post by [deleted] »

lerno wrote: post #95
throwawaymaths wrote: post #48

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.

[deleted]

Re: Learning C3

#110

Post by aidenn0 »

lerno wrote: post #102
aidenn0 wrote: post #75

Earlier quoted context omitted.

> As an example, let's say you use ZII and allocate 100 objects in a single allocation If you want to do that you can always use a nullable type. You can always assign it to a non-nullable type after initialization if you plan on using the aggregate a lot. Usually you provide a vector type though, which has an underlying nullable array, but maintains a fill-index such that for all i < fill-index it the value is initi…

This could make sense for a from-scratch language, but C3 is trying to be an evolution of C, and such constraints would make it so much of a different language that it would be way out of scope. I think Rust and similar languages fill that niche already, so there is no real need to try to offer that type of alternative.

I think we are miscommunicating. Let's imagine a language called "C@" where the only difference is that "@" is used in place of "*" for a non-nullable pointer type:

  typedef struct {
     foo @*data; //Non-nullable pointer to nullable pointer of foo
     size_t size;
     size_t fill;
  } foo_vec;
  
  void foo_vec_push(foo_vec @v, foo @x) {
    if (v->fill == v->size) {
      //realloc and zero data
    } else {
      data[idx++] = v;
    }
  }
  
  foo @ foo_vec_get(foo_vec @v, size_t idx) {
    if (idx
I'm not sure how this constraint makes it "so much of a different language" at all.
Post reply on HN