Live data from Hacker News

C-for-all: Extending C with modern safety and productivity features

cforall.uwaterloo.ca

131–140 of 143 posts

Re: C-for-all: Extending C with modern safety and productivity features

#131
post #7

I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And…

It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax. I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust. Personally if I were going to make C better, I'd add a better m…

>It's pretty much the wysiwyg of high level -> asm.

Everyone with this opinion needs to read this[0].

[0] https://queue.acm.org/detail.cfm?id=3212479

Re: C-for-all: Extending C with modern safety and productivity features

#132
post #129

Some interesting ideas here. However, C is being improved in an evolutionary fashion; the latest revision was C18 in 2018. I like languages like this (my favorite is D), but the only C successor language I use is C11 (this is what clang targets; C18 is an incremental minor update to C11 that only fixes errata). x = t.1; // extract 2nd tuple element (zero origin) Zero-based indexing in a programming language is not ne…

Modern computers encode the first address of memory as a binary word of all zeros. In an array, a pointer to the array + 0 is the first element. A pointer to the array + 1 is the second element. C is low-level, so it makes sense to follow the machine idiom.

Re: C-for-all: Extending C with modern safety and productivity features

#133
post #71

Earlier quoted context omitted.

That doesn't fix the issues mentioned. (Whether it's an "alternative" stdlib for C is debatable; nobody ever said that glibc is "the" stdlib for C…)

It is the de facto standard on Linux.

Which Linux? There are plenty that use MUSL instead.

Re: C-for-all: Extending C with modern safety and productivity features

#134

Earlier quoted context omitted.

Oh, nice, I will definitely try that. Nifs in C are an eyesore and a risk, having more language options there is good and a clean integration like this is even better.

Just FYI I recommend waiting till I 0.1 it, which will definitely happen before end of January, when I'm giving a talk. I haven't tested that it works as a library yet, much less with elixir releases (it works self contained).

Ok. Even so, very nice development, this is exactly how I think it should be done, most other dual-language environments where you use one language for structure and another for speed tend to completely lose the context of the code for the optimized part. Having them blended in like this ensures that they are viewed as a whole rather than as two loosely coupled parts.

Re: C-for-all: Extending C with modern safety and productivity features

#135

Earlier quoted context omitted.

All memory allocations in Rust follow a `malloc`-like API that ends up calling `malloc` and similar at some point.

With memory management, the question is often when and how to release resources, not how to get untyped memory from the operating system.

Sure, but in Rust, the programmer writes code that calls malloc manually, which is completely different from Java.

Re: C-for-all: Extending C with modern safety and productivity features

#136
For some time I have been puzzled that clang and gcc don't provide an option/ABI (maybe -safe or -mcpu=x86-64-safe) for memory safety.

Last I checked, memory safety for C (e.g. fat pointers with bounds checking) seems to impose a ~60% performance overhead on traditional processors (with hardware support it could be much less.) In many (most?) cases, that overhead is worth the improvements in reliability and security.

For certain applications (probably anything network facing) I'd probably want to compile the whole OS, libraries, and software base with -safe.

Re: C-for-all: Extending C with modern safety and productivity features

#137
post #122

C with modern safety and productivity features is called "C++" and has been around for decades. I'm amazed at how much effort people will expend just to avoid the C++ boogeyman. No, writing C++ does not automatically make your code bloated. No, using C does not guarantee lean design. Plain C ought to be considered a legacy language and not used for new code. There is zero reason to prefer it over whatever style of C+…

> writing C++ does not automatically make your code bloated Sorry, but it does.

No, it does not.

Re: C-for-all: Extending C with modern safety and productivity features

#138
post #63
post #55

Can we talk about the proposed new features: How are tuples different from structs? You can pass around and return whole structs (not pointers) just fine in plain C. Underscores in int literals should probably be proposed to the ISO committee for C itself. A similar concept works successfully in OCaml. (Binary literals would also be useful). I've never felt that C lacked sufficient control structures, and the new one…

I wonder how they propose to solve exceptions, destructors, constructors and overloading while being more compatible with C than D. Apparently a beta was promised for "early 2019" according this: https://github.com/cforall/cforall but nothing is forthcoming. Already announced in 2007: http://lambda-the-ultimate.org/node/2181

Oh, looks like they have a partly completed compiler with a c transpiler backend: https://cforall.uwaterloo.ca/trac/browser

Re: C-for-all: Extending C with modern safety and productivity features

#139
post #26
post #21

Earlier quoted context omitted.

You mean like the Americans did with Cisco? I am not really in a mood to defend the chinese regime, but the “free” West really threw away any moral high ground we might have had.

Just because the west also can't necessarily be trusted not to try to sneak exploits into sponsored projects (or through other means, such as a snail mail MITM) doesn't mean we shouldn't ask the question of other countries as well. Whataboutism is never the correct answer to a valid concern (in general. I'm not sure if there's much to worry about in this specific case or not).

I understand your criticism of whataboutism. I dislike whataboutism myself.

However the issue here is that I wish that the nations I am part of would conduct themselves in a manner that gives them the moral authority to speak up on issues of freedom and democracy. And this — quite frankly — currently isn’t the case. It isn’t the case because the post 9-11 paranoia lead elements of our society to feel so threatened, they threw defining rights and freedoms overboard (and this is the favourable reading of events).

You cannot topple governments, install dictators, kidnap and torture people and keep them locked up without trial for years, cover up war crimes, go after those who blow the whistle on said war crimes, spy on your allies and on your own people and still expect other nations to see you as a beacon of freedom and democracy. A lot of the behaviour of the US is only justified by: “Yeah but we are the good ones” and this is an argument my one Nazi Grandfather also used: “Sure there were bad things, but they built the streets and everybody had a job.”

A free society isn’t measured by how it treats its wealthiest and most powerful members — it is measured by how it treats its enemies.

Hard to demand someone to respect human rights, if you don’t give a damn about it yourself, when it just hits the people you dislike.

That beeing said, China is still worse. But this is not a contest and I like to change the nations I live in first.

Re: C-for-all: Extending C with modern safety and productivity features

#140
post #122

Earlier quoted context omitted.

> writing C++ does not automatically make your code bloated Sorry, but it does.

No, it does not.

  $ cat hello.c
  #include 

  int main(void)
  {
   printf("hello world\n");
   return 0;
  }

  $ cat hello.cpp
  #include 

  using namespace std;

  int main(void)
  {
   cout 
I see 1544 bytes of bloat. Hope that helps.
Post reply on HN