Looking at the current new and coming languages
I would take a hard look at NIM. It may be is not there yet
but it looks highly appealing, is as fast as the often
mentioned Rust and compiles significantly faster.
http://nim-lang.org/
Getting Past C
401–410 of 504 posts
Re: Getting Past C
#402Earlier quoted context omitted.
With C++, the default is zero overhead, not safety.
If people start to consider bound checking branches as overhead (which, in some extremely rare limited cases, they are in the right to do so), they should as well understand what happen with e.g. some largely used calling convention such as the one of Windows. Even in optimised builds, a unique_ptr for example can have an overhead compared to a raw pointer, IIRC because it forces going through the stack. If I remembe…
> if you are in a so performance critical section that you start to care about the "zero overhead" kind of stuff
If I don't have this kind of performance needs, I have no reason to use C++ to begin with. I mean, why use such a monster if I don't need the crazy performance it may offer when used properly? And even then, C, D, or Rust may be viable alternatives.
Re: Getting Past C
#403I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.
> One has to just strive to not use the C baggage that comes with it. This is why they get clubed together, regardless how much I like C++, I am yet to see the use of C baggage being successfully forbidden in enterprise teams, let alone if there are third party dependencies (which is always the case). So far I have only seen modern, safe C++ being used successfully on a big project I was part of at CERN, where everyo…
Do those enterprise teams use rust / go or have they already moved on to Java and .NET many years ago? :)
The enterprise is not the target here.
Re: Getting Past C
#404Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security.
It doesn't have to deal with 40 years of bad legacy code written by sloppy developers.
You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't even dare to write multi-threading apps without helgrind/TSAN.
And Rust doesn't help in this regard. From: https://doc.rust-lang.org/nomicon/races.html 'So it's perfectly "fine" for a Safe Rust program to get deadlocked or do something incredibly stupid with incorrect synchronization.'
Re: Getting Past C
#405> One of the medium-term possibilities we’re seriously considering for NTPsec is moving the entire codebase out of C into a language with no buffer overruns For a small one time fee of 1000 USD I can copy paste you 50-100 lines of C that provides an implementation of an array without buffer oveflows. Cheaper than switching to rust or you know, learning C properly.
Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?
Sure, if the array index is limited to 32 or 16 or 8 bits I can also give it to you at no performance cost for heap allocated arrays (i.e. no bound check happen at runtime).
There is some memory overhead per array with this method though.
Re: Getting Past C
#406Earlier quoted context omitted.
Many rust advocates talk about the performance cost of doing things safely in C, and inform me that rust has "Zero-cost abstractions". So it's fairly natural I ask for something I can benchmark.
Having used C (on and off) for about twenty years, including writing aerospace software in C, I strongly agree that writing safe C is possible. Rust (which I have thus far only tinkered with) looks pretty appealing to me, though. Do you suggest using C instead of Rust? If so, why?
If Rust solves the kinds of problems you have, then by all means use it. I don't think there exists a language that's in all aspects better than any other. For me personally, C is the language that gets in my way the least without forcing me to write ASM, and that happens to be highest on my list. If there was a language with the same idea of minimalism behind it as C, but with all the quirks and bad syntax choices out, i'd switch in a heartbeat.
Re: Getting Past C
#407I would start by getting the code to compile with g++, then begin migrating the dangerous C constructs to safe C++ constructs. IMO, that would be a safe, reasonable thing to do.
How would you prevent other developers to write C style code?
Project leadership, coding standards, automated analysis and code reviews.
But realistically speaking it might be easier to change tools for a significant number of teams, because the software development community is in general poor at leadership and process. A rewrite seems more approachable for the average (not necessarily average skills-wise) dev compared to a change in attitude, self-reflection and incremental improvement at a department or company level.
Then the rust compiler will pummel everyone into submission. This can be a succesful strategy. :)
Re: Getting Past C
#408Earlier quoted context omitted.
Why allow programmers to make mistakes? For a philosophical counterpoint: Why allow anyone to do anything that might possibly be incorrect, harmful, or otherwise perceived by some to be negative? I've looked at a lot of the talk surrounding "safe/secure languages", "safe/secure programming", etc., and yet every time I've heard people preach about the benefits, I feel like I just vehemently disagree. At a very deep an…
People rely heavily on software in many aspects of their lives. They entrust it with their personal information, their money, and in many cases their physical safety. Engineers building software and companies selling it are ethically obliged to make a good faith effort to prevent defects that might betray their users' trust and cause harm. Languages designed to enhance the safety and security of software written in t…
Are engineering standards for public buildings evil because they stifle architects' freedom to design whatever crazy structures tickle their fancy?
The physical analogy is good because even there one can see that there are different standards --- and, unlike what the "safe software" community seems to promote, engineers are not doing the equivalent of making every building strong enough to withstand a nuclear war and calling anything less "unsafe".
This also brings up another difference with software: the "absoluteness". In the physical world, no security is perfect. Locksmiths exist, and with enough determination, essentially anything can be broken into. But in the software world, with good encryption, that can never occur. Provably correct software can be employed for effectively unbreakable DRM and un-rootable/jailbreakable user-hostile devices, of which there is (fortunately) no similar real-world analogy I can think of.
Nobody's saying you can't do that; that sounds rather dystopian, a society where pointer arithmetic is illegal!
Given that there are attempts at even prohibiting Turing-completeness[1][2], I would not be surprised if that eventually happens. As it is, I'm sure there are already people who would consider you suspicious if you write software in an "unsafe" language, and from there it is not far to complete prohibition.
"The road to hell is paved with good intentions."
Re: Getting Past C
#409My experience is that using C for main(argc,argv)-style programs is rarely a problem. Trouble comes when using long running single-address space containers for service-like abstractions with pthreads etc.; in that kind of environment, malloc() and co. don't cut it because even if you get memory allocation right, unless using pooled memory allocators, memory fragmentation is becoming a serious (ie. unsurmountable) problem.
It's been said over and over since at least the Java times that creating OS processes for individual service invocations is bad for performance, but I've never seen proof for this statement in the form of a benchmark.
Even the OpenBSD developers (who know a thing or two wrt. security of memory allocation schemes) diss process-per-service-invocation architectures in their httpd implementation (eg. calling their CGI bridge "slowcgi" and favouring fcgi over it).
Isn't that inconsequential? I mean if there's a performance problem with CGI-like process-per-service invocations, why not target these problems at the OS level (or via pooling of network connections or whatever the bottleneck is)?
Re: Getting Past C
#410Rust is surely fine, and an improvement over C, but its main advantage is that all the rust code is written now, when everyone takes more care about security. It doesn't have to deal with 40 years of bad legacy code written by sloppy developers. You can obtain similar quality in a C modern code-base, using tools like static and dynamic analyzers. In fact, today the hardest issues came from multi-threading. I won't ev…
Some people take more care about writing safe & secure code today. Most only care just enough to switch to Java or Python in order not to care any more.
The big question for me is what will happen when those same developers writing insecure C and C++ code start writing rust? Will they find ways to subvert the safety checks? Will they even want to subject themselves to them in the first place?