'I am done with open source': Developer of Rust Actix web framework quits, appoints new maintainer The maintainer of the Actix web framework, written in Rust, has quit the project after complaining of a toxic web community - although over 100 Actix users have since signed a letter of support for him. Actix Web was developed by Nikolay Kim, who is also a senior software engineer at Microsoft, though the Actix project is not …
Be[ing] a maintainer of large open source project is not a fun task. You['re] alway[s] face[d] with rude[ness] and hate, everyone knows better how to build software…
This could apply to any software project. The key is always communicating clearly and setting reasonable expectations. If your project is successful and popular you will attract the slugs, the uses who want it to do everything for them but aren't prepared to contribute. Be prepared to write "design defence" documentation to defend your decisions and be firm but fair. At the end of the day, you decide what gets accepted and what gets rejected. Some people will never accept this: get over it, because there are fuckwits all over the place, but don't get dragged into their discussions. As I think Mark Twain said: don't argue with an idiot, they'll drag you down to their level and win.
But, one of the great things about open source, be prepared to walk away and let someone else take over. Software development and review takes time and energy which we don't always have as much as we'd like. Our lives and priorities change.
Are you serious?
People publish Open Source software because they're hobbyists who think others might find their work useful. They owe anyone else absolutely nothing! Others are totally free to not use their software.
Who in their right mind would spend a weekend writing a 'design defence' document? Crazy.
Actually you're both right, depending on the motive.
It's certainly legitimate for someone to apathetically dump the end result of their personal itch-scratching exercise into the public domain, in a half-baked act of philanthropy. I'm sure that is how at least some open source projects begin life. In such cases, expecting the original author to spend days carefully crafting policy documents is not very realistic.
However, it's far more common for open source to begin for more pragmatic reasons, where the license is chosen specifically to encourage community contributions, to distribute the workload among many, in terms of both developer contributions and public scrutiny. In such cases, the community surrounding that project is certainly no peanut gallery, and you absolutely need to listen to what they're telling you, assuming you wish to continue receiving their contributions, that is.
In this case, it seems that Kim started out as one of the latter, then ended up as one of the former.
It happens. Many open source projects see a lot of leadership changes due to irresolvable conflicts of interests, where tempers fray and people storm out. Exactly the same thing happens with proprietary software development too, of course, except behind closed doors, so we rarely get to hear the details.
Whether or not there's any benefit to seeing developers air their dirty laundry in public is debatable, but it's certainly entertaining.
People publish Open Source software because they're hobbyists who think others might find their work useful.
I am serious and I do run a reasonably popular open source project. Communicating clearly why your library works they way it does means you don't have to continually explain and justify it.
Not taking any shit from your users does not mean you have to treat them like shit. See the Mark Twain comment as to why this is important. The vast majority of users will be happy with what you have but some may well take the time to make worthwhile suggestions or submit patches / pull requests. The trolls are best just ignored (or banned).
"People publish Open Source software because they're hobbyists who think others might find their work useful."
Although I am certain that there are many people who fall into this particular category, you are being QUITE arrogant if you make the assumption that ONLY "hobbyists" publish open source.
I had someone say "hobby" with respect to a serious hardware project I had designed for my own company. I considered that to be BOTH condescending AND arrogant. Well, *THAT* guy's contract ended early, for a number of reasons, in a major project we were both involved in. He was one of those "UX" designers who "worked" by slapping canned packages together, writing sloppy code that barely worked, and calling it "a user interface". Oh, wait, that's "User eXperience". *facepalm* (he couldn't meet design deadilnes, even acted out and deliberately interfered with getting things done - last I heard, he applied to work for the EPA, suits him perfectly I guess)
yeah, _I_ took over his duties, and actually made the thing work, cursing his name and choices for MONTHS... [customers happy with it though]
Hmm, the super hero pattern.
We have someone like you on the project I'm on atm. Could help us deliver but prefers to let us deliver wrong so they can point out how much better they are than us.
Not particularly useful but no doubt they have a history of "successful" projects like you do.....
I like to work on a team.
Can we please finish the "open source is written by hobbyists" myth?
Yes, hobbyists CAN contribute and some do. However most open source contributions are made by professionals in the course of their work, and even most of the volunteer contributors are professionals either helping something they want to support or publishing code to help them find work (the two are not mutually exclusive, of course).
Outside some Linux desktop stuff (mostly KDE) I find it hard to think of any open source stuff I use (and almost everything I use is open source) that is primarily developed by hobbyists.
I think you'll find that virtually all of the core *nix utilities were/are developed by hobbyists and/or students. Likewise most of the core Internet software. To say nothing of GCC and the rest of the toolchain. Etc, etc., etc.
Your so-called "professionally built" system wouldn't even boot without the time and effort put in by thousands of hobbyists over the last 50+ years.
Be prepared to write "design defence" documentation to defend your decisions
Or perhaps start out by having at least an initial plan, what's in scope, what you envisage the structure to be, the rationale behind this and document that. The document can evolve. Anyone who wants to change scope etc gets invited to explain how and why they think this could/should happen.
> This could apply to any software project.
I suppose it could, but I've been in this industry for 30 years or so, and I've rarely encountered this sort of problem outside of the OSS community, and even there, it's only become a real issue over the last 10 years or so.
And it's only become a problem because a few entitled induhviduals have been fed a bill of goods and think that "every child is a winner" so all their contributions simply MUST be valid. Mummy said so!
During the meanwhile, in this particular case the adults in the audience are yawning. Or pointing & giggling, depending on how many glasses of Recovery they've managed.
Well, your experience is not like mine. I've seen exactly this in many closed source projects. People want the project to do what it does with a completely different interface. They're willing to commit a readme that lays out that interface if I could just fill in the gaps. Or they'd like their project and my project to merge because our functionality compliments one another. They'd be happy to modify the code to do that as long as I deal with all the bugs because they haven't read the code to my project before making the suggestion. Some times, these people are making constructive suggestions and my team should consider what they're asking for. Sometimes, they are very skilled and dedicated and they'll be valuable assets to our team; at least one person I respect quite a bit joined us in that very manner. Sometimes they have no clue what they're talking about and should be ignored, and if we didn't figure out this we'll be cleaning up after the disaster for quite a while.
When project deadlines are squeezed in the constant race to the bottom, documentation quality is usually the first to go, just enough to tick boxes to say it's been done. Then later on everyone's utterly surprised when nobody knows how anything works as the original people are unavailable (they're busy having the same problem with other projects or have been fired).
"The key is always communicating clearly and setting reasonable expectations."
Amazed that no one has mentioned Python and Guido van Rossum. Even when you do everything right, the wrongheadedness wears you down. After one more fraught PEP which should not have been so bone wearying painful, Guido took off the BFDL hat. After 28+ years of doing right by people.
"If your project is successful and popular you will attract the slugs, the uses who want it to do everything for them but aren't prepared to contribute."
well said!
Also a corollary of that: don't try to make your project do TOO much or it will bloat into an uncontrollable mass of feature creep. If the 85/15 rule applies, let's say 15% of the effort going into 85% of the functionality, and the rest of the functionality (15%) taking up 85% of the time and/or amount of code to support it.
Contrast this to the UNIX principle of "do one thing, well".
So at some point, all of that extra functionality should become add-ons and not built-ins. Then when the slugs complain about "no feature" you can say "write a plugin, contribute it, and then it will do what you want". So simple!
then again, if you do like Firefox and CHANGE THE API such that the old plugins break...
That is indeed true.
It is also true that writing RIST code is not easy. It is very hard indeed, and requires taking a step back from what we normally consider the way to do things in languages like C, C++, C# or Fortran. In RUST memory has to be treated with respect. By comparison, if you treat memory with respect and code to RUST's exacting standards, the compiler will created and guarantee memory and thread safe code for you.
But if you start saying that this is just too hard, or too slow, and that you know best, you can quite easily create UNSAFE code that basically tells the compiler you know best. Sometimes you have to do this, for example when interfacing to raw block structured devices. You have to map the memory array in to a RUST structure and yes, you do know best.
But if you do this in application code, you are building a product that breaks the contract. Users will take your library and rely on it, because, well, it's written in RUST, so if it compiles, it will be 'safe' (for what the RUST compiler thinks is safe). But if it turns out that its not thread safe, or it doesn't play nicely with dandling pointers, etc. you are leading the users up the garden path.
So, a better approach would have been for those people who wanted a RUST safe version of Actix to fork the project, correct what they perceive as coding errors , and benefit the whole community.
To be fair, memory has to be treated with respect in all languages. Rust in safe mode simply doesn’t give you the choice. I’ve often thought that “safe and unbuggerable” code in languages such as C, C++, even C# depends heavily on people assuming that “no one would ever do that, would they?”!
It does indeed seem slightly odd to be using Rust in an unsafe way for something that many would indeed assume was inherently “safe”. Caveat Emptor and all that, but my first reaction to the headline was “oh goodie, something good written in Rust!”, dashed to some extent by the details :(
The thing I like about Rust is it's safe by default and if you do need to do potentially dodgy stuff then you must enclose it in an unsafe block. You can simply search and find it with ease. I realise actix has gotten flak for some unsafe blocks but I see the fact that people could even see and review them as a feature not a bug.
> The episode demonstrates that expert developers are often not expert in managing the human relations aspect of projects that can become significant.
Prior to leaving the codeface for a seat by the fire, the last place I worked was developing the concept of a Project Lead and a Technical Lead who would work in tandem. The former would arrange meetings, record notes, was the keeper of the project schedule, communicated with the user community and with management, and handled the myriad of complexities that surround a project. The latter was the architect, designer, editor-in-chief for the myriad of complexities that are the project.
> a Project Lead and a Technical Lead
It's close to the current organisation in my team: our manager is doing the Project Lead, with very little technical work, since her technical skills are not applicable for the current project. But the role of Technical lead is distributed among the developers, each having their area of expertise, plus a part-time architect.
That depends very much on the size of the project and the type of contributors. Something the size of the Linux core or Actix is very much in need of someone keeping things in line, because some people WILL bugger things up with the best of intentions if left to their own devices.
It's difficult to get most beancounters to understand their optimal role, and even more difficult to get them to do it.
You see, it takes time for compost to release the nutrients to the soil. Particularly if it's through a thick carpet....
That said, their intermediary use of high dielectric insulation for cattleprod calibration they generally understand fairly rapidly.
Giving low-skilled overhead to those technical leads sounds like overspending to me. Sounds like your accountants are idiots which think there are an infinite number of hours in the day.
My employer hires low-skilled employees for the project lead jobs, saves them significantly in $/hour.
It's a good idea: each job has it's own skillset, and finding a person that can fill both competently massively narrows the application pool (And with your manager hat on if you're in that position, may not be cost effective, as the savings of one larger salary over two is trumped by the body count going up).
Back in the good old days when we used to ship shrinkwrap software on physical media, 3 1/2 floppy disks, we used to have this guy in the dev team called the Project Manager. They did exactly what you outlined. You had the Tech Lead / Architect (usually me) with a bunch of Senior and Junior programmers. Then we had the Project Manager who took care of all the organizations stuff for the dev project apart from direct code related stuff.. Such as dealing with the UI and Art Assets depts. And getting the final product physically produced. Then we had a Product Manager who took take of the business end. Marketing / sales / docs / support stuff. Then we had a QA Lead who took care of getting our product through QA. We always had a docs person who came on board near the end. Remember documentation. Not just a bunch of badly structured web pages but a proper manual. Written by people who could actually write clear lucid technical prose.
I have nt seen a real product dev group like than for quite a few years now. I have seen a whole bunch of dev teams who claim to be "Agile". Which in my experience means none of us know how to design or architect non-trivial code and none of us know how to manage a dev team. And none of us know how to ship code that is stable and feature complete.
Which is why your installed applications now try to continuously update. Because none of the dev teams know how to write stable clean code hence all the regular bug fixes. Of trying to complete feature that were only partially implemented before being released.
Nope. Not NHS. Just pretty much ever successful US PC software company back in the 1980's and 1990's. I saw inside pretty much all of them on the West Coast at some stage or another.
Once annual revenue went above $10M or so that's how they organized product development. Actually having to produce physical product and the cost of the initial dup run being several $100'ks just to get product into the distribution channels imposed a lot of discipline on the process. Cost of fixing a crash on startup on certain hardware configs after product went to Golden Master and you had to do a recall ran to a largish six figure sum. And unlike dot coms, these companies were actually trying to make a profitable business out of selling product to end users. Not just some financial engineering scam.
I'm going to try and post this without giving too much away but around 10 years ago I worked with someone who developed an ecommerce platform. This was when Magento was still fully open source (before Adobe purchased it) and essentially his system was a rival to it.
I remember reading his rants online at people who were criticising his work and essentially telling him it was shit compared to Magento (which is saying something because at that time Magento really was quite shit).
For me it was a very double-edged sword. He had put considerable amount of time and effort into doing something he loved. Nobody really thanked him for it. The platform still exists and has done reasonably well, and kept open source. Some online retailers use it and make decent turnover through it. Meanwhile Magento was purchased by Adobe for £shit-loads and isn't open source**. But on the other hand, his responses and inability to take criticism were, in my opinion, a massive failure in terms of why he didn't succeeed as well as he might have done otherwise.
In summary I both feel sorry, yet have little sympathy, for people in this situation. It's hard to know where the line is.
They're doing something positive but their lack of people skills (Linus being a classic example of someone who many people consider an arsehole even though he's done plenty of "good") is the real problem.
** Well there is an open source version but nobody really cares about it. The one people are using isn't open source.
Large swaths of the open source community have become intolerable. It's why I stopped actively participating in the OSS community a few years back -- it's just not worth the trouble.
I release most of my software into the public domain these days, but I do still release some software under OSS licenses. However, none of them are community-driven. I offer them on a take-it-or-leave-it basis.
There used to be. Perhaps there isn't anymore. In any case, this behavior has become very common across projects -- so much so that it's why I've essentially left the wider OSS community (if such a thing exists) and no longer participate in OSS projects that aren't mine.
yeah this "community" thing usually gets conceived as something *really* *nauseating*, all "touchy feely" and "we all just get along", which is the EXACT opposite of STARK REALITY.
A "community" (read: small group) of contributors who submit patches and occasional features is fine, but SOMEONE has to have the gonads to say YES or NO to all of that. Because, we do NOT all "just get along". There are agendas and personal vendettas and crusades and "i want this feature dammit" and so on... and *WAY* too much *FEEL*.
maybe this is why what the CUSTOMERS (i.e. end-users) want has become such a LOW priority these days... you know, like with major ball-busting changes like Australis, Gnome 3's UI, 2D FLATSO, removal of user customization, EVERYTHING looks like Chrome and CHROME LOOKS LIKE CRAP (all bright blue on blinding white), et cetera, et cetera, et cetera...
>"if something costs nothing, it has no value.
Open source isn't about being free at the point of use..."
That is a good point.
Years back (pre-www) you had to pay someone real money (ie. more than the cost of the media + p&p) to get your hands on a CD of open source code which you were expected to compile.
Now it seems everyone thinks that a ready-to-run distro is open source and should therefore be free, likewise the automatic updates.
Yes, I know about the marketing considerations and technology advances that have influenced the decision, but it is clear we have become accustomed to an unsustainable state-of-affairs. It would be interesting to see what the market reaction would be to an open source product (distro or application) that came with usage limitations (eg. 30 days limited trial, updates disabled etc.) that could be unlocked for a subscription... Wouldn't be surprised if MS are or have seriously looking at this possibility.
"Years back (pre-www) you had to pay someone real money (ie. more than the cost of the media + p&p) to get your hands on a CD of open source code which you were expected to compile."
Your version of history doesn't match mine.
We sent out early 1BSD tapes (1978), at no cost, to anybody who asked. Granted, not many people asked ... but there was no money exchanged. This got spendy, especially on a grad student's budget, so with 2BSD (?? late 1BSD? My mind is concatinating time again ...) we required them to send us the media and a postage paid return envelope. Soon after this, it was available via anonymous FTP from all the usual places. Again, no money exchanged hands.
IBM, DEC, et alia freely shipped the system source along with the hardware as a matter of course until the likes of Steve Jobs and Bill Gates discovered that leasing/renting software was more lucrative than including it with the hardware.
Your knowledge of Unix history predates mine :)
When I encountered Unix (mid-1980's), the tapes were no longer being sent out for free.
Thus I was referring to the period - circa mid-80's to mid-90's - when CD's were the distribution media of choice for various 386/PC Unix distributions and then Linux, and companies such as Walnut Creek were burning CD's of Unix/Minix source code and Linux distro's such as Yggdrasil. I seem to remember they charged a "rip-off" price of £5~10 per CD(circa £15 to £30 in today's money).
Yes, if you could afford a network connection (pre-Unipalm/Pipex days in the UK) then I agree anonymous FTP was the way to go. Mind you back in 1988, we regularly downloaded updated versions of Sun's complete OSI stack (including FTAM and X.400/MHS) as an SMTP attachment over whatever passed as 'fast' (for normal people) in those days.
Yes, there was quite the little industry building & selling CD "collections" of freely available porn source and binaries. I sometimes forget about that, though ... I had access to the early Internet before it was TCP/IP, and had a server under Bryant Avenue in Palo Alto connected to Stanford via 56K (officially for access to the DECUS archives), and later in the mid-80s T1 into BARRNet and the NSFNet beyond.
archive.org has a bunch of the Walnut Creek & etc. ISOs available online.
"I stopped giving away software some time ago."
Funny you say this, I used to give my photos away to artists and anyone who asked but it was too much trouble. Initially it was hard to stop doing that and start charging money for them but since I decided to stop giving stuff away and charge people it's been much easier and less stressful. The more you give away the more people seem to want from you and whatever you give is never enough and they want more, they think just 'cos you give something away for free they have a every right to criticise you and the product, whatever it is. Paying customers don't pay until they're sure and 'cos they only pay out when they're sure they almost never complain afterwards.
I hate thinking like this and it goes against my better nature but sadly human nature has taught me that a lot of the time it's simply not worth giving anything away for free that you've created, people rarely appreciate it and a lot of people just want more.
"Large swaths of the open source community have become intolerable"
This is why you need a project manager with a heavy hand that isn't afraid to say "no", or even "NO!" or "*HELL NO*!!!", as well as enforcing coding style consistency, and putting certain kinds of pull requests permanently on the shelf.
Someone like Linus, let's say. .. WITH the profanity and unafraid to insult people. [I particularly like his comments regarding 'compiler masturbation' by which he meant using "new, shiny" features simply because they were there, not because they were better or easier to maintain - which in the cases he pointed out, were NOT]
Fair enough,
Open-source often means very large user-bases. Large user-bases aren't for everyone.
Its often a bit awkward, but sometimes an open-source project can outgrow its original developer. Especially if they are a little bit old fashioned. It happened to me but frankly I am very glad the community took it over rather than the whole thing die.
Boo hoo... baby got an owweee. Look. The nastiness everyone could do without. But PURPOSELY deleting bugs? Yeah, that would get my boot up side your backside.
Ignoring peoples issues? Simply having a list of bugs to be fixed and their order would address that.
Simple stuff here, so it's probably a good idea for someone with thicker skin to take on the job.
"Rust is safe by default, but the language also supports unsafe code, which can be useful for interoperability or to improve performance."
If Rust is supposed to be a systems programming language and a replacement for C/C++ then unsafe code is a must since you can't talk to I/O ports or device memory directly if everything is in a sandbox. The reason for unsafe code isn't really the ones given abou, its because if Rust is to live up to its design ideals (it won't IMO, C/C++ has way too much traction) then it has no choice and any Rust developers bitching about it clearly don't understand what systems programming is all about and are probably just Kool Kid Webdevs trying out the latest fad language.
FWIW you still have to obey Rust's borrower rules in unsafe code. You also wrap unsafe { } around unsafe code so you can find and audit it easier - whereas with C/C++ any old pointer could be wild.
Unsafe IO port access on Rust looks like this:
unsafe { *(0x10000000 as *mut u8) = c };
..for writing a character to a serial port at 0x10000000, say.
I've done a fair amount of low-level Rust dev in my spare time and it's helped me write much better code, so much so, I am terrified about the thousands of lines of C I've previously written.
I'm not on the Kool Aid, though. It's frustrating that a lot of the ecosystem uses the standard (std) library, which is unavailable on bare metal. Thus, you may find a third-party library that will save you reinventing the wheel, only to find it's reliant on std and you can't use it.
C.
The Rust standard library isn't available on bare metal? Huh? Even the C std library is. Yes, you usually have to tell the compiler to bundle it into your executable directly (take a copy of the needed parts), but Rust doesn't have this capability yet? If not, smack the compiler maintainers. This is not particularly difficult to do with an "--embedded" or "--baremetal" flag honestly. You can implement the threading constructs in your executable if you're using parallel algorithms and thread-safe concurrent data structures.
For bare metal, you can use what's called the core library, and a few others, that provide primitives and basic structures. There's no IO nor heap allocator: you have to implement that yourself.
If you pull in a third-party library that expects to use std library primitives, you're out of luck in a core-only environment. It's not the end of the world: not all libraries require std. Ones labeled nostd will work with core.
std expects there to be an OS underneath providing stuff like heap allocation and IO. With bare metal, there is no OS. You are the OS. Core doesn't require an OS. Core expects you to provide things like the heap allocator.
So, with core, you're not totally on your own, you get some support, you just can't use dependencies that require std, and you have to provide stuff like memory management.
Compare std: https://doc.rust-lang.org/std/
to core: https://doc.rust-lang.org/core/
Core gives you a lot, along with common data structures in the alloc library, but not all of std.
C.
"whereas with C/C++ any old pointer could be wild."
Not when you write the code properly. An experienced kernel programmer would know this.
(if you're talking new college grads first time trying their hand at coding, that's completely different, but when you've been coding longer than those people have been ALIVE... *NO* need to limit things or over-generalize the 'paranoid case' just because SOME people just aren't competent enough)
Yeah. And all code is written properly of course. Even experienced kernel programmers make mistakes.
Something I learnt long ago: Given 2 code solutions to a problem, people in general pick the worse one either to use or to (shudder) clone and mangle.
"And all code is written properly of course."
Oh, but real programmers write bullet-proof code - didn't you know this?
And, heaven forbid that we let college grads write code that actually goes into production, just in case they develop this "experience" thing, come up with new ways of solving problems and put all the ageing code hacks who are too stuck in their ways to accept change out of a job...
But what is "safe code"?
Thread safety has been mentioned, however, unless I've missed something over the decades, writing code that is safe with respect to re-entrancy and accessing the same data structures/memory and other fun and games of parallel and multi-threaded execution, still requires the programmer to have the ability to write "safe code".
Another aspect, is that "safe code" is really only with respect to the module being compiled, You have to trust all other code executing within the runtime environment is also safe. I wonder if this is part of the complaint being made about RUST, namely, it doesn't go far enough in supporting runtime trust, ie. I should be able to set an OS parameter, so that anything running in 'user space' or outside of the OS rings has to be flagged as "safe code".
>C/C++ has way too much traction
'C' os an example of what used to be called a Systems Programming Language. Its essentially an overgrown macro assember. Systems languges were intended for operating system and tools writers, not applications developers, they only found their way into applications because of the shortage of better tools during the early PC years. These languages don't need support libraries although most people will see them with a couple of entities that make them useful for scratch program writing, these being the crt0 environment setup for the initial call and some kind of input/output package and processor instruction replacement package for data types the processor doesn't support directly. Because of the level of control they give you over the environment they're really easy to abuse -- its why they're regarded as 'unsafe' (but then you've got to write the safety mechansms in something!).
'C' got into the applications business because there wasn't a lot of other compiler support for early PCs. It wasn't suitable for the job -- writing GUI applications in 'C' is a nightmare -- but unfortuantely the extension that gave improved scoping and structure support (C++) turned out to be particularly suited to the needs of GUI programming. Since a GUI became the first and most common environment people were exposed to it became de-facto way of writing all software. Ironically event-driven programming (GUI) technique was originally a kludge to give the effect of having an operating system on a system too small to actually host one. It worked but to do anything more than support a stack of windows and one or two simple timers required all sorts of new kludges and workarounds. And so modern software was born......
Whilst I agree AC was overgeneralising, the main thrust of their point is correct; C is a powerful macro assembly language.
Back in the mid-80's Unix became massively popular, especially with Universities so many graduates had Unix and C skills. Fortran, Cobol etc. were seen as 'dated''. Add into this mix the desire/need to develop serious programmes for the new microcomputer/PC platforms ie. requiring something other than Basic or Pascal. Hence why the company I worked with ported their programmer's workbench from Unix to the PC; becoming the first C language development environment on the PC for the PC.
However, all of these were difficult for the new generation of largely self-taught programmers, hence why we had Turbo-Pascal, VBasic, Delphi etc.
>You worked for Mark Williams Company in Chicago?
No, although I did come across Coherent. Being a bit sloppy, forgetting the attempts to get people to run things other than MS-DOS on their PC's... :)
The product I was referring to was reviewed by Dick Pountain in Byte magazine Vol.10 Issue 12 p419
It was also reviewed in the Jan'86 edition of PCW, but the PCW archive doesn't go that far back.
I wasn't talking about Coherent, I was talking about Mark Williams C ... most people know about the version that ran on the Atari ST, but they did an MS-DOS version, too. It was one of my go-to tools ... The thing was fully K&R compatible, and was fast, small and tight, being entirely hand coded in assembler. You could develop and compile tools for UNIX and the Atari-ST using the DOS version.
You could fit (and use!) the whole system, including compiler, assembler, linker, libraries, source debugger, decent screen editor (MS-DOS version of MicroEMACS hacked into an early version of an IDE), crude source code control, etc. on a single, DOS-bootable 1.44 Meg floppy. Here's a link to it's little brother "Let's C", with some blurb.
I remember reading that article in Byte, and in fact I bought a copy of Living C-Personal based on it. Still have it, in fact. I honestly don't remember ever using it in anger, though ... MWC did the job for me when I needed down & dirty C on DOS ... otherwise I was hacking BSD with pcc, as Gawd/ess intended :-)
Sorry now you have spelt it out, I do remember Mark Williams C, but didn't get a copy and so use it.
I forget which compiler was ultimately used for the released version of Living-C as at various times we used: Aztec C, Lattice C, Digital Research C and then MS C 3.0.
One of the discussions (the conclusion to which was superseded by events) was whether we should build our own assembler, linker, libraries etc. or provide the means for Living C to drive third-party tools...
Personally, Living C-Personal, was (and still is) a really great tool in which to learn the C language and test the logic of a module (we used it to build Living C), because you were working consistently at the C language level. The only other tool that I'm aware of which had the same level of user working was Micro Focus's Animator for Cobol (which predates Living C...).
there are many reasons I do not use the Rust language, low-level code efficiency being one of the big ones.
I don't much like their model for threading either. I'd must rather hand-tweek my own algorithms based on the understanding of the system they run on, Then you can decide whether the overhead of a job queue is worth the performance benefits of spawning multiple threads, from the total number of simultaneous jobs you can run [based on the total # of CPU cores available], to the nature of the threads themselves (do they have I/O wait states or in any way lock global objects or cause priority inversion) and so forth.
And when you've been coding long enough, you can use pointers SAFELY. It becomes SAFE CODE because you WROTE IT to BE SAFE.
There's really no substitute for proper design and techniques, ESPECIALLY _NOT_ some "new, shiny" language that pretends there IS...
my language of preference: C, or C++ when the need arises. It usually doesn't. And good C++ code looks very much like good C code.
A lot is made about Rust being 'automatically safe'. This is a massive lie. Maybe it does offer the same kind of memory safety that modern C++ offers, but it will not protect you against corrupting data by an unintended write/truncate or logic errors. The compiler has no clue what the code should be doing, after all.
This is where the Steelman requirements that underlie for example the Ada programming language offer a lot of insight in what makes a good language. Preventing logic errors and kin is done through reducing the complexity of the language (fewer ways one can write similar code), by making the code easy to read and understand (Ada doesn't use a lot of abstract symbols, but prefers plain English) and requiring explicit types, not allowing for any kind of inference, as Rust happily does. Oh, and contract-based programming is really useful, as offered by Ada/SPARK and Ada 2012.
Toss this current drama on the pile with the other 'Rust is used by people who do not understand programming languages' items, I guess.
Sounds like a case of:
"I wrote the code, stop asking me to do it properly".
In this day and age, when given a language like Rust that actually works hard to make code safer, you'd think that a developer of a web framework would work hard to ensure the safety of this code.
Ditch the performance and interoperability. Thats a problem for others to sort, such as fixing their browsers to work in a more interoperable way and do we really worry about performance now? We are spoilt with huge amounts of memory and processors with 64 cores. I remember the "breaking of the 1GHz barrier" being a big thing, on a single core machine which MIGHT have 1GB of RAM.
Security is everything when concerning the web these days and if this developer was acting in this caviler way regarding using the features of Rust to provide what should have been a good attempt of bringing a secure development platform to the web then I say bye bye and good luck to him. Your users were demanding something that basically was common sense these days, you had a chance to create a platform that developers would flock to knowing that its secure and hardened but instead you seem to have got in a sulk about an entire community because they demanded you stop taking shortcuts.
Thats the thing about Free Software and Open Source. Other people can see your code and change it for the better. The communities tend to try and keep things centralised, although they dont need to and in many cases they didnt, creating a fork. Here they were telling you what the problems are. Perhaps they were wrong, Linus frequently find many who are, but here they seem to all be saying the same thing and have a point. So instead of telling them to create a fork, that would likely be better, more secure than you version, you decide to call the community toxic and quit.
Perhaps your code was toxic. Of you go now. Give the keys to the person taking over from you, maybe they will sort out the mess.
"Security is everything when concerning the web these days"
I think I see your misunderstanding ... "The Web" is not today, never has been, and never will be secure. In fact, the Internet itself is not secure and cannot be made secure without a complete, ground-up re-write. Anybody who thinks otherwise is deluded.
Oh dear, indeed.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
