31–40 of 80 posts
First the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have this question: fn ParseAsInt() The goal for this new languages like Rust, Carbon, Go etc. is to introduce "better" alternatives to C and C++ languages and move the developers over. Nothing is wrong with that. Now to syntax: I completely understand syntax constr…
First the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have this question: fn ParseAsInt() The goal for this new languages like Rust, Carbon, Go etc. is to introduce "better" alternatives to C and C++ languages and move the developers over. Nothing is wrong with that. Now to syntax: I completely understand syntax constr…
Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.
First the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have this question: fn ParseAsInt() The goal for this new languages like Rust, Carbon, Go etc. is to introduce "better" alternatives to C and C++ languages and move the developers over. Nothing is wrong with that. Now to syntax: I completely understand syntax constr…
Earlier quoted context omitted.
I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust). However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I be…
Scala and F# are safer than Rust since they're on a VM.
Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
Earlier quoted context omitted.
> Circle did the interpreted, compile-time pass idea before any of the other new systems languages. constexpr is in C++11, Jai is from 2014, and Zig 0.1.1 is from 2017. This project looks quite cool though.
With the small difference that Circle can use the complete language at compile time, constexpr is still far from it, and also gave birth to constinit and consteval.
constexpr in C++ 11 is indeed very limited, arguably even more than Rust's const functions today.
Now, solve package management and I'll be ready to be back on board the C++ train!
Can't comment on Conan but, I hear it's nice
Earlier quoted context omitted.
I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust). However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I be…
C++ templates cannot be reused or rewritten piecemeal in a new language, it's practically impossible. There's a reason why the Rust folks were very careful to separate out generics from the more flexible case of macros (that come in both rewrite-based and procedural varieties).
Of course:
- this doesn't cross library boundaries;
- this assumes robust enough static analysis, which is not possible in the general case, since templates are non-decidable in the general case – so you need to restrict your new language to more reasonable semantics;
- let's not even get started on the interaction between templates and C-style macros – at some point, you need to throw the towel.
Earlier quoted context omitted.
I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust). However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I be…
Scala and F# are safer than Rust since they're on a VM.
Do you have any evidence to back up your claim?
Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo...
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr
Programming languages running on VM is not a safety guarantee.
Earlier quoted context omitted.
Scala and F# are safer than Rust since they're on a VM.
As far as I understand, both these languages are subject to data races whereas (safe) Rust is not. Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
Earlier quoted context omitted.
Scala and F# are safer than Rust since they're on a VM.
>> Scala and F# are safer than Rust since they're on a VM. Do you have any evidence to back up your claim? Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr Programming languages running on VM is not a safety guarantee.