atilaneves

You don't need Emacs

Yes, I do.

and lose access to most things

What "most things" are these?

No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).

Yes, that's my point. I'm replying to claims that "if it compiles it probably works". My limited experience with both is "nah".

Because it is also possible to write tests that don't adequately capture real-life requirements.

It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.

Every language with a GC drastically reduces the chance of memory errors.

I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.

So...yeah.

I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?

I'm still figuring out why anyone would want to write a shell script in C. That sounds like torture to me.

Wouldn't the instance state here be "was constructed"? That is: you should always be able to call `Read` because the constructor opened the file, and you shouldn't have to call `Close` anyway because the destructor did.

I just posted on the forum about it, I didn't do it before because of surgery (I'm still nowhere near 100%).

What changes would you like to see happen?

FWIW, I just posted this on the D forum: https://forum.dlang.org/post/vwnefgsszqxobssylhmc@forum.dlan...

Proof of the fact that this works is that D does exactly this.

What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme

I think that's a non-starter because you instantly lose the entire ecosystem of elisp packages out there and nobody's config would work anymore. The latter is especially important when for some people that's a decades-developed init.el file in a repo that's migrated from CVS to subversion then git.

I've git bisected (mercurial at the time, but whatever) my .emacs repo to figure out what I did to break my Python config, so there's that.

Switzerland has a population of 8.6M, isn't part of the EU, and yet...

The problem there has been getting enough doses delivered.

If the array fits in the cache, deleting from the middle of an array and copying all the subsequent elements one to the left is actually faster than a linked list.

And most arrays fit in the cache.

dpp* can't do function definitions yet but for declarations it's as easy as #including a C header file natively.

* https://github.com/atilaneves/dpp

I think you missed the point where they mentioned you can change any and all keybindings in Emacs.

1. That's a rare use case 2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??

And yet, it's worse than both.

Source code is for humans

The reason why making the scope as local as possible is important is for humans, not compilers.

Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block"

Why would humans care about how much scratch space is needed? That's for the compiler to know.

That would be satan's language.

No need to imagine, it happens all the time in D, and it's not that bad.

Simple is better. People however tend to not agree on what's simple.

Not really - the concrete type isn't important, but what you can do with it is. One could argue that instead we'd use a concept in place of `auto`, and Bjarne has argued exactly that for C++.

> It takes an input range Which should have a type.

It does. That'd the `Range` here: https://dlang.org/phobos/std_algorithm_iteration.html#.map.m...

> and returns a type that iterates through that range Which should have a type.

It does. But the name of that type depends on the type of the range and on the callable.

Functor f => (a -> b) -> f a -> f b

This doesn't work because the return type isn't `f b`, it's `g b` where g depends on what f is. It also depends on the callable, because the first parameter isn't necessary a function. The closest is

Callable c, Range r0 => c a b -> r0 a -> r1 b

Where `r1` isn't even a concrete type but a type that depends on both `c` and `r0` and is made up on-the-fly (per instantiation).

Documentation is good.

I agree. How would you suggest improving the signature of map given that D doesn't have typeclasses? Or with types that depend on other types in the template?

Not in D, it isn't, for performance reasons. It takes an input range and returns a type that iterates through that range applying the callable (doesn't have to be a function!) to each element as requested.

Are there any downsides beyond the niggle the author mentioned?

For me, using a GC is just a lot easier than making the borrow checker happy. Given that in practice it's rare that the GC is the bottleneck (and when it is I write around it after profiling), the trade-off just isn't worth it for me.

Are compilation speeds an issue for anyone?

Yes, it's pretty slow to compile.

I got given it as a child in the form of coffee.

Compile time generic programming is not a replacement for runtime reflection.

Yes, it is, especially since the former can be used to implement the latter.