
D is being used for autonomous driving research – Audi and Mercedes - pjmlp
https://forum.dlang.org/thread/udqxobzmwmgksgmcimjz@forum.dlang.org
======
totalperspectiv
I have done an unhealthy amount of comparing around the languages in this
space. I'm curious what others think about the tradeoffs between choosing
Nim/D/Go/Crystal/C#/Java/Kotlin? Previously I would have not included Rust in
that grouping, but I've finally bitten the bullet and started learning it...
and now I would, high level abstractions with low level control, etc etc.

Essentially there's a class of programs that are performance sensitive, but
also dev time sensitive. How do you choose between the set above? (The answer,
if there is one, is probably Python, and then optimize the hotspots, but lets
pretend we can indulge).

\- Nim: fast dev time; fast performance; not v1, C/C++ interop is second to
none. Newruntime seems awesome

\- C#: medium dev time; med-fast performance; very OO, coreRT and readToRun
are awesome

\- D: fast dev time?; fastish performance; I haven't written more than a few
lines

\- Go: fast dev time; med-fast performance; interop is expensive, lack of high
level abstractions

\- Crystal: ?; fast?; have not used

\- Java: medium dev time; med-fast performance; very OO, GraalVM is cool

\- Kotlin: fast dev time; med-fast performance; kotlin native may be cool some
day

\- Rust: slow/medium dev time; fast; safe, awesome type system

\- C: slow dev time; fastest?; unsafe / current tooling and docs are like
performing an archeological dig.

\- C++: medium/slow dev time; fast; unsafe / full of intricacies

All of the above are obviously opinions gained over time with sources
forgotten and I've only written a few hundred lines in each language. PL ADD
is real. At the moment, Rust is scratching all the itches though, and I'm
excited to see if my mental model of programming adapts to the language and
dev speed is not an issue. Obviously I like collecting hammers and am less
good at finding nails.

Very cool to see D getting picked up for some serious use. D and Nim are
fantastic and hopefully thrive in the coming years. I would love to see a
write up of what led them to choose D.

~~~
earenndil
C, D, C++, rust, and nim should all have comparable performance; they all go
through gcc|llvm, and all have the same optimizations. Rust and c++ may be
slower in debug mode than their other-language counterparts, but the cost of
abstractions goes away when optimizations are turned on (in exchange for
drastically increased compile times). Java is not significantly more OO than
C++; global-scope variables and functions in c++ are analogous to static ones
in java. D's interop story is similar to nim. I don't know rust, but I believe
it is said to be more expressive than c++.

Honestly, I think all the judgements of dev time are a little bit misleading;
iirc there were some studies showing that productivity is not significantly
different across languages.

Worth noting, though, is that D and Go compile _really quickly_.

~~~
xhgdvjky
d is just such a pleasure. it's like it was designed to make the programmer
happy. maybe that's not a reason to choose it, but it's a huge perk

~~~
vram22
>d is just such a pleasure. it's like it was designed to make the programmer
happy.

IIRC, Walter has said somewhere (likely on the D site or on his site or one of
his articles for DDJ) that it _was_ designed for that, actually, or something
to that effect [1]. I've felt that myself while using it. I think he also said
something like the code should look good on the page.

I agree.

[1] Or at least, make _him_ happy :)

~~~
vram22
This subfeed of my blog has all my D language posts, about a dozen of them
(apart from a few videos of D or related confs):

[https://jugad2.blogspot.com/search/label/DLang](https://jugad2.blogspot.com/search/label/DLang)

They may be of interest to beginners or others wanting to get a bit of a feel
for some of the kinds of things D can do, via simple command-line programs,
along with checking the D site and tour at dlang.org .

------
z3t4
I really want an excuse for learning D. I'm currently working as a full stack
web developer using Node.JS and JavaScript. What I like about D on the surface
is that it compiles fast, so I'll still have a fast feedback-loop. It has
support for named lexically scoped modules which I like so much about Node.JS,
but without the performance penalty. It doesn't seem to enforce any particular
programming paradigm. And that it allows another level of optimization which
you can only get from a "systems" language.

~~~
TheSmoke
as a d user, i definitely do not recommend d for web development. for
everything else, go for it. it's just because d does not have a mature web
development ecosystem.

i'm hoping this will change soon but this is the case for now. i simply don't
want you to be disappointed when you finally decide to jump in.

~~~
z3t4
I do not like web frameworks. All I need is a websocket module with legacy
fallback. Something like SockJS, to build a JSON API on-top of. And a database
module for persistence. But I use Node.JS for almost everything; image
rendering, network services, utility tools. etc. And if a bash script requires
more logic then a bunch of unix pipes I usually write that in Node.JS too. I
like that D can be used like a scripting language. Node.JS started out as an
async networking framework focusing on performance, simplicity and fast
development. Despite it's huge potential it has mostly become a scaffolding
tool for web frameworks. What concerns me most though is TypeScript as well as
EcmaScript piling on mostly useless features to the JavaScript language,
making it harder to learn, and dividing the community.

------
devy
In their job post[1] title&description, they specifically mentioned that D
programming language is used for "Software Verification & Validation". So it's
possible that the core tech stack may or may not be written in D.

[1]: [https://jobs.lever.co/aid-
driving/c4b243bd-c106-47ae-9aec-e3...](https://jobs.lever.co/aid-
driving/c4b243bd-c106-47ae-9aec-e34d5bbe0ce1?lever-via=vcPRnEaCR3)

~~~
simfoo
Our core stack is written in C++ so most of our open positions are about C++.
Have a look at [https://jobs.lever.co/aid-
driving?department=Software%20Engi...](https://jobs.lever.co/aid-
driving?department=Software%20Engineering)

~~~
gdy
Was it a requirement for 'Software Verification & Validation' to use a
different language?

------
hellofunk
D is the only language I use any more, so it's neat to see others have made
similar realizations about it.

~~~
mobiledude
Do you get to use it for work? Or just for personal projects?

~~~
dymk
Given how few companies use it, we can safely guess personal projects.

~~~
nemanjaboric
Given his user name he may be from the Funkwerk:
[https://dlang.org/blog/2018/03/14/user-stories-
funkwerk/](https://dlang.org/blog/2018/03/14/user-stories-funkwerk/)

------
thenightcrawler
Sell me on using D, I have no skin in the game, just curious of what fans of D
say.

~~~
jadbox
It was one of the easiest languages for me to learn, and I felt I was as
productive in it as Py/Node (that I've used for years) with only about 2 weeks
of playing with D on the side. There's a lot of intuitional things that D gets
very right imho, from syntax to the standard lib. Also the generic/template
support in D is a real pleasure to work with coming from most other languages
I've used.

There's a couple challenges though. D's community for library support isn't as
rich when comparing to even newer languages like Go. The other issue is D's
runtime gc (which is being slowly removed/reduced) is pretty slow compared to
Go, and is similar to Python in performance.

The shame is, on paper, D could replace Py or Node for being a very developer
productive language. However, it can't compete with them because it doesn't
have the same massive community. It also isn't performant enough to stand out
against Go and Rust. So D is sitting in an uncanny valley without a silver
bullet to stand out against any one particular audience. In many ways, D
reminds me of Plan9. For me personally, it's one of my favorite languages to
program in (it "gives me joy"), but I currently only use it for side projects.
My hope is in these active projects:

a) D minimizes gc use and makes the gc as fast as Go's, allowing it to
complete in the performance [web app] category. Vibe.d performance competing
fairly in the top of techempower benchmarks.

b) Rust adds more sugar to improve developer 'ergonomics' and finishes the
async additions.

c) Go gets "D like" generics and macros (Shh... I can dream)

~~~
nicwilson
Re GC, it is most definitely not being removed. Dependance on it is being
reduced (with @nogc) and if you don't allocate from it, it will never trigger.

It was recently made multithreaded for the mark phase (sweep is still single
threaded), which for large heap small garbage has made it significantly
faster.

There are also fork-based GC's available for linux where the mark and sweep
are done by a separate process.

The GC is stop the world so if you care about latency the default is not so
great, but there are plenty of groups using D for hard realtime systems with
either no use of the GC or the fork based one. Speed wise the default is not
too bad.

------
sk0g
I've wanted to get into this field for a while now - how does one get in? I'm
hardly going to build myself a hobby self-driving car!

While I'm working full time as a backend engineer, I do have final placement I
am yet to complete. Would doing it in computer vision-y areas be of a
particular value add, or would my best bet be skill up in C++ and then look
for a relevant job?

~~~
thenightcrawler
Check out udacity self driving car class.

~~~
sk0g
If I found the right one [0], it's a bit pricy, seems to encourage doing it in
a burst. Looks like it's very connected to the industry, at least in terms of
course load. Thanks for the pointer, will look into it some more when I get
tired of my current job (getting there slowly but surely!)

[0] [https://www.udacity.com/course/self-driving-car-engineer-
nan...](https://www.udacity.com/course/self-driving-car-engineer-nanodegree--
nd013)

~~~
jmkni
I thought that was a joke! Awesome though!

------
ricardobeat
Direct link:
[https://forum.dlang.org/thread/udqxobzmwmgksgmcimjz@forum.dl...](https://forum.dlang.org/thread/udqxobzmwmgksgmcimjz@forum.dlang.org)

~~~
dang
Ok, we've changed to that from
[https://old.reddit.com/r/programming/comments/c4f1hu/dlang_b...](https://old.reddit.com/r/programming/comments/c4f1hu/dlang_being_used_for_autonomous_driving_research/).

------
fnord77
how safe is D, compared to C/C++ on one end and Rust on the other end?

~~~
vips7L
I would say it depends. Maybe Walter will chime in, but from what I can tell
it is fully possible to use raw pointers (-betterC) and step into unsafe
space, but if you're using the full runtime it should be as safe as go, java,
etc.

~~~
mhh__
-betterC removes the druntime features, but pointer safety is gained with the -dip1000 flag (with @safe) regardless of whether you use betterC or not.

@safe will also stop you doing obviously unsafe pointer arithmetic unless you
abstract it into a @trusted function.

