4 ms·

>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 pointe

by carlmr 3y ago

>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

actionfromafar 3y ago
C# can also manipulate memory: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/pointer-related-operators https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
- giancarlostoro 3y ago
  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.
ludocode 3y ago
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.
- e12e 3y ago
  If you want simple, there's always Pascal.
  - OnlyMortal 3y ago
    … and Modula 2!!
- vlovich123 3y ago
  > 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.
- binary132 3y ago
  Rust isn’t even really a successor to C++
cornholio 3y ago
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.
- guipsp 3y ago
  A decade is nothing in the lifespan of a programming language
- e12e 3y ago
  > 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.
- pyrale 3y ago
  What you're describing is not the successor of C, though. It's one of the many managed-memory languages.
- vlovich123 3y ago
  > 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.
cyco130 3y ago
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/ https://ziglang.org/
- vlovich123 3y ago
  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++).
giancarlostoro 3y ago
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.
crabbone 3y ago
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?

by carlmr 3y ago

>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

actionfromafar 3y ago

C# can also manipulate memory: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/pointer-related-operators https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

giancarlostoro 3y ago
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.

ludocode 3y ago

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.

e12e 3y ago
If you want simple, there's always Pascal.
- OnlyMortal 3y ago
  … and Modula 2!!
vlovich123 3y ago
> 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.
binary132 3y ago
Rust isn’t even really a successor to C++

cornholio 3y ago

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.

guipsp 3y ago
A decade is nothing in the lifespan of a programming language
e12e 3y ago
> 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.
pyrale 3y ago
What you're describing is not the successor of C, though. It's one of the many managed-memory languages.
vlovich123 3y ago
> 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.

cyco130 3y ago

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/ https://ziglang.org/

vlovich123 3y ago
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++).

giancarlostoro 3y ago

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.

crabbone 3y ago

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?