[HN Gopher] Driving with D
___________________________________________________________________
Driving with D
Author : pjmlp
Score : 289 points
Date : 2021-06-01 14:10 UTC (8 hours ago)
(HTM) web link (dlang.org)
(TXT) w3m dump (dlang.org)
| emteycz wrote:
| > 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 Skodas. What's up with American cars?
| Is this common?
|
| Edit: my bad, the car is Australian.
| cgh wrote:
| Holdens are Australian, not American.
| ok123456 wrote:
| They're owned by GM now. Modern ones will be GM parts-bin
| cars. Going through that many GM transmissions is possible.
| This is why GM cars have horrible resale value and anything
| over 150k miles is on borrowed time.
| panopticon wrote:
| These use GM's 4L60E 4-speed automatic. I don't remember
| the 4L60E being _that_ much of a lemon that you blow
| through four of them with normal use.
| 0dyl wrote:
| Holden has been owned by GM since the 1930s and has been
| building its own vehicles since 1948. Holden ceased
| building cars in 2017 and was disbanded in 2020 (RIP).
|
| But yeah, the 4L60es are lemons in my eyes.
| 0dyl wrote:
| 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 go
| 20km each way to and from work. My Aunt's Commodore was
| recently in the shop getting a new 4L60e. They're simply not
| suited to the car.
| emondi wrote:
| 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.
| danielEM wrote:
| > great for racing
|
| that could explain a bit
| the-dude wrote:
| I hate to be that guy, but is this legal?
| 0dyl wrote:
| Good question!
|
| It is. I contacted a VicRoads approved engineer in regards to
| this project, and I received the all clear. I've been pulled
| over by cops, and they were cool with it.
|
| My insurance is ok with it, too.
|
| It does have a software watchdog, and failing that, the
| gearbox's hydraulics have a safety mechanism that allows for
| some limited driving.
| mikepurvis wrote:
| Almost certainly. Basically all "under the hood" mods like this
| are-- street legality for a vehicle you build or modify
| yourself is a surprisingly narrow band of requirements that are
| mostly around safety equipment like lights, horn, etc:
|
| https://en.wikipedia.org/wiki/Street-legal_vehicle
|
| The much higher bars to clear are when it comes to a device
| that you offer for sale to others for _them_ to operate on the
| road.
| 0dyl wrote:
| 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.
| danielEM wrote:
| Out of curiosity, what is your job?
| 0dyl wrote:
| I'm a full time university student (20 y/o). I work part time
| as a labourer for a crane truck company.
| [deleted]
| [deleted]
| [deleted]
| mhh__ wrote:
| He said he's gone to bed, but he's a student.
| danielEM wrote:
| I must have missed that comment, just saw "I have work in
| about 4 hours"
| mhh__ wrote:
| It was on our discord, I should've said. Feel free (to
| anyone) to join if you'd like to learn more about D.
| jgilias wrote:
| This is what I love HN for. Every now and then there's a
| submission like this that makes me go: "How do you even...".
|
| That being said, is there maybe somewhere a more thorough
| write-up about the whole thing? You know, with more in-depth
| technical details, gotchas, and so on? I'm sure many people
| would enjoy reading that!
|
| Thanks for posting!
| 0dyl wrote:
| Thank you so much for the kind words :)
|
| Sorry, no. I don't have a blog or website or anything. The
| closest thing I have to a devlog are some posts in a private
| Facebook group dedicated to the Holden Commodore.
|
| I think this project is almost 12 months old now.
| olyjohn wrote:
| This project sounds awesome. I hope you will find some time
| later to post it on the web. So much legendary information
| is stuck in Facebook, and difficult to find, or just lost
| forever.
| alephu5 wrote:
| You're a wizard. I wouldn't have a clue where to start with a
| project like this.
| lbj wrote:
| No questions, but let me just congratulate you on a wonderful
| hack, very well done!
| 0dyl wrote:
| Thank you so much for the kind words :D
| pretty_dumm_guy wrote:
| 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 automatic
| transmission was a 4 speed automatic ?
|
| 3. > "the ability to go ahead and change the way it works
| whenever I want." - Could you please elaborate what you mean by
| this ?
|
| Again, I am amazed by what you have accomplished. My inner
| mechanical engineer is so keen to know how this all came
| together. I think everyone would definitely appreciate if you
| could provide a rough overview of how you achieved these
| things. Thank you :)
| kleiba wrote:
| What are the legal hurdles you had to jump to get this hack
| approved for street use? As car modders know all too well, this
| can often be the hardest task.
| 0dyl wrote:
| Fortunately, and surprisingly, this project was smooth
| sailing on the legal front.
|
| I contacted a VicRoads certified engineer in regards to the
| project and got the all clear.
|
| Even my insurance was OK with it.
|
| I think it's because most of the legislation is aimed at
| engine modifications.
| Grazester wrote:
| I follow the car modding scene and to be honest, in the U.S.
| there don't seem to be anything preventing this from being
| street legal. Even in California, something like this being a
| non-engine mod I don't see it being an issue.
| p0nce wrote:
| I use D every day for own business and it's a pleasure. Nice
| work!
| danielEM wrote:
| What for exactly you use it?
| p0nce wrote:
| Products in https://www.auburnsounds.com/ also PDF
| generation, SIMD, static websites (CommonMark), and a lot of
| internal tools. There is a wide gamut of applicability.
| (EDIT: I have become that blurb programmer :o )
| alphaglosined wrote:
| Audio plugins like VST.
|
| He created dplug, a framework for audio plugins in D a pretty
| great feat!
| 0dyl wrote:
| Thank you! Your post about D without its runtime is a fantastic
| read.
| ximeng wrote:
| UFCS example uses units, which looks neat, but assigns
| injectorWidth to a variable injectorTime, which seems wrong?
| gagege wrote:
| I use D every day at work (inherited codebase) and the UFCS
| bothers me to no end. I try not to use it.
| 0dyl wrote:
| That's understandable. Not for everyone.
|
| Different situation, but I do admit when I first got into D I
| was wary of the UFCS feature and I avoided it, too.
|
| Over time it felt a bit more natural and I began to
| appreciate it.
| schveiguy wrote:
| There are "bad" uses of UFCS, and good ones (sometimes
| depending on preference). For example, I hate code like
| `1.writeln`.
|
| The major feature that it provides is pipelining (as shown in
| the article)
| crazypython wrote:
| Adding a method to a class you don't control is also
| useful.
| jhvkjhk wrote:
| Can you explain why? I have never used D, but I think UFCS is
| really convenient.
| p0nce wrote:
| I don't know for GP, but UFCS functions just litter the
| auto-completion tab for me. It's also not always readable.
| danielEM wrote:
| do you have open vacancies? :-)
| jimbob45 wrote:
| Can you expound upon why you feel that way?
| gavinray wrote:
| UFCS as a concept is fantastic but the one hangup is that
| D's language server implementation by the community and its
| IDE integration can't handle it because of the complexity.
|
| https://github.com/Pure-D/serve-d
|
| https://github.com/Pure-D/code-d
|
| (I can't remember if the Visual Studio extension, VisualD
| handles UFCS or not)
|
| http://rainers.github.io/visuald/visuald/StartPage.html
|
| It's possible to implement, because Nim's language server
| handles UFCS, but atm D's doesn't do it (it's written
| pretty much by one people)
|
| So personally I avoid UFCS except for very simple/common
| function like "to!" because it breaks the intellisense for
| that call.
|
| Though if I knew the language inside and out probably I
| wouldn't care.
|
| It's still my "favorite" language.
|
| -----
|
| SIDE NOTE: This single person wrote the D lang server, and
| has maintained it, written and maintained the VS Code
| extension, and other fundamental tooling + libs for years.
|
| https://github.com/sponsors/WebFreak001
|
| If you use D and feel like sponsoring someone, consider
| sponsoring them, or Rainers (VisualD), or the maintainers
| or LDC or GDC, also single individuals for the most part.
|
| LDC Maintainer: https://github.com/sponsors/kinke
|
| GDC Maintainer: https://github.com/sponsors/ibuclaw
| mhh__ wrote:
| The language server doesn't do it because it's only a
| parser whereas making UFCS work properly would presumably
| require a full semantic analyser. By no means impossible
| to do, just no one has taken the plunge yet.
| mrfredward wrote:
| I believe width is referring to pulse width, which should be a
| time unit.
| 0dyl wrote:
| Bingo!
| 0dyl wrote:
| The units are a mix of D's UFCS and metaprogramming. I find it
| helps keep track of which units are used where in the code
| base, and stops me from accidently running operations on wrong
| unit types and such.
|
| Injector width / time pretty much means the same thing (at
| least in my code base). My apologies for the confusion.
| fnord77 wrote:
| Any reasons D never caught on more? No big tech company anchor
| behind it?
| Diggsey wrote:
| 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:
|
| - The complexity of the language, and then the sheer number of
| different ways of doing the same thing.
|
| - Some pretty dark corners in the way stdlib/language feature
| were implemented that seemed hard to ever fix.
|
| - The way behaviour is specified in the language is very tied
| to the underlying hardware: rather than explicitly describing
| behaviour in terms of an abstract machine, it works more in the
| way C++ is specified where we all know it operates on an
| abstract machine thanks to compiler optimizations, but the spec
| likes to pretend it doesn't...
|
| And then there are problems that are introduced by D, such as
| the fact that a safe subset exists, but depends on GC, so
| there's a weird split where no "safe code" can be used in
| contexts where GC is unsuitable.
|
| Contrast this to Rust, where:
|
| - There is a true step-change in bringing safe code to _all_
| contexts, not just those where GC can be used.
|
| - It's missing a lot of the complexity of C++. Rust is hard
| because it has concepts that are foreign to a lot of
| programmers, but the total number of features is low (compared
| to C++) so there are fewer surprising ways they can interact.
|
| - Rust is a suitable replacement for C, not just C++, because
| it's not just adding more features.
| LAC-Tech wrote:
| 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.
| brianush1 wrote:
| > such as the fact that a safe subset exists, but depends on
| GC,
|
| @safe works perfectly fine and exactly the same in @nogc code
| as in GC-enabled code.
| Diggsey wrote:
| My mistake - SafeD was introduced since I stopped using D,
| so I was going off this article:
|
| https://dlang.org/articles/safed.html#safed-subset
|
| > When you enter SafeD, you leave your pointers, unchecked
| casts and unions at the door. Memory management is provided
| to you courtesy of Garbage Collection.
|
| Does D provide the necessary tooling to be able to expose a
| safe API for something which needs to allocate memory,
| without needing a GC?
| alphaglosined wrote:
| You are stuck with dropping to @trusted and calling the
| appropriate allocator API.
|
| Following that you will want to check for null ext. to
| make it actually @safe in practice and not just typed as
| such.
| PoignardAzur wrote:
| That's a bit disingenuous. Memory allocations in D require
| either GC or non-local unsafe code.
|
| I'm aware that D has @live, a WIP attribute that mimics
| Rust semantics, but it's not remotely ready for production.
| mhh__ wrote:
| The idea that Rust is suitable to replace C and D isn't is
| odd to me. It's really not hard to do + we (unlike some
| languages, not sure about rust) actually test on embedded
| targets via GCC.
| Diggsey wrote:
| What I meant by this is: if you are starting a project
| today, and have to choose between C and C++, there are
| certain reasons why you might choose C over C++.
|
| Those same reasons would apply for choosing C over D. They
| might not apply for choosing C over Rust.
| mhh__ wrote:
| I can't think of a reason that would apply here. For me
| at least if I were on a toolchain so crap I had to use C
| you'd have to pay me a lot of money not to work on
| something else.
| SLWW wrote:
| All my embedded design work has been in C as i don't need
| all the extra cruft.
|
| Also anything i want to be very fast on limited hardware
| i also use C and C only.
|
| As for any hobby programming i do on the side, C is
| usually my goto choice, unless i want to be very
| esoteric.. following along the lines of: "The enemy of
| art is the absence of limitations."
| mhh__ wrote:
| I find that C actually gets in my way compared to D when
| I am writing code with limited resources. The end result
| is semantically the same but with D I can avoid macros,
| inline asm is easier etc.
| haolez wrote:
| Except that Rust compilers seem incredibly hard to implement,
| as opposed to C.
| pas wrote:
| To give some perspective: mrustc is written mostly by one
| person, in C++ and it caught up to 1.39.0 recently -
| meaning it can "compile" rustc itself (without any type
| safety validation) as opposed to arbitrary Rust code.
|
| Also C++ compilers are hard too. And optimizing C compilers
| are hard too...
| maxpert wrote:
| That is very true but absolutely fine because then some
| fine set of engineers can do the hard lifting parts and
| rest of the ecosystem can thrive on stable base that core
| establishes. That is how things work in most of industries,
| not everybody is writing a compiler (or even suitable for
| writing one!), but the complexity compilers remove lets you
| build more complex pieces of engineering.
| echelon wrote:
| I don't think minimal compiler complexity is a real
| requirement as much as safe and reliable software is.
|
| CPU fabs aren't easy, yet we're fine with that.
| haolez wrote:
| It matters for portability. I'm not saying it's the most
| important requirement, of course, but it's C strongest
| point.
| [deleted]
| Zababa wrote:
| Do you need to build an entire compiler or "just" the
| backend/code generation to port something? Although
| "just" a code generation for Rust means building one for
| LLVM, which I'm sure is harder than some C compilers out
| there.
| eggy wrote:
| 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
| nix23 wrote:
| Ada is absolutely great, it's a shame that is was "closed"
| behind really expensive compilers and government work in
| the past.
|
| GNAT Aux could use some help too:
|
| http://www.dragonlace.net/
| nicoburns wrote:
| 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.
| Jtsummers wrote:
| Rust's type system still lacks the expressivity of Ada.
| Rust has a lot to teach Ada (and you see this coming out
| from AdaCore's blog recently with efforts to add lifetime
| analysis to SPARK), but Rust has a ton to learn from Ada
| as well.
| gavinray wrote:
| 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 fantastic language though, and the 202x
| edition brought some niceties to the language.
| pizza234 wrote:
| Ultimately, for any language to become popular, it must bring
| something radically new on the table (e.g. Java: relative
| performance, simplicity and safety; Python: immediacy; etc.),
| and/or have a big company behind. D doesn't have any of the two
| (unfortunately! I do appreciate the language).
|
| This viewpoint is typically represented by the question "what
| can I do in X that I can't in C++?".
|
| Something I personally find interesting is the thought
| experiment: if Golang was written by a small actor, and D by a
| big one, which one would have succeeded?
| AnimalMuppet wrote:
| I don't know that it's essential that a big company be behind
| a language. What's essential is that the _tooling_ and the
| _libraries_ be top-notch. That 's beyond the reach of an
| individual, or even a small team. But a large company can
| easily provide the resources to do that.
|
| (The third essential is that a language do something
| significantly better or easier than existing languages. A
| language can't just be "does the same as C, but with a bit
| different syntax", unless it's _radically_ better syntax.
| Switching languages has a cost; your new language has to pay
| back that investment or it won 't get used.)
| systems wrote:
| As far as I know D's original design strategy, was to be a
| simpler to use C++ with a GC, but with the same expressive
| power
|
| Over time, this proved to be a bad strategy, C++ key strength
| became RAII (deterministic memory management), so the GC became
| a failed strategy
|
| The maintainers tried to move in different directions, adding
| manually memory management, making the GC optional, moved D to
| be a C replacement, with the -betterc compiling option, and
| many other tweaks and features added overtime, but nothing
| really caught on
| mhh__ wrote:
| 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 clean code out
| of the door quickly.
| Zababa wrote:
| Would it be fair to say that for some time (I wouldn't know
| exactly when it started) D has evolved to serve the needs
| of the D community rather than to attract new people?
| mhh__ wrote:
| Attracting new people is basically never (with exception
| of the C stuff) been the driving force behind efforts
| influencing D's design.
|
| Another anecdote - Someone who hires people in D has told
| me definitely that D being small means that hiring for
| them is usually just seeing some code, i.e. there hasn't
| been an eternal September let's say. They can onboard
| people who don't know the language, but knowing D is a
| very good cultural (programming is easy!) filter.
| Zababa wrote:
| Thanks, that's interesting.
| alphaglosined wrote:
| No it wouldn't be fair to say that.
|
| Lots of stuff exist specifically to help with onboarding
| people into the community. Like the recent announcement
| of adding a C parser into the frontend.
| systems wrote:
| 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, D have no where to go, I don't
| think it should be fixed to appeal to a wider user base,
| the only good strategic move they can do today, it make it
| better for the current user base, they have few big users,
| they should focus on them and the language will fade once
| those users move on to something else
| mhh__ wrote:
| Then don't use the GC? Ignoring that a lot of C++
| developers are practically incompetent and completely
| unable to separate their ideology from the actual
| requirements of their software (I note that not one
| single even anecdote has been mentioned regarding the GC
| in this thread), D gives you the tools to do that
| already. I work argue not as polished as C++, but that
| really doesn't matter if you set out to write a new
| project.
|
| Also, if you think existing D users are going to replace
| D with Go I don't know what to say to you. Go and Rust
| are literally punchlines without a need for a joke in
| discussions I've had with many senior people at these
| companies (Mostly Go). The reasons why people use D are
| so utterly detached from everything that has been
| discussed in this thread that I don't know what to say to
| you. Go is a bad programming language, pure and simple,
| good ecosystem, awful language.
| destructionator wrote:
| > 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.
| skocznymroczny wrote:
| It's trying to please C++ fanboys too much, who then get
| outraged about some other D feature and go back to C++ again.
| gher-shyu3i wrote:
| Challenging to overcome languages like C++, Rust, Java, and C#.
| D seems to sit somewhere in between, a better C++, but with
| (optional) GC. The thing is, Java and C# are already making
| strides into that space.
| tzs wrote:
| D was released 9 years before Rust, making it unlikely that
| rust had much influence on D adoption.
| bachmeier wrote:
| This is Hacker News.
| FraaJad wrote:
| I am curious to see where Java are C# are making progress
| towards optional GC.
|
| This specific article talks about using _No GC_ aka
| "betterC".
|
| D has GC by default; the use of GC is convenient and
| mainstream as most popular languages show - Java/C#/Python
| etc. What D gives is the unique ability to do No GC
| programming for the cases where GC is not desirable. Very few
| languages offer this capability.
|
| Zig is interesting in this arena, but it approaches the
| problem from the other angle. It is manual memory management
| by default, but you can explicitly choose which memory
| management technique you want to use - at compile time.
| pizza234 wrote:
| If one sets the requirement of having manual memory
| management in a mixed language, then:
|
| 1. either they don't use any library, including the
| standard one,
|
| 2. or the (standard) libraries must be written in both
| manual and managed memory management versions.
|
| Additionally, the language must include extra syntax for
| memory allocation and access. This doesn't event include
| safety-related semantics, like Rust, which would be very
| hard to bolt-in (language-wise).
|
| I hardly see any advantage in Java/C# having this
| functionality; Oracle is actually putting lots of effort
| into improving their garbage collectors. Java does actually
| have manual memory management (through Unsafe), although
| it's rudimentary; for the reason mentioned, I doubt it will
| ever be improved/expanded.
| vips7L wrote:
| C# has added a lot of control over memory layout. Span [0],
| structs etc. I am hoping they add more D like features
| (@nogc) to the language. Java itself has just made strides
| on reducing GC pause times [1].
|
| Granted, this isn't optional GC, but does D really give you
| that? Don't you lose the entire ecosystem and stdlib with
| -asBetterC? Why would I choose that over rust/zig/c++?
|
| FWIW, I am a big fan of D.
|
| [0] https://docs.microsoft.com/en-us/archive/msdn-
| magazine/2018/...
|
| [1] https://malloc.se/blog/zgc-jdk16
| aldacron wrote:
| > Granted, this isn't optional GC, but does D really give
| you that? Don't you lose the entire ecosystem and stdlib
| with -asBetterC?
|
| -betterC is not the only way to avoid the GC in D, just
| the most extreme. The original motivation for -betterC
| was to ease porting C code to D. Walter has used it for
| that to port a good bit of his old C code over. But it's
| also suited for the space in which the blog author is
| using it, and some people just prefer it. You always have
| access to the existing C ecosystem, but there are people
| writing -betterC libraries in the D ecosystem. And as
| more people use it, I expect that space will grow.
| echelon wrote:
| Back when D originally debuted, I couldn't separate it in my
| mind from C# and Java, despite the fact that you could manage
| your own memory. It felt like it fit into the same space, yet
| didn't have a compelling ecosystem. (Competing standard
| libraries did not help their case!)
|
| That's at least why I glossed over it.
| pjmlp wrote:
| Java and C# also offered similar capabilities when D
| appeared.
|
| Granted on Java side it required sun.misc.Unsafe, JNI or
| Real-Time JSR, while on C# side, a mix of structs,
| SafeHandle, MarshalInterop, unsafe and eventually C++/CLI.
|
| So while not as pleasant as D, the cost to drop those eco-
| systems wasn't worth the cost to switch, and now 10 years
| later those eco-systems have doubled down on improving the
| experience for low level coding.
|
| This makes it quite hard to sell D to those potential
| users.
| nicoburns wrote:
| Not different enough to be worth switching from Java/C++ with
| their much bigger and more established communities. This was
| especially true earlier in it's history when it required GC.
| Now it doesn't, but it has to compete with Rust which can also
| offer memory safety.
| Zababa wrote:
| But Go came and succeeded. Would you attritube this to
| Google's marketing, products like Docker/Kubernetes, or the
| simplicity of the language? Maybe something else?
| bachmeier wrote:
| > Not different enough to be worth switching from Java/C++
| with their much bigger and more established communities.
|
| Companies using Java or C++ don't switch because a language
| is "sufficiently different". I've been involved in
| programming language discussions for decades and I've never
| heard of a company switching to a language because it was
| different from what they were already using, though being too
| different is a common reason for _not_ switching.
|
| {For those not aware, D has intentionally kept compatibility
| with C as a priority, to the point that you can set a
| compiler flag and restrict yourself to "betterC". You can
| translate C code to D without making many changes to it.}
| pornel wrote:
| "Different" is not a reason to switch, but "not different
| enough" is a reason _not_ to switch.
|
| When switching is costly, the potential upside must be big.
| When the other language seems similar, the upside also
| seems limited. When there are few differences, you can
| rationalize staying with the old language, because it may
| catch up with the features, or you can emulate the missing
| features, or just live without them, if the differences are
| small.
| bachmeier wrote:
| This is getting into a fuzzy area where one person's big
| difference is another person's small difference. I'd
| consider D templates to be a small difference from C++
| templates in terms of the language[1] but big enough in
| terms of productivity that it would make sense to start a
| new project in D over C++ for that reason alone.
|
| [1] A random commenter on HN might well conclude that
| there's no benefit to D's templates without using them.
| mhh__ wrote:
| The D compiler speaks C11 now, it'll be ready for prime
| time in two or three releases based on speaking to Iain and
| Walter.
| WalterBright wrote:
| Just added C11 anonymous structs last night!
| mhh__ wrote:
| I saw, as long as the code stays clean I think we're
| going to be kicking ourselves this only happened now.
| aldacron wrote:
| Funkwerk, one of the first companies to adopt D back in 2008,
| switched their passenger information system from Java and C++
| to D. They weren't just on the look out for something
| different. They had a real problem to solve, tried out a few
| languages, and settled on D. They're still using it today
| (they moved from D1 to D2). And if you're riding certain rail
| networks in Europe, you're benefiting from it.
|
| https://dlang.org/blog/2017/07/28/project-highlight-
| funkwerk...
| CyberDildonics wrote:
| I think there are just two big factors - garbage collection and
| tools. When it was made garbage collection seemed reasonable,
| but with modern C++ and rust we now know that tracking
| ownership through different scopes solves the same problems
| very well with none of the downsides of garbage collection. If
| you look at D, Julia, C#, Java, Ocaml, etc. etc. over and over
| you see people eventually fighting with the garbage collection
| over throughput and latency.
|
| D to my knowledge has never fully transitioned to garbage
| collection being a thing of the past.
|
| For tools I think D fell into a common trap, which is to just
| keep working on the language itself. Eventually the lack of
| debugger, real time syntax checking and auto completion take
| their toll and something like C++ seems better even with the
| rough edges of the language itself.
| valenterry wrote:
| Honestly, I believe it is much more about marketing than one
| might expect.
| NationalPark wrote:
| That's kind of an uncharitable way to say, "Rust has a
| welcoming and beginner-friendly community". It's not like
| there's a marketing team buying Facebook ads.
| hu3 wrote:
| Rust had Mozilla blog posting about it for a long time.
|
| https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/
|
| Let's not pretend marketing is just paid Facebook/Google
| ads.
| mhh__ wrote:
| I don't know if I'd say beginner (an initio) friendly but
| we have some really clever people on our forums who have a
| lot of time for new people.
|
| There will be a book on dlang.org soon, that's the one
| thing I think we're lacking at the moment.
| Zababa wrote:
| I think that's your vision of marketing. Marketing by word
| of mouth because you really like a product is still
| marketing, and the Rust community is really good at that.
|
| The Rust community realized early that if they wanted to
| succeed, they had to talk about Rust a lot, show good
| examples, be beginner friendly to avoid people picking it
| up and dropping it quikly. But that "marketing" is also
| things like a really good package manager, really good
| compiler errors, a really good VSCode extensions. Many
| communities don't have this (especially the new ones) and
| this makes developing in Rust more of a joy than in let's
| say OCaml or even JS.
| MaxBarraclough wrote:
| Agree. I think this is one of the reasons Ada has seen (and
| continues to see) so little use.
| andrewflnr wrote:
| Ha, only unexpected if you haven't been watching how every
| other language adoption goes. Otherwise I agree. :)
| mhh__ wrote:
| The things that make D special - culturally even - are quite
| niche so while it's been extremely profitable for many who do
| use D, D is sometimes not an easy sell in the sense that the
| things that D makes easy are not things you encounter in the
| first few minutes of using a language.
|
| Also: Marketing, a lot decisions are made based on nothing,
| we're too modest (to be blunt).
| Corazoor wrote:
| 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 constructs, which puts you in a similar
| spot as with C++...
|
| And if you actually want a GC, you might find the simple linear
| allocator of D to be lacking...
|
| D is a very cool language, but it is also a lot like QTified
| C++... Which, well, already exists...
| WalterBright wrote:
| > 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 feature with lots of nice uses.
| Programming in D is not impaired by not using it.
| mhh__ wrote:
| I'm surprised you mentioned memory allocation without
| spotting the memory allocators in the standard library.
| Andrei designed the library and as far as I can tell no other
| language comes close when it comes to composable allocators.
| Corazoor wrote:
| I dunno why you assume that I don't know about them...
|
| Apart from that, they came pretty late, are still in
| experimental, and don't change the fact that only a subset
| of D is usable without GC.
|
| I very much like D, I really do, but I never encountered a
| usecase where the pros of using D outweight the cons. It
| sits in a very very weird spot design-wise, and while
| Walter and Andrei tried their best to get rid of the most
| common problems, not much of that effort resulted in actual
| useful change: Still no other GC than the default linear
| one, the stdlib is still not fully noGC usable (and
| probably never will), and "proper" compile time functions
| are still not done, after quite a few years now...
|
| Which is a shame, D is very close to being the perfect C++
| replacement.
| WalterBright wrote:
| If you don't want to use the GC, why the concern about
| its implementation?
|
| I have no idea what you mean by "proper" compile time
| functions. D's CTFE is excellent.
| crazypython wrote:
| Symmetry Investments, a $4.5bn assets-under-management hedge
| fund, sponsors Dlang.
|
| No major tech company behind Dlang.
| p0nce wrote:
| A company that probably understands risk-reward.
| mhh__ wrote:
| Symmetry are a bit bigger than that now. They use D
| extensively and it's been very good for them.
|
| Edit: Why am I being downvoted for repeating publicly
| available information?
| TheCondor wrote:
| A lot of people have mentioned a lot of reasons, marketing,
| corporate support, etc...
|
| I think a language technology needs at least one, but ideally a
| few, flag ship projects using it. It provides some examples for
| people to see, it shows the "why" and then it also connotes
| that it's living and good. I don't think it has to be big, just
| good. Ripgrep is a prime example, there are a few other smaller
| tools in Rust that are nice, well put together tools that do a
| nicer or better job than the old standards.
|
| You can talk about why something is nice or better, but
| actually showing people that it is probably convinces more.
| fock wrote:
| are there any schematics available?
___________________________________________________________________
(page generated 2021-06-01 23:00 UTC)