211–220 of 270 posts
Earlier quoted context omitted.
> dangling pointers to raw memory that [are not] cleaned How do you feel about building special constructs to automatically handle these ?
I totally can but my gripe is about not wanting to.
Earlier quoted context omitted.
That would be C# ?
I understood the sibling comment recommending Ocaml and to a lesser extent Borgo, but OP is looking for a high level functional programming language based on giving Gleam as the reference point. How does C# fit here. I do think the compilation speed and runtime is at least in the same ballpark, but C#, while a perfectly fine language, is definitely not a functional language in syntax or semantics.
Earlier quoted context omitted.
Borgo could be your thing? https://borgo-lang.github.io
It looked really good! But seems kinda dead, and I don't know the Go ecosystem well enough to know if dead things can sort of keep working forever
This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day
Unfortunately the current trend among new languages seems to be eschewing GC; a clear mistake IMO — we don't really need yet another low-level systems programming language, but we badly need the go-to GC'd lang — one that'd take the faults of Java and Go into account.
Earlier quoted context omitted.
That would be C# ?
I understood the sibling comment recommending Ocaml and to a lesser extent Borgo, but OP is looking for a high level functional programming language based on giving Gleam as the reference point. How does C# fit here. I do think the compilation speed and runtime is at least in the same ballpark, but C#, while a perfectly fine language, is definitely not a functional language in syntax or semantics.
Earlier quoted context omitted.
Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…
I guess the reason I found it surprising is that I would only use 3 (ie risk introducing UB) for invariants that I was very certain were true, whereas I would mostly use 2 for invariants that I had reason to believe might not always be true. It struck me as odd that you'd use the same tool for scenario's that feel like opposites, especially when you can just switch between these modes with a compiler flag
The runtime check thing just sounds like a debugging feature.
Earlier quoted context omitted.
“However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated” This implies that a compiler would be permitted to remove precisely that actual code that checks the condition in non-safe mode. Seems like a deliberately introduced footgun.
My understanding of this was that the UB starts only after the value is passed/returned. So if foo() has a contract to only return positive integers, the code within foo can check and ensure this, but if the calling code does it, the compiler might optimize it away.
Earlier quoted context omitted.
Which one specifically does ending a process not clean up the memory?
Any flat memory rtos. Not everything is *nix. For example microcontrollers or aerospace systems.
I've been following C3 for sometime now, and I really appreciate the discipline in the design philosophy here. Neither does it force a new memory model on you, nor does it try to be C++. The killer feature for me is the full ABI compatibility. The fact that I no longer have to write bindings and can just mix C3 files into my existing C build system reduces the friction to near zero. Kudos to the maintainer for sticki…
Is full ABI compatibility important? I'm having a hard time seeing why. I mean… C isn't even an unsafe language. It's just that C implementations and ABIs are unsafe. Some fat pointers, less insanely unsafe varargs implementations, UBSan on by default, MTE… soon you're doing pretty well! (Exceptions apply.)
And the various system ABIs supported by C compilers are the defacto standards for that (contrary to popular belief there is no such thing as a "C ABI" - those ABIs are commonly defined by OS and CPU vendors, C compilers need to implement those ABIs just like any other compiler toolchain if they want to talk to operating system interfaces or call into libraries compiled with different compilers from different languages).