Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Thanks, I'll try to write better documentation for my packages, maybe even rename my "bindbc" stuff so Mike Parker won't get harassed for my own stuff (bindbc-zstandard and bindbc-jsl).
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 17:29:29 UTC, Adam D. Ruppe wrote: On Thursday, 2 July 2020 at 17:19:31 UTC, claptrap wrote: and adrdoc? i think and they put everything onto its own page. Not even worth trying imo, that's why i wrote a replacement from scratch. adrdox could prolly be modified to do all one page, or just load the pages and embed after the fact. just im not sure if it has value tbh Tbh i much prefer the navigation on dlang, a tree view on the left, and a single page per module, but vastly prefer your presentation. The whole thing on dlang with putting everything in its own rounded outline rectangle with a red bar at the left hand side is hideous. Anyway I realise its a personal preference thing, and dont mean to criticise adrdoc, it's a big improvement.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 18:22:54 UTC, Dibyendu Majumdar wrote: So why was Java successful? It was not compatible with an existing language. Neither Rust nor Go are compatible with C++. Rust, D and Go are all compatible with C in some sense. Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy. There is no single recipe that will make a language successful. It's funny nobody has mentioned ease of use. Why is Java so popular? I'd say it's easy to use among other things. Why is Python so popular? Because it is easy to use and many can quickly learn it. Why is C++ so popular? It is or at least has been easy to use in its domain, at least if you use it conservatively and do not dig too deep into its language features. Ease of use is a big factor.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Nice article. Thumbs up!
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 10:21:19 UTC, Joseph Rushton Wakeling wrote: On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote: To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I think that's a misinterpretation of what was said. Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure. So why was Java successful? It was not compatible with an existing language. Neither Rust nor Go are compatible with C++. Rust, D and Go are all compatible with C in some sense. Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy. There is no single recipe that will make a language successful.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 17:19:31 UTC, claptrap wrote: and adrdoc? i think and they put everything onto its own page. Yeah, I find it is generally easier to read, search, and link this way. It does have an overview page for anything though you can skim through. Even a good tutorial on how to coax something useful from DMD would help. Not even worth trying imo, that's why i wrote a replacement from scratch. adrdox could prolly be modified to do all one page, or just load the pages and embed after the fact. just im not sure if it has value tbh
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ i think one problem is a default docs generated by DMD are goddamn awful. They actually look better if you delete the CSS at the top and have no styling. So i looked ddox? and adrdoc? i think and they put everything onto its own page. Better styling but tons of pages to click through, and some weird formatting in places. There should a flexible simple solution in the box. What we seem to get is a shitty default, and two bespoke options. Even a good tutorial on how to coax something useful from DMD would help. So i've kind of given up of documentation atm.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Excellent article. As the author of a moderately-popular dub package, I'm convinced that one of the reasons it's succeeded where other similar packages haven't is that I've made high-quality documentation a priority. For anyone interested in learning more about how to write good documentation, I've found the guide at writethedocs.org to be a good resource: https://www.writethedocs.org/guide/
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 16:04:20 UTC, Patrick Schluter wrote: [snip] Thank you. Really good and I hope devs here will follow your advices. It's needed. Agreed.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Thank you. Really good and I hope devs here will follow your advices. It's needed.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 13:03:12 UTC, Guillaume Piolat wrote: On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote: If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. That was how we did it for a while, the speed hit was immeasurable. Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit. I think my post was unclear, I'm saying keep the realtime thread hidden, just make sure any references are either duplicated somewhere reachable by the GC, or only give the real time thread malloced memory. Chances are almost all the memory the audio thread has references to will be referenced elsewhere anyway. And those that arnt, say a message object passed through a queue, just use malloced memory.
Post: Why no one is using your D library
Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 12:36:09 UTC, IGotD- wrote: On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote: If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute. The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway. You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use. Also see this... https://github.com/AuburnSounds/Dplug I think you can make a callback thread to D work if you have a trampoline function and then call thread_attachThis rt_moduleTlsCtor before calling the actual callback. Then the thread will be known to D runtime. Sorry maybe I was unclear, I'm saying keep the real time thread hidden from D runtime & GC. Just make sure any GC memory referenced by the real time thread is also referenced in the threads/data that is known about by the runtime / GC. Or only pass the real time threa malloced memory.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. Great talk. Similar to what I was trying to say in my DConf19 talk but in many ways better.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. Herb Sutter is a national treasure, C++ has become bearable, nay even useful, under his stewardship and that is really saying something
Re: Talk by Herb Sutter: Bridge to NewThingia
On Tuesday, 30 June 2020 at 11:12:22 UTC, aberba wrote: It requires someone with C++ knowledge to start, then we'll take care of driving in more idioms. Like a GitHub wiki or something. The D wiki more appropriately for centralization. Anyone up for it? D and C++ are VERY different languages: - D objects have different construction sequences and teardown sequences. In C++ when you can name an object you are guaranteed it is constructed. Not in D. - the meta-game of C++ meta-programming was template specialization for a long time, and is considered hard and something to avoid. For D it has been CTFE + string mixins for a long time, and is considered only moderately difficult. - D uses DUB, modern dependency management that can make you maintain a lot more programs that you thought possible ^^. C++ culture is pretty much again this convenience. - T.init is a valid D object, D destructors must handle T.init. - destructor of heap objects is a big trap in D, perhaps the biggest surprise when coming from C++ - D collections do not necessarily own their elements, and are generally less complete than C++ collecions. - D always has RTTI and Exceptions - the C++ culture is much more conservative since regular people that wanted some modicum of sanity have fled to Java/C#/Python/anything else for _two decades_. - mixed ownership (GC + manual) is more complicated than just scoped ownership; but ultimately liberating, and fast. - ...so you have to actually know how the GC work.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote: I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures. I work in audio effects, use no GC, and use OOP since TypeInfo is there. You are right about basic set of algorithm and data structure. If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. That was how we did it for a while, the speed hit was immeasurable. Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit. The problem with the D runtime can be (depends on when): - macOS compat in a shared lib - D host hosting D client can be tricky The point is even in C++ you should never ever do malloc/free in the audio thread Pet peeve, lot of practical audio applications do this (at startup) :) You'll find mutexes in the audio thread in the most well known audio frameworks... all of them since spinlocks-style algorithms have worse worse-cases. If the event is rare enough, it won't really matter and chasing it would be a lot of effort just to stay holier. But it's a good talk topic so regularly people will berate other about how it's a bad thing. Also see this... https://github.com/AuburnSounds/Dplug Note that we disabled the runtime (and GC) for reasons I cannot entirely collected, we've tried to enable it back several times and it's hard. D is very fitting for audio.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote: If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute. The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway. You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use. Also see this... https://github.com/AuburnSounds/Dplug I think you can make a callback thread to D work if you have a trampoline function and then call thread_attachThis rt_moduleTlsCtor before calling the actual callback. Then the thread will be known to D runtime.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 10:13:02 UTC, Dagmar wrote: On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote: Then don't turn it off. :) I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;) I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures. If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute. The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway. You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use. Also see this... https://github.com/AuburnSounds/Dplug
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 11:54:54 UTC, Cym13 wrote: On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote: It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :) Some people don't want to hear all that because implementing crypto is exciting. So I like to recommend this problem set instead: https://cryptopals.com/ It scratches the "I wanna write crypto" itch, and it makes the "custom crypto is easier to break than you might think" point really well. (By the way, your article had really good depth. I'm subscribing to your RSS :)
Re: Talk by Herb Sutter: Bridge to NewThingia
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote: To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I think that's a misinterpretation of what was said. Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure. I can't speak for Go, but Rust's compatibility is clearly adequate given how Mozilla is able to fit it inside the (mostly C++) Firefox codebase.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote: Then don't turn it off. :) I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;) I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures. OOPS: :) I fail to find a reference table that explains implicitly or explicitly deleted or defaulted fundamental C++ operations like the copy constructor. I agree, C++ is overcomplicated. That's the reason why I look at other languages. Yeah, accepting that kind of complexity but rejecting the GC is interesting. (I am not directing this to you but to most C++ programmers.) Not manual memory management is the main problem in modern C++, but its excessive complexity with thousands of nuances that simply do not allow you to write a program without hidden issues. TBH, I don't suffer bc I have to deal with memory management at all. I understand the point of GC advocates, but among other things, people choose C++ because it gives them more control. A good language should provide the ability to easily ADD a garbage collector, not the ability to cut it off, losing a half of the language features and its standard library. That may be true for many languages but when it comes to getting things done I find D much more productive, manageable, easier, etc. etc. compared to C++. C++ has only one thing over D: Many smart people are already using C++. D has lots of really interesting features and it's more productive than C++, but I find it hard to use in real projects. Although I agree that transitive const is the correct feature, I too find it difficult. Well, I agree that transitive const is a good feature for some use cases. For instance, a function may return a pointer to a constant linked-list node. In the case of non-transitive const you can reach and modify other list nodes through this "constant" pointer, which is not good at all. But introducing transitive const without showing a way to implement caching, using mutexes, etc is not a good idea either. Imagine a class, that protects its data with a mutex. How should I implement a getter function (const) that locks the mutex? The only way that comes into my mind is introducing a global mutex-manager entity that works with mutex handles (integers). Any class that requires a mutex would call this manager to create a new mutex and remembers its handle. This way it can pass this handle to the manager when the mutex should be locked/unlocked. But obviously, this is such a horrible scheme. There is this dated document: https://dlang.org/articles/cpptod.html Although dated, that document should be sufficient to jump to D from C++. :) Not at all. It's not so hard to learn the syntax and other details of a new language. It's hard to adopt it to my needs. This document tells nothing about typical issues that C++ programmers encounter with when trying to do a real work with D.
