Hacker News Reader

Comment by trealira | Hacker News Reader

> A type-safe C successor that compiles directly to x86_64 assembly.

...

> Warning

> There is no safety measure regarding string literal manipulation. Doing this will most probably result in a segmentation fault.

  # String literal (int8*)
  "abc"

  # Character literal (int8)
  'c'

  # Undefined behaviour
  "abc" at 0 = 'd'

This doesn't seem very type safe, at least not yet.

This is a cool project, though! I have been wanting to learn to write compilers. They're the coolest things.

Also, this is a side note, but what I actually hope is the successor to C is higher level languages having the option to restrict oneself to a low-level variant that can manipulate pointers, and/or let you embed assembly under macros and special functions, like this old blog shows how to do for Lisp[1]. It would be cool if more languages let you do stuff like that.

[1]: https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-co...

View on HN

That's what "under development" means, but you're correct

>I actually hope is the successor to C is higher level languages

Rust

>having the option to restrict oneself to a low-level variant that can manipulate pointers

unsafe Rust

C# can also manipulate memory:

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

I'm pretty sure I had seen a C# project years back that jailbroke the iPhone as well, but I don't even remember how it worked, it was probably a decade back.

A killer feature of C is its simplicity. It is so simple that there are dozens, probably hundreds of independent C compilers and C standard libraries.

Rust has no formal specification and no independent implementations even close to complete. gccrs is still struggling to compile the standard library after years of development by some of the smartest compiler writers in the world.

Rust is a successor to C++, not C. Rust may be a lot of things but I don't believe it will ever be a successor to C.

If you want simple, there's always Pascal.

… and Modula 2!!

> Rust is a successor to C++, not C. Rust may be a lot of things but I don't believe it will ever be a successor to C.

Well, the Linux kernel which is C and ASM, rejected C++ (for reasons although not technically because of the language itself so much) and it is adopting Rust. Rust is a language & a runtime. You can write C-like code in Rust and C++-like code in Rust or mix'n'match however you like (you can even get close to ML style languages).

> Rust has no formal specification and no independent implementations even close to complete

Rust has plenty of formal specifications. Their whole process is to formally specify how a thing works & then implement it against that spec.

It's not standardized by an external body / doesn't have a snapshot of the standards that are relevant to implement for a given edition. I view standardizing a language as an anti-pattern for similar reasons that attempts to do that with human languages fails - it ossifies things whereas languages really need to continue to grow and evolve (+ standards bodies become their own weird little fiefdoms that often have nothing to do with achieving the goals they're nominally supposed to be focusing on).

Same goes for independent implementations. It's fine for C because C as a language is a very simple thing and hasn't really changed in 30+ years and doesn't really have a runtime (most of the things people call C is actually POSIX).

It has not worked out well for C++ which has stagnated quite badly, having to implement the same feature 3+ times and having representatives from each arguing against features that are more difficult to inject into their architecture and for features that are easier is part of the reason. There are positives in that errata can be found more likely when you implement the same thing 3 times, but it's not clear to me that it's net better than just implementing a thing in the nightly release chain & letting it bake until it's ready.

Having a single frontend simplifies a lot of things. gccrs struggling is a positive thing as far as I'm concerned - it means that the Rust language continues to evolve and isn't concerning itself with needing to support a fork of the frontend.

Rust isn’t even really a successor to C++

Rust is too complex and clunky to ever gain widespread acceptance outside its niches.

It's been a decade already, us recovering and current zealots we all need to wake up and smell the roses.

For system programming, treating memory as a critical resource with strictly traced ownership is a good design. For the other 97% of programing, memory needs to be there when you need it, to be plentiful and to get out of your way and not be a source of runtime bugs or compiler friction. Slight inefficiency is acceptable.

A decade is nothing in the lifespan of a programming language

> Slight inefficiency is acceptable.

Sure - and in rust that probably means boxed types everywhere. Maybe the worst feature of Java was the easy access to bare types. For rust it might be a culture thing - but that might change.

What you're describing is not the successor of C, though. It's one of the many managed-memory languages.

> Rust is too complex and clunky to ever gain widespread acceptance outside its niches.

Rust is a systems programming language (it didn't start out that way but is where it pivoted to) so I think we agree on that niche. Most people don't work on problems that Rust would help with, but the places it's suited for is seeing more Rust adoption, not less and those niches are quite large. For example, Linux kernel, Android, Windows kernel, Chrome, etc etc. Basically any C/C++ codebase, if it really needs to be C/C++, will get migrated and there's a metric fuckton of such code. There's probably more JS, Java, Python, Ruby, etc but those programs don't need to be migrated to Rust unless they need more performance/multithreading and can benefit from Rust in that way. Rust not making sense for JS, Java, Python, Ruby, etc coders does not make it a failure or a valid claim that it doesn't have "widespread acceptance" - after all those other languages also don't see widespread acceptance outside their niches.

Well, as usual, use whatever language fits your needs best. But Rust's main benefit is not performance, it is safety. There are very few languages in the industry that I feel have my back when it comes to reliability and one of them is Rust.

It's both. It's fast enough to provide an alternative to C and C++ purely due to its performance, even ignoring that it's more enjoyable to write Rust than C and C++, and ignoring that Rust code is reliable. That's why Discord switched from Go to Rust for performance reasons, and why there are Python developers that replaced C with Rust for high-performance Python extension modules.

Rust is much more akin to C++ than C in terms of complexity. It's early but Zig[1] might fit the bill.

[1] https://ziglang.org/

Not sure how. Zig is targeted as a systems level language but isn't memory safe. It's complex enough in its own way. I don't see it faring well against Rust - it'll have it's proponents and enthusiasts but I doubt it'll ever see the same adoption as Rust (i.e. it'll be closer to what D accomplished trying to supplant C++).

I assume also Zig, Nim and D fall into this category as well. I'm not sure about Crystal, and others so apologies if I missed some.

I've written some Rust. This isn't by far the first language that aims to replace C. I haven't touched Rust for a while, and now decided that I want to get into Spark (that's Ada's thing). And going through the process of learning a new language that's somewhere close to C, for... I don't know exactly which time now, I realized that:

The unsafe aspects of C is what you pay for comfort. Sometimes, when you write a program you simply don't know what type it's going to be, and the details of that type aren't important right now. You just need the convenience of casting everything to everything or passing "void *" around just to get things done.

Similar to Rust's lifetimes Ada has what it calls "access checks". Roughly, it's a static check that your pointers are always valid. Similar to Rust's lifetimes it's a huge pain to deal with. Sometimes you'd sit in front of your monitor and be like "this code is correct! why don't you just do what I'm asking you to do and let it fail at runtime so I can tell where the problem is?" And then you start to weasel around. You don't spend time actually working on the problem you need to solve, you just typedef this, expand the definition of that, try making something a constant, a variable, try not passing some piece of data -- all kinds of manipulations just to make the checker happy.

All while in C you can just tell it to shut up and move onto the next goal. It's more natural to deal with problems when your code actually fails.

So, in the aftermath: do I like C programs? -- Absolutely no. They are unsafe and will potentially do all sorts of bad things. But do I like writing in a safer language? -- No... not really.

I wish there was a way for humans to write in C and then some magical compiler would read that code, understand what the human actually wanted and produced an Ada or Rust program from it. While there isn't such a thing, maybe the next best thing is to write first in C, and then rewrite it in a safer language?

Memory safety and type safety are different things. They usually go together, but not necessarily so.

This seems like it ought to make sense, but do you have a concrete example?

Null pointer dereference, out of bound array accesses.

I was looking for concrete issues which violate either memory safety or type safety but not both. However, these examples are clearly both.

Let's look at the null pointer case first: Is this a memory safety issue? Yes, this is definitely a memory safety issue. The actual hardware has no concept of a "null" pointer, it just uses raw addresses - so if we allow this operation typically we're accessing arbitrary memory which happens to have an address corresponding to our "null" pointer. How about type safety? Well we violate type safety if we perform any operation on an object which isn't sanctioned by its type, and dereferencing isn't a sanctioned operation for the null pointer type.

Now how about array bounds? Memory safety is pretty obvious here, this is the classic stack smash beloved of "hackers". And type safety? The bounds miss is not a sanctioned operation for this type.

That's not really how most type systems work. Take array access. The typical typing is: if you have an `Array[A]` and reference an `Int` index you get an element of type `A`.

ref: Array[A] Int => A

This says nothing about what happens if you access an out of bounds element. In a memory safe language this is enforced by a runtime check. Without memory safety you get YOLO semantics like in C.

I don't know what kind of type system you have in mind then. Do you have an example of language where all array types have a way to check, statically, that all indexing operations are in bound? How would that even work? A language without dynamically-sized arrays at all, maybe?

I think you can do this with proof assistants, and with the SPARK version of Ada.

You can also do it with a dependent type system. I haven't used it, but from what I've read, in the ATS programming language, which is dependently typed, you can guarantee that array index accesses and pointer arithmetic never goes out of bounds, at the cost of having to pass proof variables explicitly to various functions.

This poster goes over how to ensure you don't cause buffer overflows in it:

https://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-b...

https://bluishcoder.co.nz/2018/01/10/capturing-program-invar...

It's a bit obscure; this is the only person who's ever blogged about ATS, as far as I can tell.

Two things.

Firstly, it is simply not the case that all constraints must be able to be statically enforced for them to constitute part of the type's definition. I'd guess that's a huge part of the confusion here.

But, yes, actually all WUFFS indexing is statically checked. It's using inference to conclude the range of the index, so if it won't fit that's a static type mismatch.

In this case, a type sade programming language would stop you from trying to write to read-only memory at compile time.

Reply on news.ycombinator.com