| Quote: | “Performance-wise, Golang is closer to Node.js than to C/C++” |
| Another Quote: | “concurrency (leave alone efficient concurrency) is never easy” |
| [→] |
The choice of programming language for your Next Big Project can be difficult. Even worse, it can seem easy… when it is not. On the one hand, strictly speaking, you can write any program in any of Turing-complete languages. On the other hand, that doesn’t mean it will be easy. In fact, writing a program in a poorly suitable programming language could be extremely difficult.
Programming Languages, page 1:
Programming Languages As a Social Network
The Idea Recently, I was thinking about visualizing relations among different programming languages, and a thought has crossed my mind: Methodology I took quite a few more-or-less popular programming languages (33 to be exact); however, I explicitly restricted myself to more-or-less general-purpose programming languages. This eliminated DSLs such as R, as well as all dialects […]
Java vs C++: Trading UB for Semantic Memory Leaks (Same Problem, Different Punishment for Failure)
| Quote: | “with all due disrespect to mutable static/global data, I have to say that the problem of semantic memory leaks is NOT restricted to statics” |
| Another Quote: | “semantics of good code is about the same regardless of Java/C++ choice” |
| [→] |
C++: “model of the hardware” vs “model of the compiler”
| Quote: | “we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that’s it).” |
| Another Quote: | “My problem with introducing a ‘model of the compiler’ into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements.” |
| [→] |
Unchecked Exceptions for C++
| Quote: | “‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'” |
| Another Quote: | “Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.” |
| [→] |
App-level Developer on std::error Exceptions Proposal for C++. Part II. The Discussion.
| Quote: | “having an ability to associate extra information with std::error is important for us – both for our own std::error exceptions, and for conversion from existing C++ exceptions” |
| Another Quote: | “I think that current C++ standard is Badly Lacking(tm) a concept of ‘segfault’ (which is supported by CPUs on VAST majority of modern systems with modern C++ compilers)” |
| [→] |
App-level Developer on std::error Exceptions Proposal for C++. Part I. The Good
| Quote: | “No single error handling method is good enough for ALL the projects – which in turn leads to segmentation, with some of the projects using exceptions, and some others using error codes” |
| Another Quote: | “Right above I said that I like the std::error exception proposal a.k.a.[P0709R0]. However, as soon as I look at competing proposals, I begin to love it.” |
| [→] |