DWARF supports quite a few languages: https://dwarfstd.org/languages.html
709 karma · joined February 9, 2020
First of all it’s not just an issue of maintaining the language itself, but all of the associated tooling as well. Second of all, it’s not just that Google could pull support, but that Google could choose to prioritize their own needs over the rest of the community.
And btw. Languages don't have to continuously evolve to remain viable. … If Go showed one thing, it is that PLs don't need to add as many features as possible.
Go advocates say this often enough that it’s honestly beginning to come off as an insecurity. And I would be concerned about cultivating a community around “less is more, Go should only evolve as a last resort”.
Moreover, keep in mind that the primary selling point of Go were goroutines. At the time Go was particularly well suited to exploit a gap left by other languages. Fast forward to today and Go has become a significantly less compelling option.
And just to prove that point: C is still a top rated language in terms of usage. When was it last updated?
Projects written in pure ISO C are relatively few and far between. In fact many high profile C projects are exclusively tied to one or two compilers. Furthermore, ISO C has delegated a lot of functionality to external standards like POSIX instead of giving them first class support, not to mention the plethora of nonstandard language extensions found in many compilers[0]. In other words, ISO C has stagnated, albeit C23 is a big update, while the C language has evolved.
Anyway, as I see it, golang is basically a dead end as a PL. It doesn’t interface well with other languages, it doesn’t substantially differentiate itself as a PL, any nuance you encounter with the language is likely to never be fixed, it’s a poor language for writing great libraries and/or abstractions, etc. That said, plenty of great businesses have been built on top of languages like PHP, so it can definitely work. Personally I don’t expect anything like another kubernetes coming out of the language again.
mitigations=off
The trade off between risk and performance isn’t a smooth gradient in this case. Eventually conservative behavior under a certain threshold does nothing but cost performance and waste power. Therefore, the multi-billion dollar question is where that threshold is and how closely can a design toe that line. Perhaps I am wrong, but I don’t believe Intel’s management would risk a vulnerability like Downfall for better SIMD benchmarks.
Do you believe that Intel would have sold as many chips if they’d been honest — “our products are faster than before by trading your security for speed”?
Outside of the “prosumer” market, the vast majority of retail consumers do not even look at CPU benchmarks, nor could they understand them if they did. The true target of those performance numbers is the enterprise segment, a reoccurring multi-billion dollar revenue stream for Intel. With that in mind, it makes about as much sense for Intel to ignore vulnerabilities for benchmarks as it does for a milkman to sell spoiled milk.
As for Intel it’s difficult to judge without knowing how complicit they were. The fact it took years to for a proof of concept of Downfall to surface lends some credibility to their choices. Moreover equating a security vulnerability to being outright defective is overeager, to say the least. If that were true then you might as well sue the vendor of any lock that has been successfully picked, cut, shimmed, or broken.
(Wild idea) I wonder whether NetBSD could be turned into something like device drivers or firmware?
This is actually quite common. The Qualcomm modem in your phone is very likely running QuRT, Intel ME famously runs Minix, Apple apparently uses some version of the L4 micro-kernel family in their Secure Enclave IIRC.
Well, sure, but most of the software they maintain are the relatively “trivial” parts of the system. Or rather, the software that gives me the most trouble isn’t anything they’d be maintaining.
I have long wished they would find some killer application(s) for the server sector and grow in widespread usage.
I wouldn’t hold my breath. I mean, what feature or functionality could any BSD have that would justify migrating? It would be easier to add an equivalent to Linux in virtually every case. Not to mention that many “cloud-native” projects are typically Linux-only.
I don’t really care one way or the other, it’s basically “coke vs Pepsi” as far as I’m concerned. It’s just hard to see any BSD variant challenging Linux.
Ultimately Silverblue is trying to be an “immutable” system without the need to coordinate packages and/or software. And such an approach is highly appealing for enterprise support, but the end result is somewhat of a Frankenstein system. Of course Nix is not without its warts, I can’t stand its language and documentation is terrible.
Overall I find Guix to be my favorite of the bunch. It’s legitimately a wonderful tool to develop with, I agree with the emphasis of reproducibility and bootstrapping, Guile is a wonderful language for configs/scripts, and it comes with a great manual. Even still, I couldn’t recommend GuixSD due to the lack of systemd and the hardline approach to free software (libre Linux).
If someone buys real estate with some expectation of ROI, then why should they be shielded from risk?
If by "understand" you mean "have a passing familiarity with" then.. sure, but if you mean "my understanding is reflective of reality" then there's absolutely no way.
We, people who really understand the technology that the world runs on, are a slowly dying breed.
There are more people doing "low level" programming right now than were doing it a few decades ago. The only knowledge that is fading is knowledge that's applicable to legacy and/or retro systems.
Honestly I feel like the F35 is a target in the “information warfare” space. While the project is not above criticism, China/Russia/etc have every reason to promote animosity towards the project.
It is reasonable to write a naive C compiler alternative with few resources… and totally insane, at a pathological level, for a naive c++ compiler alternative.
Sure, but why should I, as a language end user, care about implementation difficulty? The fact that C prioritizes implementation simplicity over users is a grave sin, especially when in practice the vast majority of C programmers are using a vendor with substantial resources.
Also, if C is so easy to implement, then it shouldn’t matter what Clang, GCC, ICC, MSVC, NVCC, IBM XL, etc, are implemented in, right? Just roll your own C compiler and bootstrap from that.
The less worse compromise, for now.
Languages are more than syntax.
If you cannot understand why many prefer to avoid using such language for those very reasons,…
I’m not saying anyone must like C++, nor is it any mystery why many do not. Now, if you can’t understand why many people choose C++, including the GCC developers, then I suggest you charitably evaluate their claims for doing so.
…I am very sorry, I cannot do much more.
Quite patronizing of you, but par for the course as far as Cnile rhetoric goes. Just know this, C may outlive us all but C++ will outlive C.
If projects like Linux stuck to plain and simple C then it wouldn’t even matter what GCC was written in. The fact that Linux doesn’t even try to do so, and that it is hardly unique in that choice, suggests that maybe “plain and simple C” is not so practical.
…the cure is worse than the disease. c++ is not a sane language, … it is NEVER the solution. I think it should not be taught anymore as its syntax complexity is toxic for mind sanity.
I’ll never understand the withering criticism of C++ on the part of C programmers and/or C aficionados. For instance, suppose we take everything you say about C++ as true, then what does that say about C? Virtually anywhere C++ is used C could be used as well, and every line of C++ represents a choice to not write C. In other words the insanity of C++ is seen by many smart and serious people as better than C, including by the stewards of every major C compiler today. Ultimately knocking down C++ to build up C does nothing but make the C community look like dilettantes trying to convince themselves more than anyone else.
The truth, as bitter as it may be, is that C++ genuinely scales and composes better than C. And C programmers know it too, at least on some level.
Rust was more inspired to be a memory safe, C++ like language, with a better syntax and type system. It’s far more targeted towards application programming than anything else, although it’s looking better and better for embedded as well. Although it can probably be used for safety critical applications in the future, it’ll need better tooling before that can happen.
Anyway, the primary issue with Ada/SPARK in the (F)OSS ecosystem is primarily due to the lack of available compilers IMO. On top of that it has a reputation as a somewhat “dead” language and, as silly as it is, many people can’t bring themselves to look past the pascal style syntax. That said, Ada/SPARK is not the only game in town. JML exists for Java, Frama-C and Astrée can basically offer equivalent functionality, and I’m sure others exist (ployspace code prover?). So you might as well ask “why Ada/SPARK?”.
Why does our industry get so enthused with shiny new things, repetitively?
Personally I believe that Rust appeals to many who have historically avoided native development because C and C++ are just such a bother to deal with. It’s hard to imagine Rust being where it is today without cargo. Now, with security only becoming more of a serious problem, Rust is becoming more compelling for some users.
AFAIK mainline Linux currently has a minimum compiler requirement of GCC5.1, but even then the only reason for that version bump was to avoid compiler bugs in earlier versions. With a bit of patching and a restricted set of architectures it might be possible to continue using GCC4.7 for mainline Linux.
All that would not to be required if gcc was till a clean simple and plain C project,…
It cuts both ways. Linux and any other C project could avoid this if they remained compatible with tinycc, GCC4.7, or any other pure C compilers. Apparently such an expectation is out of the question, I suppose asm goto and friends are too appealing.
…moving gcc to c++ was probably one of the worst mistake in open source software history, if not the worst.
The decision to move GCC to C++98 was not taken lightly, nor was it done without opposition. I would recommend reading into the discussions on the topic. Moreover, I would also recommend browsing the source code of GCC4.7 and comparing it to later versions to see how much the transition genuinely simplified a lot of the codebase, e.g. the large scale replacement of preprocessor abuse.
At the end of the day, although it adds another step to the bootstrapping process it needed to be done to keep GCC development manageable.
Marketing is not a silver bullet for success and the tech industry is full of examples of exactly that. The truth is that Sun was able to promote Java so heavily because it was found to be useful.
Since the advent of Java in mid-90s I hear about superiority of its VM, yet my observations from the ops PoV claim otherwise.
The landscape of the 90s certainly made a VM language appealing. And compared to the options of that day it's hardly any wonder.
So I suspect a huge hoax...
It's you verses a plurality, if not majority, of the entire enterprise software market. Of course that's not to say that Java doesn't have problems or that the JVM is perfect, but is it so hard to believe that Java got something right? Is it honestly more believable that everyone else is caught up in a collective delusion?
Hey btw, you're saying "Java is _memory intensive_", like it would magically explain everything.
It's not that Java is necessarily memory intensive, but that a lot of Java performance tuning is focused towards optimizing throughput performance, not memory utilization. Cleaning out a large heap occasionally is in general better than cleaning out a smaller one more frequently.
By the way, if the code implementing functionality X needs N times more memory than the other language with gc, then however advanced that gc would be (need to find a proof for that btw), it wouldn't catch up speedwise, because it simply needs to move around more. So simple
It's not so simple. First of all, the choice of a large heap is not mandated by Java, it's a trade off that developers are making. Second of all, GC performance issues only manifest when code is generating a lot of garbage, and believe it or not, Java can be written to vastly minimize the garbage produced. And last of all, Java GCs like Shenandoah have a max GC pause time of less than 1ms for heaps up to 16TiB.
Anyway, at the end of the day no one is going to take Go away from you. Personally I don't have a horse in this race. That said, the fact is that Java GCs are far more configurable, sophisticated, and advanced than anything Go has (and likely ever will). IMO, Go came at a point in time where there was a niche to exploit, but that niche is shrinking.