Dlang

Is there some kind of meme in the Rust community where "safe, fast" must always be part of the project description?

>OP loves D
What a surprise

It's pleasant to program in
>C++ stealing our ranges

> generators
> ranges in stead of streams
> operator overloading
> classes and structs
> strongly typed and support for dynamic types
> template metaprogramming done right
> no macros
> traits and compile time introspection and mixins
> immutable types and pure functions
> delegates (closures)
> functional reductions on ranges
> lazy when needed
> deterministic garbage collector and custom allocators
> built in async await
> non verbose
> algol syntax

Walter and Andrei did such a good design that features such as pattern match, variant types, algebraic unions and reflections are done through libraries

>Rust is better at system programming
When I first started learning D I was like this is soo cool and awesome. They try to say its a systems programming language so I want to develop a microkernel in it. Well I quickly found out that I'd need to bring their whole huge amount of dependencies into it which then it would no longer really be a microkernel. This was unlike a basic C microkerne I did, C has no dependencies it can run bare metal without anything else. Does Rust have a similar problem that D has?

no, too little, too late with too retarded delays

>no macros
Also: No actual macros, besides having no C preprocessor """"macros"""".

About how long ago did you try
dlang.org/changelog/2.079.0.html#minimal_runtime

No, Rust has no runtime, there are microkernels written in Rust - redox-os.org/

I was trying to do that a long time ago before 2.079. I'm havent read that changelog yet but from what I remember even back then there was stuff like that to specify some kind of minimal runtime dependency. But the problem was that made you have to stick to a severely limited subset of the language that it was no longer really the awesome D systems programming language that you first read about thinking about how cool it would be to try to do a kernel in this language.

> it was no longer really the awesome D systems programming language
Also most of the libs won't work, since they require GC to work, I assume.

>classes and structs
I wonder if deciding heap vs stack in-place would have been a better solution.
>template metaprogramming done right
no such thing, should have gone with proper macros or full compile time execution instead

emerge sys-kernel/redox-os-sources when?

>Java and C# is better at application programming,
D shits on Java and C# because it doesn't have to load 50 GB runtime first.

I guess I'd ask what you'd want from a standard library at that level.

Also here's an OS that's in active development
github.com/PowerNex/PowerNex

It's 2018, who cares about a hundred mb or so? And then C# and Java have two orders of magnitude better tooling, two orders of magnitude more libs and infinite order of magnitude more jobs.

nice meme
In reality, JVM and CLR shit on D because D has a subpar garbage collection.

>In reality, JVM and CLR shit on D because D has a subpar garbage collection.
Haha, sorry to burst your bubble
github.com/kostya/benchmarks
github.com/frol/completely-unscientific-benchmarks

I know you can develop a kernel in D, but like I said in the previous post I was interested in trying to make a microkernel with this cool systems programming language and found it would require bringing in a bunch of dependencies and that would make it not so much of a micro kernel anymore.

Performance still matters, people don't want to wait forever to load their calculator.

Attached: Screenshot_2018-07-17 bdrung startup-time.png (1776x1168, 118K)

He's mostly C++ because of the opportunities, but loves to work in D as well

FUD, he's still working and a very active core D contributor.

>output not sorted by completion time
what the heck...

Don't you dare accuse me of being a fuddy duddy

I'm not your buddy

>Performance still matters
>posts microbenchmarks
Nice startup measurements.

Yeah, when your app starts x26 time slower it's a concern.

It's not when the absolute difference is 26ms.

The issue is with their usability in shell scripts. Programs are often started on a loop, and if it's started 10 times, 26ms becomes 260ms, 100 times and you have 2.6 seconds of wasted time loading the runtime.

You wouldn't use C# or Java for this, you would use C, C++ or Rust, something without GC at all.

D has a complete C standard subset, with no GC. With templates, modules, ranges and package management.

A lot of people use either quick languages like python, or the languages they're most familiar with for these things, which might include Java.

According to your first benchmark the following GC languages that compile to native executables are approximately as fast as D:
>Nim
>MLton
>Crystal
>OCaml
How does D compare to them?

I don't think D has any libraries that implement real pattern matching.

These days microkernels write part of the stack in fucking Go.

>D has no niche - Java and C# is better at application programming
d's niche WAS application programming except that it had to compete with java in its peak and while java was the language being taught in schools, d stood absolutely no chance against java despite java being absolute cancer for 'applications programming'

rust has "no runtime" just like c and many of the things you'd expect to find in the standard library like rand are put into crates to keep the dependencies of huge libraries to a minimum, depending on what you need or want to do rust may be suitable now but for some things it's not quite there yet and the rust team are aware of this - rust on embedded is an ongoing effort for instance and is on the roadmap, but rust for systems programming is absolutely fine

Compile time functionality is pretty in-depth, I haven't had any problems just assigning things I want precomputed to an enum.

>how to get pegged
that's indeed a very interesting project.

Just because of Tilix

>>Nim
Pretty Nice. Nim has the potential and as a language, better than D in all aspects. Then again it doesn't have people like Walter Bright and Andrei Alexandrescu working on it
>MLton
who
>Crystal
Pretty nice. In fact I'd be interested to see it catch on. Not for systems programming though, good replacement for Go. Currently it has a very little support for windows and parallelism.
>>OCaml
Not as fast.