6 ms·
Gonna go on a tangent here. I'm always curious about stuff like this. Everyone and their mother wants to replace C, but what's people's answer to it being a par
by andrewmcwatters 9y ago
Gonna go on a tangent here. I'm always curious about stuff like this. Everyone and their mother wants to replace C, but what's people's answer to it being a part of POSIX? I mean it's literally a part of the standards family, and no one seems to address this. I can never take aspiring C-replacements seriously because no one comes out and openly says, "This is how we replace C."
They're all really just claims that C is bad, and we shouldn't use it. Okay, well how do you replace it? Or was that never the goal to begin with and you just want me to use this language?
- floatboth 9y agoWho cares about POSIX? And yeah, Redox is how "we replace C". A full operating system where C is not the main language.
- tzahola 9y agoWhy does an OS have a “main” language?
- vbezhenar 9y agoIf you know this language, you can change any part of OS. I think that's a valuable asset. For example if you're using OpenBSD and know C, you can hack anything from kernel to smtp daemon. If you're OS is written with 10 languages, it's much harder to learn them all.
- adrianmonk 9y agoThat's a good argument for keeping the set of languages limited. But it doesn't necessarily have to be just one.
- tonyg 9y agoThere's such a strong connection between the idea of "programming language runtime" and "operating system" (resource management, I/O management, task scheduling, package management, upgrade management, lifecycle management, version control, configuration management, user interface, etc.) that it makes sense both to - think of a PL as an OS (Smalltalk, Erlang, JVM) - think of an OS as a PL The latter leads to the idea that there might be a "main language" for an OS in the same way there's a "main language" for Smalltalk, Erlang, and JVM runtimes (Smalltalk, Erlang, and Java, respectively), and "auxiliary languages" that fit into the same runtimes (Java/Self/etc, Elixir/LFE/etc, and Scala/Clojure/Kotlin/etc, respectively).
- favorited 9y agoAnyone who ships software to multiple operating systems? Anyone who maintains a port? And, transitively, the users of that software.
- pjmlp 9y ago> Anyone who ships software to multiple operating systems? You can do that without direct dependencies to POSIX. I don't care how .NET, Java, Go, Free Pascal, Ruby, Python, Perl,Swift, D, C++... implement their runtimes, unless I actually need to look under the hood.
- zbentley 9y agoGo write a complex program for Windows 95, without unix/cygwin helpers. Or for DOS. Then come back and explain to me who cares about POSIX. It'll be an educational experience.
- pjmlp 9y agoI don't care. Started doing desktop software development on MS-DOS 3.3. POSIX is only relevant for C, the bits that they felt shouldn't be part of ANSI C, not to impose UNIX semantics on other OSes. It is completly irrelevant on programming languages with rich runtimes or good package managers available.
- tonyg 9y agoAre you saying that the only people who care about POSIX are those saddled with legacy systems that they can't get rid of? That actually sounds about right to me.
- zbentley 9y agoThey aren't the only ones, but there's some truth there. POSIX, and other similar uniform standards, are very much a "you don't know what you've got 'til it's gone" type of thing.
- qaq 9y agoThe non-goals of Redox We are not a Linux clone, or POSIX-compliant
- korethr 9y agoRedox bills itself as a Unix-like OS. Seems to me Posix compliance, or attempting to get close to it would fall under being "Unix-like".
- empath75 9y agoIf they wanted to build a Unix, they’d have said they were building a Unix.
- korethr 9y agoI think you're splitting hairs. If someone is making an OS they claim is "Unix-like", then it isn't unreasonable for someone to expect that the code that compiles and runs on AIX, HP-UX, MacOS, Solaris, and OpenBSD will also compile and run on this new "Unix-like" OS with minimal changes. If they're not going for POSIX compliance, or even getting reasonably close thereto, they're going to have a hard time being "Unix-like" in practice, certifications be damned.
- imtringued 9y ago
- geofft 9y agoReplacing C in part is valuable. You don't have to have a plan to replace all C code in an entire stack to get measurable improvements (performance, readability, barrier to entry, modularity, features, and yes security) from the work. POSIX is an ideal. It's true that POSIX is defined in terms of the C API instead of any ABI - Rust libstd used to have a tiny bit of code I wrote to deal with the fact that Android's libc exposes a couple of signal-handling functions as inline functions in <signal.h>, which is perfectly fine as POSIX goes but annoying if you're not writing in C. But in practice you can successfully bind to POSIX implementations from non-C languages and only need workarounds like this a few times, and in the same way, you can write a POSIX-fulfilling set of header files that interface to a non-C implementation. And once you replace every component... you've replaced C.
- jcranmer 9y agoA rant I've wanted to do for a while: We're at the point now where it would be useful to be able to express ABIs and FFI in a language-agnostic manner without resorting to C. C lacks the capability to describe fairly widespread functionality: things like fixed-size integer types [0], pointer lifetimes, arrays with lengths, functions with bound environments, variable arguments [1]. Keeping distinctions between binary strings and textual strings would be useful for languages, and tracking how to deallocate pointers would be beneficial as well. An ABI that allows systems with different GCs to pass GC information to each other would be amazing, if challenging. Unfortunately, we're sort of in a catch-22. The multilingual interoperation has to go through C, because that's the only standard that exists. The people who write the standards look at the situation and see no reason to go beyond C because no one's proposing an alternative. [0] Sort of. There is <stdint.h>, but C tends to fundamentally think in terms of char/short/int/long/long long, and there have been issues with trying to work out what [u]int64_t maps to. [1] Not in C's broken sense of "there are more arguments after this point, but you get to guess how many." Rather, I'm thinking of a more Java sense of "here's the list of extra arguments the caller gave me."
- adrianratnapala 9y agoI mostly agree. The caveat is that we can still express things like pointer lifetimes and even arrays-with-lengths in English. E.g. libc is full of arrays-with-lengths, implemented as separate params. Don't get me wrong: I think it is great that more powerful languages automate and check those things. But it is also right for ABIs to be two-steps behind so that they don't tie themselves to a single language. And here is the real problem with ABIs and C -- C is a single language. Ages ago C was a decent lingua franca, because C programs translated to machine code in pretty easy to guess ways, and the job of an ABI was just to formalise those guesses. But nowadays we have aggressive optimisers, expansive definitions of undefined behaviour, clever parameter passing conventions, abstract "memory models" defining concurrency rules and all kinds of other stuff that make C something more than just an obvious abstraction of real-world machines.
- mjevans 9y agoWhat sort of properties would you consider a "textual string" to have that a "binary string" would lack? Offhand I'd assume you mean some of the following, but I'm curious if /my/ assumption about your needs is correct and complete. (Also, note that some of these may be implied by values elsewhere in the specification, it isn't strictly a data structure.) * flag:isValidated * targetEncoding * flag:isNormalized * targetNormalization * lengthMemory (not including the implicit size of the type's metadata) * lengthCodepoints (distinct encoding elements) * length(Some word meaning complete display elements, but not the actual width, height, etc.) Do you also need actual random access to individual codepoints/"full characters"? Or is the assumption that if such a scan is in progress the entire sequence or major parts of it are being fully-scanned? What if, within a given function call*, the underlying storage could be referenced with zero-copying and substrings made? (On exiting that context they'd be copied if retained.) It might be useful to have library iterators that split on say, a single given character, segments up to a maximum memory size of N (and scanning backwards for the last "full character" or at least complete rune). Of course, I believe that, by /default/ a program should perform /binary/ interaction with files including standard in/out/err. If there is a process for converting such binary input/output it should assume and produce data in UTF-8 (in NFC normalization) (when converting to/from "text" types) as a default, which should be easy to globally over-ride or set specifically for a given open file (and change mid use). Of course I don't normally need to care about the encoding of data directly; libraries with parsers and writers typically do that as well as other encoding/decoding for that format for me. Everything else tends to be copy / compare and do not change, or making filenames (mostly append bits of "should all be UTF-8"). Actual, hard core, manipulation of encoded streams seems far more like a composition editing issue (A specific editor where default input dialogs are insufficient) or something that underlying libraries need to worry about.
- zamalek 9y agoSo long as you can export using standard x86 conventions (cdecl, stdcall, syscall, etc.) there is no need to replace it. Even a managed (.Net, Java, Go, etc.) POSIX could interact with C, provided it can import and export C calls. This also means that the C/++ compiler, which depends on these standard imports and exports, could theoretically run in a pure Rust POSIX. In theory.
- cryptonector 9y agoWhat's the issue? So what if POSIX is specified in using C. That's just an API, and Rust can use it. The ABI is not specified by POSIX, naturally, but the platform does specify an ABI (or enough that you can derive an ABI for an API).
- xenadu02 9y agoIt is still difficult to get some people to believe C is a problem at all. Until the majority of the industry (and especially OS vendors) agree that we should have a replacement systems programming language we can't begin the discussion on what that replacement should look like.
- pjmlp 9y agoYeah, what did Microsoft get when they decided C was done and the path forward was C++ and .NET? Google with their locking down of C in Android and ChromeOS? Apple with their long term roadmap to replace everything with Swift? Being bashed how it is possible that they aren't willing to keep on using C, walled gardens and such.