Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Driving with D

dlang.org

Post reply on HN
Print view View original

121–130 of 186 posts

Re: Driving with D

#121

Post by emondi »

0dyl wrote: post #105
emteycz wrote: post #58

> From the factory, it came with a rubbish four-speed automatic gearbox. During 18 months of ownership, I destroyed four gearboxes. [I'm from Europe.] I absolutely don't get this. Just... what? Four gearboxes? I don't know anyone who destroyed a single one - even after an entire lifetime of daily driving, but I don't mean Mercedeses - more like Škodas. What's up with American cars? Is this common? Edit: my bad, the c…

They're really not good gearboxes. Keep in mind, with the 4 speeds I drove casually. With this 6 speed, I can push it hard and it's still going strong almost a year later. They're quite an old (American) design bolted to a modern engine. It simply doesn't mix well. 4 speeds (4L60e) are the bread and butter of automatic transmission rebuilders in Australia. My father killed one in his daily driver, and all it did was…

What do you mean with "push it hard"? Maybe try a manual next time. Half of the fun of driving for me is switching gears.

Re: Driving with D

#122

Post by destructionator »

systems wrote: post #119
mhh__ wrote: post #31

Earlier quoted context omitted.

This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…

on the point of the GC being a good thing to have, this is true, but not when your main objective is to replace C++, C++ key advantage being RAII deterministic manual memory management You cant replace C++ with GC language, even 10 years ago this should have been evident to a seasoned developers such as Walter Bright and Andrei Alexandrescu Sometimes great developers are bad product managers Anyway, with Rust and Go,…

> your main objective is to replace C++

D's main objective is to be useful. I did some hobby C++ that I replaced with D, but my main D migration was actually from PHP.

Re: Driving with D

#123

Post by LAC-Tech »

Diggsey wrote: post #17
fnord77 wrote: post #2

Any reasons D never caught on more? No big tech company anchor behind it?

I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: -…

D is easy to pick up, and has three really fast compilers. It feels like a very practical language.

Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway.

And I really question what these situations are where you can't have garbage collection in 2021. Hard real time systems, sure, but that's not what 99% of people are using rust for. Maybe people just like the challenge.

Re: Driving with D

#124

Post by iso8859-1 »

danielEM wrote: post #48
gagege wrote: post #18

Earlier quoted context omitted.

I use D every day at work (inherited codebase) and the UFCS bothers me to no end. I try not to use it.

do you have open vacancies? :-)

Symmetry Investments has vacancies with D: https://news.ycombinator.com/item?id=27034032

Re: Driving with D

#125

Post by Corazoor »

WalterBright wrote: post #117
Corazoor wrote: post #37

Earlier quoted context omitted.

Certainly not the sole reason, but the mix of language features puts it into a weird spot: You have great control over memory layout and can easily embed assembler, which would be perfect for performance sensitive software like games. Yet "default" D comes with a garbage collector and - more importantly - language features that require said GC. If you want to go the noGC route, you have to refrain from using certain…

> language features that require said GC A whole two features: 1. concatenating strings using the ~ operator. You can concatenate strings using malloc if you prefer. 2. closures that escape the context of the function they enclose. Instead, write a struct with fields representing the values, and make the lambda a member function of that struct. Allocate the struct instance any way you wish. The GC is a convenient fea…

Maybe something changed, but I thought array concatenation with ~, associative and dynamic arrays as well as exceptions rely on the GC as well.

It's a short list, for sure, but thats not the point: Anyone looking into using D without GC will see that there are some language features that require special care.

At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.

GC free D is low friction, but seemingly not low enough for uptake from interested parties.

Re: Driving with D

#126

Post by 0dyl »

emondi wrote: post #121
0dyl wrote: post #105

Earlier quoted context omitted.

They're really not good gearboxes. Keep in mind, with the 4 speeds I drove casually. With this 6 speed, I can push it hard and it's still going strong almost a year later. They're quite an old (American) design bolted to a modern engine. It simply doesn't mix well. 4 speeds (4L60e) are the bread and butter of automatic transmission rebuilders in Australia. My father killed one in his daily driver, and all it did was…

What do you mean with "push it hard"? Maybe try a manual next time. Half of the fun of driving for me is switching gears.

Flogging it, pretty much.

I have a manual license, but I'm not interested in them. Thanks for the suggestion anyway.

Re: Driving with D

#127

Post by 0dyl »

pretty_dumm_guy wrote: post #103
0dyl wrote: post #13

Hi, I'm the author of the article. Feel free to ask any questions you may have. I have to go to bed, I have work in about 4 hours, so I'll reply when I can.

Hi, Firstly, Congratulations. This is no trivial accomplishment. Here are the questions I have. 1. Normally, cars come with their own ECUs for the engine. Interfacing with them requires knowledge about the underlying firmware used afaik. Did you happen to reverse engineer the firmware so that you could interface your own electronics with the provided ECU ? 2. How did you make the car believe that your 6 speed automat…

Sorry for my late reply. I'm currently at work- I'll make sure to reply when I knock off. Have a great day :)

Re: Driving with D

#128

Post by philzook »

nicoburns wrote: post #80
eggy wrote: post #46

Earlier quoted context omitted.

I am learning Rust and SPARK2014, and I would think SPARK2014/Ada would be a better fit for high-integrity software for verifiable, embedded software than Rust. This was the older article that stimulated me to look at Ada and then SPARK2014 again: https://www.embedded.com/spark-2014-why-i-am-backing-a-predi... EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development

That's probably true for now. But only because there's no equivalent to SPARK for Rust yet. Rust + something like SPARK could be really amazing.

Interesting work in that direction https://www.youtube.com/playlist?list=PL-uEDsw-7yRLYMEdlvh4u... Rust verification Workshop 2021

Re: Driving with D

#129

Post by eggy »

nicoburns wrote: post #80
eggy wrote: post #46

Earlier quoted context omitted.

I am learning Rust and SPARK2014, and I would think SPARK2014/Ada would be a better fit for high-integrity software for verifiable, embedded software than Rust. This was the older article that stimulated me to look at Ada and then SPARK2014 again: https://www.embedded.com/spark-2014-why-i-am-backing-a-predi... EDIT: Cool list of SPARK2014/Ada embedded projects: https://blog.adacore.com/tag/embedded%20development

That's probably true for now. But only because there's no equivalent to SPARK for Rust yet. Rust + something like SPARK could be really amazing.

I agree, but I just turned 57 (been programming since 1978 for fun), and there is so much already done in Ada that powers SPARK that it will be a while for it to be tried and true. Although, with all the work on theorem provers and such, maybe it will be exponential and I'll be around to see it. I really like Zig too, but I am staying with Rust because of its inertia. At heart, I love J/APL, but I use them for wholly different reasons.

Re: Driving with D

#130

Post by eggy »

gavinray wrote: post #85
nicoburns wrote: post #80

Earlier quoted context omitted.

That's probably true for now. But only because there's no equivalent to SPARK for Rust yet. Rust + something like SPARK could be really amazing.

There are some things that attempt to come close. Prusti by ETH Zurich is maybe the closest. https://github.com/viperproject/prusti-dev https://www.pm.inf.ethz.ch/research/prusti.html extern crate prusti_contracts; use prusti_contracts::*; #[requires(something)] #[ensures(result >= a && result >= b)] #[ensures(result == a || result == b)] fn max(a: i32, b: i32) -> i32 { if a > b { a } else { b } } Ada seems like a fa…

I am an Ada/SPARK novice, but on first look Prusti seems to deal with contracts, but I am not sure how much more of the Ada/SPARK system it may covergg. I used to dislike Ada and SPARK due to their verbosity, but after studying some of the embedded work in them, and what they bring to the table, I am no longer put off by that or syntax. I've seen Julia and even Elixir projects in areas that would better suit Ada/SPARK, but I think it is due to their popularity rather than applicability. But things like Elixir's Nerves platform is very interesting in bringing the BEAM to the embedded world, and I love Pluto notebooks for Julia, but for high-integrity software I think I'll try and leverage Ada/SPARK's capabilities and pedigree for now. I will look further into Prusti this weekend.
Post reply on HN