The Rust Foundation gets ready to Rumbul (we're sure new CEO has never, ever heard that joke before)

The Rust Foundation – the US non-profit behind the programming language since Mozilla let the team go – has picked a new CEO: Rebecca Rumbul, formerly director of research and engagement at digital democracy charity mySociety, and before that the Privacy Collective. Dr Rumbul's appointment at the relatively new foundation …

[a_yank_lurker]

Congrats

Congrats to heady up Rust.

On Go and Rust, I am familiar with both. Both are solid attempts to make certain types of programming easier and more reliable. One feature of Go I would like to see adopted more probably is its type system.

On C/C++, both were excellent languages when created but they have not aged particularly well (something true of many languages from their eras to be fair).

[bombastic bob]

Re: Congrats

they have not aged particularly well

I completely disagree. What is your definition of "aged well" such that it would NOT cover C nor C++?

(a moving target that radically changes every few months is NOT "aging well" just in case that is what you meant)

[Anonymous Coward]

Re: Congrats

C has aged better than C++ I think. C++ has become a bit of a dog's dinner with syntactic flourishes everywhere. There's a serious risk that c++ code becomes more symbols than letters which doesn't help legibility.

[Anonymous Coward]

Re: Congrats

> Both are solid attempts to make certain types of programming easier and more reliable.

I've got news for you: programming languages don't write unreliable programs. Incompetent programmers do.

[Phil Lord]

Re: Congrats

Also, alas, high competent programmers write unreliable programs.

Looking for better tools to write code with has been happening since the beginning of computer time. Why would it stop now?

[fg_swe]

Re: Congrats

All programmers and software engineers are just fallible humans. They have families, managers, relationships. All of that can create pressure which will result in nasty software bugs.

It happened to HPUX, Linux kernel, Windows kernel and many other systems.

[Ignazio]

Re: Congrats

I've got news for you: bad craftsmen blame the tools, good craftsmen never stop looking for better tools. A bad tool gets in the way of every craftsman.

[fg_swe]

Problems of C and C++

Rust has been specifically created to address the serious weakness of C and C++ - a lack of memory safety.

Memory safety has many aspects. On page 2 of this presentation they are listed: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

[Anonymous Coward]

Re: Problems of C and C++

> Rust has been specifically created to address the serious weakness of C and C++ - a lack of memory safety.

Translation:

1. lack of memory safety - never could figure out pointers. Double pointers are the spawn of Satan.

2. serious weakness of C and C++ - barely understood C, C++ might as well have been Vinča symbols.

Programmers have wives, families and life problems.

Rust is designed to address all that. Rust will help with divorce, crying babies, psycho ex-girlfriend/boyfriend who comes over and makes a scene at 3AM, meddling mother-in-law, you name it, Rust will fix it. It will make your code run and work flawlessly even though what you wrote is shit.

Rust can do that because it's been designed that way. By people who designed it so it does that. Other languages don't have the amount of design that Rust has.

Webscale.

[fg_swe]

Yeah, Cynicism

That will surely help you improve the state of the art. Not.

Once again:

1.) Wife gives programmer hell

2.) Programmer has cloudy mind

3.) Programmer makes rookie mistake due to 2.

4a) Rust compiler detects mistake

OR

4b) Rust runtime will detect problem and stop execution.

With C and C++:

4.) Mysterious faults, always at a different place.

[bombastic bob]

about that steeper learning curve...

Back in the 1980's I learned C programming in a night class at a local city college.

That's VERY important: you can take a night school class to learn C.

Is there such a thing WORLD WIDE for Rust? (I looked n the San Diego city college web site and did not see anything, but maybe my search terms were wrong... it's where I had my C class decades ago)

As for language speed, it's interesting that C and C++ (according to the article) are still a bit faster than Rust.

in fact, there was a comparison: "But so are Ada and FORTRAN" (FTFY)

I learned FORTRAN long ago, on my own from reading the docs. My assembly language prof LOVED Algol, and C was still mostly unknown outside of the UNIX community. I taught myself Pascal but wasn't really good at it. The C class helped a LOT.

And my first OFFICIAL I.T. job was programming in FORTRAN for the ASK/MANMAN system on an HP3000. Old school I.T. (The accountants liked me because I got all of their report backlog done and talked to them to see what they REALLY needed before doing it. Even the HR guy changed his mind after I provided him with some complicated reports he wanted. HR usually HATES me. But yeah, FORTRAN was a big part of it).

So it woulx seem to me that FIXING THIS OTHER PROBLEM, that is the STEEP LEARNING CURVE, would be the RIGHT thing to do.

(that and stop trying to use Rust when it is really not fit for purpose)

[Phil Lord]

Re: about that steeper learning curve...

There are more C/C++ programmers out there than Rust, so obviously, there are more people who can teach it also.

Having said that, Rust has produced quite a large quantity of fairly good documentation, freely available, as well as a number of books that you can buy. They have also a very good and supportive community. All of which is available world wide via the magic of the web. It's how I learned Rust.

Decreasing the learning curve, indeed, is a good thing. Some of that comes from your background. Javascript programmers will probably have an easier time than C programmers, because Rust is fairly functional. And some will come from the many "quality of life" improvements that Rust has made particularly to lifetime handling. I think it is easier now than it was four years ago when I learned it, although that's hard to measure.

[cdegroot]

Nothing new...

Also, from my toying with Rust, it feels like a competent C programmer will be able to dive right in - a lot of the techniques that Rust employs in the compiler have been employed for decades in C coders' brains, like passing ownership of pointers around.

Golang is a manager's dream - a language so hobbled that you cannot write bad code in it (you also cannot write good code in it, just mediocre code) so that developers become replaceable cogs. It is not a surprise that Google developed it.

[Phil Lord]

Re: about that steeper learning curve...

"C [...] is still a bit faster according to the article".

Yeah, the article is probably wrong there. It's very hard to compare across languages, of course, but where it has been done Rust and C come out about as fast as it is possible to come out, and much the same. GO is also very fast, even with GC.

The article is also wrong about concurrency. Rust had this well before version 1.39, it just didn't have async/await as keywords. That should be obvious really. Who would design a single-threaded programming language in the 21st century?

I think most of the articles conclusions (lone programmers vs big groups) are equally suspect. Still, the title is fun.

[fg_swe]

Garbage Collection

All the GC-based languages I have seen in the real world suffer from

A) non-deterministic runtime, because the GC mark+sweep can hit at any time. This is bad for GUI ergonomics and other realtime applications.

B) High RAM consumption. GC-based programs consume typically 2x the amount of RAM of an equivalent reference-counted program. That translates in higher energy consumption (read CO2) and higher capital costs.

[bombastic bob]

Re: Garbage Collection

I am certainly NO fan of garbage collection. I think it is a CANCER that needs to be removed as an option. The best way to manage object lifetimes (outside of a single function) is with thread-safe reference counting, coupled with a little discipline like allocating and freeing an object ONLY via a constructor utility and a destructor (as an example) which would both employ reference counting so that the object can be shared and will live its life long enough to prevent GPF/PageFault and other nastiness.

As long as you can preserve the life of an object WITHOUT garbage collection, your programs will be faster, AT LEAST as reliable, and without the bloat/overhead that garbage collection would otherwise require. Bumping a ref count using atomic operators is often only a few CPU instructions.

(handle de-reference using sufficiently randomized handle values, along with an efficient hash, is one way to manage this - yes I do this myself, actually)

[fg_swe]

Details of Reference Counting

If the language's type system can differentiate between thread-local and inter-thread data structures, then thread-local reference counting does not need atomic operations. Atomic operations (which synchronize multiple CPUs/cores) is much more expensive in terms of runtime.

In my language Sappeur this is exactly how it is done.

[Anonymous Coward]

Re: Garbage Collection

> [ ... ] equivalent reference-counted program.

What is a reference-counted program?

Please explain.

I know what reference-counted variables are. Never heard of a reference-counted program. Is it a program that counts references?

Why is is that the vast majority of fanboi supporters of Rust appear to be completely clueless about the basics of Computer Science?

Inquiring minds want to know.

[werdsmith]

Re: Garbage Collection

Why is is that the vast majority of fanboi supporters of Rust appear to be completely clueless about the basics of Computer Science?

Because the vast majority of people involved in writing code are clueless about the basics of computer science.

[Phil Lord]

Re: Garbage Collection

I don't know what a reference counting variable is either. References counting is done at the level of the value. The whole point is for where you cannot determine whether multiple variables point to the same value.

To bring it to the question of Rust, it does not reference count. The language uses a system of lifetime analysis to ensure that only one variable owns a value and that value outlives all references to that value. Mostly this is done statically. For the situation where it's too complex, Rust also provides library support for reference counting values. There are also libraries which do mark-and-sweep GC. I don't know how widely used they are.

Most people who use terms like "fanboi" and accuse others of being "clueless" do not actually have "inquiring minds", they just lack civility.

[Anonymous Coward]

Re: Garbage Collection

> Most people who use terms like "fanboi" and accuse others of being "clueless" do not actually have "inquiring minds", they just lack civility.

It would have been quite helpful if you had a clue what you were talking about. You don't.

Reference counting is NOT done at the level of the value, as you so innocently put it. It is done at variable level.

For example, 5 is a value. It is also an integer numeric constant. How do you reference-count an integer numeric constant? Please explain.

I can tell you right now how many instances of 5 as an integer constant value you would have in your program: exactly one. The compiler will constant-fold it. There is no need to reference-count it, and there is no need to keep around more than one instance of it, because 5 will always be 5, and will never magically change to 6 or 4.

But yeah, Rust. This is a perfect example of the types of "programmers" pushing Rust. Those who don't know the difference between a variable and a constant.

[Phil Lord]

Re: Garbage Collection

The number of variables can be determined at compile time. The number of values cannot. It's references that are one of the mechanisms for achieving this.

The value "5" is a different kettle of fish. Integers are fixed in size and usually take up the same amount of space as a reference. So most languages store these directly on the stack, rather than using a reference to the heap. You are wrong if you think that there is only one value 5 in a program; there could be any number and the compiler cannot determine how many 5s there are at compile time.

It can determine how many literal 5s there are, or expressions that always evaluate to 5 (i.e. constant folding). Again, there would still be multiple copies of "5" in the program, because there is no point interning an integer. Unlike, say, a string which might very well use an interned reference.

Of course, there are circumstances when it makes sense for "5" as a value to be referenced rather than stored directly, which is when you want to add some extra behaviour to it. Atomicity, is one example. Another is when 5 is not an bounded and fixed-size integer but a number you want to be grow to any arbitrary size or precision.

As for your last comment: c.f. previous argument about civility. It is a shame that you lack it.

[fg_swe]

Re: Garbage Collection

"How do you reference-count an integer numeric constant? Please explain."

Of course the interesting thing is to share an object with an integer variable inside.

Example for a Sappeur class to collect the sum of all ages of a population from a set of population files.

Objective is to determine average age. All threads reading the population files will update an object of the following type:

<pre>

class AgeSum multithreaded

{

longlong ageSum;

longlong numberHeads;

methods:

void addHead(int age);

int averageAge();

};

void AgeSum::addHead(int age)

{

ageSum = ageSum + age;

numberHeads++;

}

int ageSum::averageAge()

{

return cast(int,ageSum/numberHeads);

}

</pre>

Objects of this class will have both a reference counter and the methods of the generated C++ code will be protected by pthread_mutexes. Both listed methods can be called from any number of threads at the same time safely.

As a final note, this is certainly not the most efficient way of doing this calculation (as it requires a lock/unlock pair for each head processed), but for educational purposes it is good enough.

[fg_swe]

Errata

Must read "as it requires a pthread_mutex_lock()/pthread_mutex_unlock CALL for each head processed"

[fg_swe]

"Reference Counted"

I was using a quick expression for "program using heap memory objects, which have a reference count. When reference count goes to zero, destructor will be called."

Better ?

[Anonymous Coward]

Re: "Reference Counted"

> Better?

Not really.

> Rust runtime will detect problem and stop execution.

You seem to believe that this Rust run-time detection - of what exactly, I don't know, it's not clear - is cost-free. It's not.

If reference counting is involved, there is a cost penalty associated with it: the reference counter itself must be incremented / decremented atomically, inside a critical section. That can be done either (a) with a mutex lock and unlock or (b) with a cas (compare-and-swap).

Neither are cost free. And contrary to popular belief, neither method is lock-free.

Yet again, this all comes down to: so-called programmers who can't deal with pointers and dynamic memory allocation.

This is what happens when you don't learn C. Instead of keeping track of one's pointers and memory allocation, one relies on the machine to do it. It can do it, but it's always a giant hammer.

Instead of putting in the effort to determine where the double-free occurs, and correcting it, make everything a reference-counted pointer.

In final analysis, it's just a transfer of incompetence. The incompetence of the programmer is transferred to the incompetence of the Rust runtime, which will make everything reference-counted, whether it's needed or not.

Apparently, that's a valid approach.

The programmer still has no clue why their program doesn't work correctly in C (or C++). They just notice that "if I write it in Rust it doesn't crash, so I'ma gonna do that."

Cargo Cult Programming.

[fg_swe]

Re: "Reference Counted"

I kindly ask you to read here

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

https://www.chromium.org/Home/chromium-security/memory-safety

So both Google and Microsoft have come to the same conclusion.

Before you crow "Linux", I would like you to explain all of the exploitable kernel bugs, such as the one in gethostbyname(). The kernel developers are all rookies, eh ?

[Anonymous Coward]

Re: "Reference Counted"

> So both Google and Microsoft have come to the same conclusion.

Microsoft hasn't been able to write an operating system in 50+ years. They can kindly STFU with their blaming the programming language for their own incompetence.

Same goes for Google, only they haven't been around for 50+ years. Name one operating system written by Google. Please don't say Android. That's Linux, with some massive Java goo on top of it.

Yeah, Fuchsia. Right.

Kindly stop pushing crap about gethostbyname(3C) and Linux. That has nothing to do with C, or Linux, and everything to do with whoever wrote it. Not to mention the fact that gethostbyname(3C) is in the GNU Standard C Library, not the Linux kernel.

Take a look at the number of vulnerabilities in the Linux Kernel, and/or the GNU Standard C Library, and compare them with the number of vulnerabilities in Microsoft Windows.

Maybe Microsoft should mandate an Advanced C Programming class for their engineers instead of pushing this Rust turd as the magic solution to sloppy or incompetent programming.

[fg_swe]

Re: "Reference Counted"

HPUX Ping of Death ?

VxWorks TCP Datagram of Death and Subversion ?

The C language itself is a brittle, dangerous thing. Listen to Sir Tony Hoare (see my other post) or to Niklaus Wirth.

[fg_swe]

Re: "Reference Counted"

https://security.business.xerox.com/de-de/news/wind-river-vxworks-ipnet-tcp-ip-stack-vulnerabilities/

[fg_swe]

Re: "Reference Counted"

You are right, gethostbyname() was "just" an exploit in glibc. Bad enough, because it enables process takeover and it is used in many exposed places such as web browsers, MTAs and many more types of programs. Attackers could place a virus inside a HTTP URL, for example. One click and browser is pwned.

Here is a list of Linux kernel bugs; see yourself how many could have been avoided by a memory safe programming language: https://www.cvedetails.com/vulnerability-list.php?vendor_id=33&product_id=47&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=7.99&year=0&cweid=0&order=1&trc=729&sha=27cc1be095dd1cc4189b3d337cc787289500c13e

[Phil Lord]

Re: "Reference Counted"

Rust by default does not use reference counting at runtime. Rather it determines statically at compile time when the value associated with a variable can be deallocated and does this automatically for the programmer. There is no runtime cost associated with this.

This is not always possible, of course, for example if you intern strings created across a program to save memory. For those cases, Rust has support in the standard library for a reference counted pointer. Actually two. One for single threaded use and one for threaded use. Using the wrong one (i.e. using the single threaded one across threads) is a compile time error.

So, you pay the costs for what you need and pay no cost for what you do not need.

[Phil Lord]

Re: Garbage Collection

GO uses "critical sections" to address the realtime problem. I'm not sure that I would distinguish between reference counting and GC. Reference counting is a form of GC as far as I can see.

Rust doesn't GC by default, but it does provide a reference counting system -- so some of the values in a program are effectively GC'd and some not.

[DrXym]

Re: Garbage Collection

Rust doesn't do GC at all, nor reference counting anything without your knowledge as the programmer. So the only way a program is going to reference count is if you wrote code to do that, e.g. if you were modelling a tree or graph with nodes you might use reference counting.

Rust offers two containers for that - either Rc<> or Arc<>, the latter for atomic refcounting things shared by threads. If you don't share a struct between threads you can avoid some overhead by using Rc<>.

The closest analogue in C++ would be a std::shared_ptr<> which is analogous to Arc<>. Rust also has a thing called a Box<> which is like a std::unique_ptr<>.

[Anonymous Coward]

Re: about that steeper learning curve...

> Who would design a single-threaded programming language in the 21st century?

Rust always had multi threaded (traditional) asynchronous processing in mind, but the introduction of 'async' and `await` are new. Despite the keyword 'async' sounding like 'asynchronous' that really is a feature for sharing control synchronously between logically independent control sequences/tasks living in the same thread. 'psuedo-async' and 'psuedo-wait' would have been more accurately descriptive keywords.

Here is a link to an example in the rust book -

https://rust-lang.github.io/async-book/01_getting_started/04_async_await_primer.html

Here is a description of what it does -

In this example, learning the song must happen before singing the song, but both learning and singing can happen at the same time as dancing. If we used block_on(learn_song()) rather than learn_song().await in learn_and_sing, the thread wouldn't be able to do anything else while learn_song was running. This would make it impossible to dance at the same time. By .await-ing the learn_song future, we allow other tasks to take over the current thread if learn_song is blocked. This makes it possible to run multiple futures to completion concurrently on the same thread.

Notice the final four words - "on the same thread".

Threads are an operating system feature, and languages can be designed to interface that OS feature.

Concurrency is strictly a language level feature. Concurrency implement through events is a very old paradigm. Think Windows 3 message queue from the 1990. That got blown away by improvements in multi-threading and fell out of use.

But concurrent programming event loops re-emerged in 1995 with Javascript, because it was a practical paradigm for broswer programming and web servers.

However, the event loop paradigm makes it harder to clearly program top down control and leads to a lot of errors, relative to a single line of control program. The 'await' and 'async' keywords paradigm for concurrent programming was introduced in 2012 by Simon Marlow in Haskell. That paradigm is not ubiquitous in concurrent programming.

[DrXym]

Re: about that steeper learning curve...

Yup, Rust has had strong concurrency support since before 1.0, enforcing data protection at compile time. Also people were playing with futures and async IO before it became a language feature.

I have to say that async/await make it a breeze to write async code. Using tokio before was doable but it was also painful.

[fg_swe]

Re: about that steeper learning curve...

Fortran is lacking memory safety and according to Tony Hoare real-world Fortran programs have serious "hidden" index error problems. Deterministic detection of index errors is a key aspect of memory safety.

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

[glococo]

Someone have to say it

What it really makes me twist is to watch a new language ending each line with the semicolon.

That is something from the past, noisy and ugly

[Phil Lord]

Re: Someone have to say it

The semi-colon in Rust has some semantic beyond the end of the line actually. Or more the lack of one. Without a semi the line becomes a function return expression.

Feels a bit ugly when you start, but works out nicely once you are used to it. Having learned it, though, I find my python code keeps breaking, when I forget to put a return statement in a one line function.

[dajames]

Re: Someone have to say it

What it really makes me twist is to watch a new language ending each line with the semicolon.

Semicolons don't end lines, they separate statements (in Rust).

This is a good thing. It means that line ends and statement ends are not one and the same, so one could write multiple statements on a single line or split a statement over several lines and it is still very simple for the parser to tell where one statement ends and the next begins.

You wouldn't write English prose without using punctuation, why would you expect to be able do the same in a programming language?

[T. F. M. Reader]

Re: Someone have to say it

Semicolons don't end lines, they separate statements (in Rust).

And in C/C++ that are whitespace-insensitive.

You wouldn't write English prose without using punctuation, why would you expect to be able do the same in a programming language?

I am guessing you are not one of the people who consider tweets and WhatsApp messages a natural evolution of English prose... ;-)

[fg_swe]

Re: Someone have to say it

Maybe you can put your syntactic desires on the backseat and appreciate the advanced type system of Rust. It will help you avoid or detect errors in a deterministic fashion, ideally at compile time.

Semantics is usually more important than syntax in computer science.

[Anonymous Coward]

Re: Someone have to say it

> Semantics is usually more important than syntax in computer science.

Really?

How does computer science do semantic analysis without syntax rules?

Please explain.

[fg_swe]

Re: Someone have to say it

You can have essentially identical semantics with indentation and semicolons. What matters in the case of Rust and Sappeur is not the semicolons, but type systems which assure memory safe operation and deterministic crash.

[bombastic bob]

Re: Someone have to say it

why re-invent basic syntax just tko provide additional functionality?

Python's indent-based syntax is often criticized and hated, for example.

One version of BASIC that I worked with used ':' to separate commands on the same line. I think the ';' actually dates back to Algol, then Pascal and C both adopted it because it makes sense.

[DrXym]

Re: Someone have to say it

Most lines end in a semi colon but Rust also supports return values from blocks in which case you don't use a semi-colon to signify a block value, e.g.

let x = if y > 20 { println!("y is out of bounds, {}", y); 20 } else { y };

[CrackedNoggin]

Reliable near zero latency

A language with garbage collection is much harder to use when consistently-near-zero-latency is an absolute requirement. Rust satisfies that niche. What other notable languages have satisfied that need since C and C++? Rust both satisfies that niche and addresses the inherent risks of memory leaks from not having a memory manager.

[fg_swe]

Re: Reliable near zero latency

Rust, Swift, Sappeur have heap object reference counting and memory safety.

[DrXym]

Re: Reliable near zero latency

Rust doesn't reference count anything unless the code says to do it. Instead it uses lifetime checking to insert code to delete an object from memory at the right place in time.

e.g. if I allocate something by using a Box<> and I move the box to a function that then spawns a thread moves the box to the thread's function then the compiler knows the lifetime of the box ends in the thread and will insert the dealloc / unwind code in the right place.

So basically even though I moved an object across functions & threads, the runtime cost is zero. Now I can use an Arc<> to explicitly reference count something but it's not the language but me saying to do this. I clone the Arc<> each time I want to reference count it and when the Arc is destroyed it will decrement the reference count with the last one alive deallocing the contents.

[werdsmith]

It's interesting and fun how to see how these differences of preference cause these disagreements about programming languages. Also DBMS', computer OS, cars, cameras, phone OS, TV display panels, Hi-Fi, guitars and many more. Always good for a laugh.

I've been playing with RUST, and I like it. I will be doing a lot more of it. But, I have a probably unfounded bias against using libraries with anything but their native language so I still do C/C++ and can't see myself making a switch.

Python, great for quick and dirty jobs and better at glue code than shell. Also essential for Flask which I prefer over Node, though I still need Javascript for browser based stuff.

The one unbearable abomination that should never have existed: Java. Fuck Java and fuck everything about it. What the fuck is the point of that shit? It seems to encompass every point that can be used as a criticism of any programming language and none of the good stuff. I guess its popular because its so easy to use, my cat could hold down a job as a Java programmer - which becomes yet another weakness. It's like VB in that respect.

There you go, if you are massively invested in training and experience or even emotionally one way or the other then you are going to be biased. I'm sure if I had spent a career paying my bills by scratching out Java code then I might feel differently. And the best thing about all this, I'm not even a programmer/coder/developer. I just use this stuff to enable my real work. Most coding is fairly easy and doesn't need dedicated career skillset. Obviously you need a top knob to do your critical aircraft safety stuff (Boeing may be the exception here) or to work on kernels and hardware drivers - or OpenGL and Vulkan (I've messed with shaders and stuff and I won't be doing that again). But I've contributed to space science missions and I even have some work that is due to fly soon (after about 15 years of trying).

[fg_swe]

Java Popularity

Java's key feature is Memory Safety. This enables programmers and software engineers to quickly track down most of bugs to their root cause. With C and C++, you can have very nasty and (especially in multithreaded programs) nondeterministic bugs. Very hard and very expensive to track down and fix.

Time == Money.

[Dan 55]

Re: Java Popularity

RIAA and each thread type in its own class. Practically impossible to go wrong.

[fg_swe]

Re: Java Popularity

In any useful multithreaded program, the threads need to communicate with each other. For example, they need to update a shared hash table. They must NOT accidently share variables, buffers etc.

Rust and Sappeur enforce this through the type system. Shared data structures are protected by mutexes.

[Dan 55]

Re: Java Popularity

C/C++ has POSIX mutexes and the standard library in C++ has the mutex class.

[fg_swe]

Mutexes in C and C++

I am fully aware of things like pthread_mutex, as I am using them in generated Sappeur code. But the C and the C++ compilers cannot determine whether the software developer has properly used these synchronization mechanisms. C and C++ have no means of differentiating between thread-local and thread-global data structures.

In Sappeur and Rust, you as the software engineer are forced to make this distinction and then the compilers insert synchronisation primitives as required.

There are static analyzer tools for C and C++, which attempt to do similar things, but I suspect they cannot do this in the same strict fashion.

[Dan 55]

Re: Mutexes in C and C++

C and C++ have no means of differentiating between thread-local and thread-global data structures.

C++11 has the thread_local keyword.

[fg_swe]

Re: Mutexes in C and C++

That is certainly an improvement, but it does not stop the programmer to accidentally share "normal" variables between threads.

For example, multiple threads can read and write a global variable in C and C++. Compilers will not even warn the programmer. Static analyzers *might* be able to detect and warn.

In more complex cases (object trees, handing pointers from one thread to another), these static analyzers quickly reach their limits and might not report this type of bug.

With Sappeur and Rust, global variables must be either synchronized (being protected by an internal mutex) or the compilers will emit an error. And also all other cases of "pointer passing" between threads are secured by means of the type system and its rules.

[Ignazio]

Oh mate I hope you didn't forget to put a zero at the end of that long ass comment.

Java did something C and C++ never managed, it got strings right. Never got a segfault messing with strings.

[Dan 55]

C++ doesn't have strings?

[Tom 7]

C++ has Boost.

Never managed to use it in anger but seems to have pretty much everything in it to solve the problems people like to pretend are a fault of the language.

[DrXym]

Boost is great especially if you have an older C++ lacking some of the features found in later versions of C++.The documentation is also pretty horrible though.

It's most strong for stuff that most software needs like date & time, logging, asynchronous IO, smart pointers, string algorithms, threading. There is some super esoteric stuff in Boost too which I've never had reason to use.

[fg_swe]

Multithreaded Memory Safety ?

Boost may be a powerful library, it cannot ensure that multiple threads access shared data structures in a safe way. The type system of the compiler itself must support this.

The resulting bugs of accidental sharing are in many cases impossible to track down with a debugger. All you will see are heap corruptions at random places. Valgrind/Purify won't help you with that either, as they slow down runtime to a crawl, thereby often masking the bug.

Rust and Sappeur enforce safe access of multithreaded data.

[DrXym]

C++ has a template basic_string that encapsulates string functionality at various character widths. Neither C nor C++ really give a crap what a string is, or the encoding. About the only guarantee is if you declare something like "foo" in source code, that the characters foo will be terminated with a nul char.

Rust has an intrinsic type "str". If I assign "foo" to a variable, the variable type is "str &" which is a string slice - a length and reference onto the str. There is also a type String in stdlib which is akin to basic_string in C++ if you need to modify strings.

[werdsmith]

“Oh mate” I was trying to demonstrate the idea about being biased towards where you are invested. You’re not supposed to take the Java comments seriously. For goodness sake, you just stepped in to prove my point.

Having said that, applications built in Java and deployed to do serious enterprise work always seem to be the most troublesome, and worst performing. Must be all that thread safety. And to cap it all, it’s owned by Larry.

[fg_swe]

C Memory Issues

When valgrind was first used to check the standard Unix userland tools (grep, wc, sed etc), it found plenty of memory errors. They resided in these programs for decades. From that "follows" that all Unix developers were "rookies", if you believe the C fanbois. In my opinion, it just demonstrates the limits of ANY human programmer.

I am not a big fan of Java either, but Java will immediately report an index error or a null pointer. C programs often "march on with several bullets sticking in the foot". An immediate Segfault is actually a very good thing, much better than hidden memory corruption.

Similar to the Unix tools at the time of valgrind introduction, many real-world Java log traces are full of exception traces, because the programs have not been properly developed/tested to maturity. But that is not the fault of Java, but rather the fault of the teams, managers, companies developing said Java-based systems.

What you can blame on Java itself is huge memory consumption (2x that of the equivalent Sappeur program), long startup times of the VM (Sappeur programs can start in a few milliseconds), and unpredictable delays due to GC mark+sweep runs.

[Adam Inistrator]

Re: C Memory Issues

What would it take to incorporate the memory safety of sappeur into c++?

[R: Tape Loading Error]

I was about to post a witty comment, when I was interrupted by less than urgent compulsion to empty my waste-paper basket and rubbish bin. I blame the hypnotist for missing everything, and losing those vital postit notes, but at least my boss can see a clean desk now.