I'm currently facing this issue. I've resorted to implementing my own execution environment albeit limited.
It goes like this:
- bash script parser + interpreter (with hooks for things like file open, execute etc.,)
- wasm executor for execution.
- wasm implementations of common tools like coreutils, grep, sed etc., from the uutils project.
- wasm implementation of python by a VMware backed project.
- entirely virtualized filesystem using Go's io/fs.FS. (tmp dirs can be implemented using any backend)
Works like a charm for the limited usecase I have. There are definitely some drawbacks with threading and especially with preopens in wasm. But a cheap sandbox for simple file explorations and minimal computations.
What? I feel go has one of the best language tooling out there without requiring a bully ide to do stuff. golangci-lint is quite comprehensive. What do you miss otherwise?
(Honestly go's distributing itself has covered a lot of it)
golangci-lint is good, but you have to glue together a bunch of linters, and it adds up. You can easily get runtimes of several minutes, there are caches etc but the main problem is that golangci-lint doesn't own the lints, so it will never be as fast as something like Ruff.
I use it purely as a search engine. It is pretty good at dehtml/dejs/decss or a distraction free access to articles / docs. I had dabbled with claude for purely writing testcases which I'm very lazy at.
But man, people really oversell LLM's coding capabilities. It is good at pattern matching and replicating elsewhere. That's about it.
I had asked a simple question to opus 4.5.
> Python redis asyncio sample code.
The 3 attempts at generation all failed at the import statement. I verified if such an import structure ever existed in older versions. Never.
But it looked convincing enough though!?
Is it because there is not much asyncio code (2014) is available for claude to train on?
It was competing with C and Java when it came out. People who like C will not use a language with garbage collection, even one that allows you to not use it. Against Java, it was a losing battle due to Java being backed by a giant (Sun , then Oracle) and basically taking the world by storm. Then there were also license problems in early versions of D, and two incompatible and competing standard libraries dividing the community. By the time all these problems were fixed, like a decade ago, it was already too late to make a comeback. Today D is a nice language with 3 different compilers with different strengths, one very fast, one produces faster results, and one also does that by works in the GCC ecosystem. That’s something few languages have. D even has a betterC mode now which makes it very good as a C replacement, with speed and size equivalent or better than a C equivalent binary… and D has the arguably best meta programming capabilities of any language that is not a Lisp, including Zig. But no one seems to care anymore as all the hotness is now with Rust and Zig in the systems languages space.
I like and use D but Nim has better metaprogramming capabilities (but D's templates are top-notch except for the error message cascades). (And Zig's metaprogramming is severely hobbled by Andrew's hatred of macros, mixins, and anything else that smells of code generation.)
> Note: ImportC and BetterC are very different. ImportC is an actual C compiler. BetterC is a subset of D that relies only on the existence of the C Standard library. BetterC code can be linked with ImportC code, too.
D contains an actual C compiler because Walter Bright wrote one long ago and then incorporated it into D.
Zig also contains an actual C compiler, based on clang, and has a @cImport directive.
I had D support in my distro for a while, but regrettably had to remove it. There's just too many problems with this language and how it's packaged and offered to the end user, IMO. It was too much hassle to keep it around.
To get it onto one's system, a bootstrapping step is required. Either building gcc 9 (and only gcc 9) with D support, then using that gcc to bootstrap a later version, or bootstrapping dmd with itself.
In the former case I'm already having to bootstrap Ada onto the system, so D just adds another level of pain. It also doesn't support all the same architectures as other gcc languages.
In the case of dmd, last I checked they just shove a tarball at you containing vague instructions and dead FTP links. Later I think they "updated" this to some kind of fancy script that autodownloads things. Neither is acceptable for my purposes.
I just want a simple tarball containing everything needed with clear instructions, and no auto downloading anything, like at least 90% of other packages provide. Why is this so hard?
Tip: pretend it's still the BBS days and you are distributing your software. How would you do it? That's how you should still do it.
I haven't tried the LLVM D compiler, and at this point quite frankly I don't want to waste any more time with the language, in its current form at least--with apologies to Walter Bright, who is truly a smart and likeable guy. Like I said, it's regrettable.
The only way to revive interest in D is through a well planned rebranding and marketing campaign. I think the technical foundation is pretty sound, but the whole image and presentation needs a major overhaul. I have an idea of how to approach that, were there interest.
The first step would be to revive and update the C/C++ version of the D compiler for gcc so as to remove the bootstrapping requirement and allow the latest D to be built, plus a commitment to keeping this up to date indefinitely. It needs to support all architectures that GCC does.
Next, a rebranding focused on the power of D without garbage collection.
I'm willing to offer ongoing consultation in this area and assistance in the form of distro support and promotion, in exchange for a Broadwell or later Xeon workstation with at least 40 cores. (Approx $350 on Ebay.) That's the cost of entry for me as I have way too much work to do and too few available CPU cycles to process it.
Otherwise, I sincerely wish the D folks best of luck. The language has a lot of good ideas and I trust that Walter knows what he is doing from a technical standpoint. The marketing has not been successful however, sadly.
"We all know of the language and chosen not to use it."
Is a strange claim, and hard to cite. But I think many HNers have tried out D and decided that it's not good enough for them for anything. It is certainly advertised hard here.
But there seems to be a bug maybe? Just for fun, I had asked it to play the Real Slim Shady lyrics. It always seems to add 1 extra "please stand-up" in the chorus. Anyone see that?
Hello Gabriel from Kyutai here, maybe it's related to the way we chunk the text? Can you post an issue on github with the extact text and voice? I'll take a look.
+1. I was a strong proponent of RCS earlier. Don't care about Green/Blue bubble nonsense. But Google (an Ad company) started abusing RCS to send garbage ads my way. And there is no way to block that as well except for disabling RCS. I feel this is a loophole Google can abuse where local regulations ban vendors for sending promotional messages.
Whatever it is, Google of all org should not be at the Helm of this.
And the amount of moral policing they did to apple. Disgusting assholes. I hate Apple for a lot of reasons. iMessage is definitely not one of them.
I know this is a niche complaint but I hate packaging golang things. On Gentoo contributors are stuck hosting giant dependency tarballs since you need the modules to build a package and we sandbox networking while building.
I definitely think people will regret adopting Golang in time. It's this generation's Java, except without an smooth off-ramp in Kotlin/Scala and even less of the benefits.
I have no idea what issues folks are talking about. I use vanilla gnome for my work and personal use case (given with well supported GPUs, read: no Nvidia). All the features work. Zoom/screen share/obs etc.,
Multi touch gestures work on laptops as smoothly as they were on a mac. HDR has started working recently even in my browser. VRR has been working for almost a couple of years.
It doesn't break, most mem leaks that gnome was known for all gone. Almost all the cli X specific tools I use (mostly clipboard stuff) are all available. Initially when I switched I did see like a 10~15% increase in battery usage albeit being smooth.
You can easily setup a copr repo for this to solve the auto update qualms for almost all the RPM repos. Needs a spec file and that's about it.
AUR should do.
Debian. Eeshk.