Re: two points
On 02/09/2017 01:08 AM, Joakim wrote: I agree that "coercion," or more accurately the tyranny of the default, is the dominant factor in language popularity even today, but you're reaching when you apply that to web frameworks too. Fair enough. It was just another example trying to make the point that "if you want to do X, then you have little choice but use Y" is, as you say, the dominant factor in language popularity. I can grant that the web framework examples are weaker examples. D's problem on the client is that the popular platforms are still very much tied to certain favored languages: iOS - ObjC and Swift Android non-game apps - Java Android games - C/C++ Windows - C# or C++ Web - Javascript Three of the four major client platforms all allow other languages (with the fourth starting to with WebAssembly), but you're often fighting the tide if you choose a non-default language so most don't bother. That's a good way of explaining it, I like that. We can make the dev experience more pleasant on those platforms, as I believe has happened now that we support the MS toolchain on Windows, but D is unlikely to become popular without a killer app that demonstrates its suitability. That's not coercion, but something we can actually control. I hope you're right, but I worry that even "killer app example" may not be enough, and that the lack of one may turn out to be just another red herring excuse for "why aren't using D". After all, I think vibe's approach to server development comes very close to "killer app" yet, far as I've seen, it doesn't appear to have proven a major win for D so far. Then again, having D in the "my secret weapon" category has certain benefits, too, so I guess I can't be TOO sour ;) On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote: I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir. You're right, in theory. But Mike is unfortunately very right about the whole "suffer an eternity in pull request purgatory." I fixed an issue where "///"-style doc comments resulted in excessive paragraph breaks...must've been over a year ago. Simple fix for a nagging bug. The fix worked. Caused no problems. No controversy. And to this day, just went completely ignored despite my periodic nagging about it. Eventually got tired wasting my time babysitting the constant need for rebasing and manual merge fixes just for something that proved guaranteed to be ignored. And any PRs I have managed to get through were all uphill battles the whole way. We have far too high a threshold for letting things actually happen. It didn't used to be that way, and that was a key reason why D became as good as it's gotten in the first place. So I'm not surprised people familiar with D go to lengths to avoid putting the effort into PRs that are much more major than my comparatively trivial PRs: It's proven to come with a depressingly high likelihood of turning out to be a complete waste of time. At the risk of sounding hyperbolic, I think this is D's next biggest problem after the lack of any "If you want to do X, your only real choice is D". Though I admit I might be a little biased on this particular point though.
Re: Questionnaire
On Wed, 08 Feb 2017 18:27:57 +, Ilya Yaroshenko wrote: > 1. Why your company uses D? You might have specified that this questionnaire is only for people who use D at work. I use D for small utilities to help in development. For instance, I used vibe.d to compare performance with other frameworks when I had performance concerns. > 2. Does your company uses C/C++, Java, Scala, Go, Rust? We use Java, Kotlin, and some C/C++. > 3. If yes, what the reasons to do not use D instead? On the client side, we're building for Android. Some of it is native, and it would not be a natural fit to use D (minor modifications in Android platform code that's written in C/C++). We use Swagger and Thrift for service definitions. Thrift supports D; Swagger does not. We use AWS. There is no AWS client library for D and it would not be cost- effective to implement one. If we want people to learn a new programming language for the JVM, they probably know Java already, and the rest of the ecosystem is identical. With D, the ecosystem is entirely difficult. Java has NullPointerException, while D has a segmentation fault. It's easy to catch NPE and harder to handle a segmentation fault, even if you are just trying to log and exit. The "die on error" trend has me worried that it will be difficult to run services with reasonable uptime, and the people saying that we shouldn't even try to log anything in the face of an error worry me even more. I can't run systems in production if I'm not allowed to log errors. The runtime doesn't even promise to make an effort to let me catch an Error. > 2. Have you use one of the following Mir projects in production: No. > 4. Have you use one of the following Tamedia projects in your > production: I've never even heard of them before. Have they ever thought of going into advertising? > 5. What D misses to be commercially successful languages? The backing of a large organization. The example of Go shows me that a language can become successful despite its technical attributes with the backing of a large organization.
Re: Beta D 2.073.1-b1
On Thursday, 9 February 2017 at 00:31:17 UTC, Martin Nowak wrote: First beta for the 2.073.1 point release. This version resolves a few regressions and bugs in the 2.073.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.073.1.html Please report any bugs at https://issues.dlang.org -Martin https://issues.dlang.org/show_bug.cgi?id=17162
two points
I'm not going to fill out the questionnaire because I'm not at a company and have not tried Mir, but two points about what Nick and Mike wrote. On Wednesday, 8 February 2017 at 20:40:48 UTC, Nick Sabalausky wrote: Coercion (and perceived coercion[1] for that matter) makes technologies popular far more than any other factor. The computing sector is NOT a meritocracy, not by a longshot. That right there is D's #1 biggest marketing flaw, period. If you nail that coercion part, it doesn't matter HOW badly you do on any other technical or marketing aspect. Been proven time and time again. And if you DON'T have that coercion, you face an uphill battle no matter how good you do on technical and marketing fronts. Also been proven time and time again. I agree that "coercion," or more accurately the tyranny of the default, is the dominant factor in language popularity even today, but you're reaching when you apply that to web frameworks too. As you admit, rails didn't become as big as it might have because there were quickly many other web frameworks, ie languages and frameworks on the server are very competitive and that market is very fragmented, though PHP is likely the biggest. D's problem on the client is that the popular platforms are still very much tied to certain favored languages: iOS - ObjC and Swift Android non-game apps - Java Android games - C/C++ Windows - C# or C++ Web - Javascript Three of the four major client platforms all allow other languages (with the fourth starting to with WebAssembly), but you're often fighting the tide if you choose a non-default language so most don't bother. We can make the dev experience more pleasant on those platforms, as I believe has happened now that we support the MS toolchain on Windows, but D is unlikely to become popular without a killer app that demonstrates its suitability. That's not coercion, but something we can actually control. On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote: I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir. Now, you may not want to go do this on your own if you believe it's a lot of effort, could use a design the core team may not approve, and don't want to maintain or develop your own fork indefinitely, but that's a lot of "if"s. I doubt it would be a lot of effort to strip D down like this, but I have not looked into it.
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language a,d 2. Does your company uses C/C++, Java, Scala, Go, Rust? We use the C++ alaso. we have C++ for writeing the Client by Qt. 3. If yes, what the reasons to do not use D instead? No reasons to use D instead. 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice No. 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. 4. Have you use one of the following Tamedia projects in your production: a. https://github.com/tamediadigital/asdf b. https://github.com/tamediadigital/je c. https://github.com/tamediadigital/lincount a, we use the asdf in hunt. 5. What D misses to be commercially successful languages? Not has distinct orientation。 and update slow。 6. Why many topnotch system projects use C programming language nowadays? The GC。 and if not GC , D only has a little.
Re: Boston D Meetup 2/17: `shared` Experiences
On 1/30/17 4:48 PM, Steven Schveighoffer wrote: Attention fellow Boston D enthusiasts: I have set up a meetup for February, and Michael Coulombe will give a presentation on his experiences with shared. As before, this will be at the Capital One Cafe in the back bay (across from Prudential center). Hope to see you all there! https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/ FYI, this has been postponed, we are supposed to get 8-12 inches of snow lasting all day tomorrow. I have rescheduled for next Friday, 2/17, which is the only day I could book. -Steve
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko
wrote:
1. Why your company uses D?
a. D is the best
b. We like D
c. I like D and my company allowed me to use D
d. My head like D
e. Because marketing reasons
f. Because my company can be more efficient with D for some
tasks then with any other system language
I use D only privately so far.
2. Does your company uses C/C++, Java, Scala, Go, Rust?
I've seen C, C++, and Java being used.
3. If yes, what the reasons to do not use D instead?
Nobody ever heard of the language (this holds true pretty much in
every discussion I have on the topic)
2. Have you use one of the following Mir projects in production:
a. https://github.com/libmir/mir
b. https://github.com/libmir/mir-algorithm
c. https://github.com/libmir/mir-cpuid
d. https://github.com/libmir/mir-random
e. https://github.com/libmir/dcv - D Computer Vision Library
f. std.experimental.ndslice
No.
3. If Yes, can Mir community use your company's logo in a
section "Used by" or similar.
N/A
4. Have you use one of the following Tamedia projects in your
production:
a. https://github.com/tamediadigital/asdf
b. https://github.com/tamediadigital/je
c. https://github.com/tamediadigital/lincount
I've used asdf for configuration files[1][2], it works very well
for shortening development time.
5. What D misses to be commercially successful languages?
My two cents:
- "Name" backing by a well-known (i.e. internationally famous)
corporation/foundation
- Viral marketing ("spread the D")
- Fix or removal of all the little things that may make someone
go "ugh, wtf?". I'm looking at you, `shared`, and your missing
memory barriers[5], or you, `std.parallelism.taskPool`, and your
non-daemon "daemon" threads[6]. Privately I can work around them
since it's my own time, but I don't expect many people in big
companies (see first point) with a deadline to want to put up
with that.
- Tooling, though that's been getting better
- Phobos without GC (where possible)
- std.experimental.allocator -> std.allocator and promote it as
*the* memory management interface for D. Seriously. With it I can
even allocate and pass delegates to C in an intuitive way (see
[3] and [4]).
6. Why many topnotch system projects use C programming language
nowadays?
Don't know if the premise holds, but if it does I'd wager it's
because people who *do* write topnotch (system) software can do
so in *any* (system) language that's asked of them - since in the
end the topnotch comes from the person writing the code, not the
language ("ignorance (of a language) can be remedied, stupid is
forever") - and C has the de facto corporate monopoly of being
asked to write in.
[1] https://git.ucworks.org/UCWorks/dagobar/tree/master
[2] https://git.ucworks.org/UCWorks/tunneled/tree/master
[3]
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L125
[4]
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L159
[5] https://dlang.org/faq.html#shared_guarantees
[6] https://issues.dlang.org/show_bug.cgi?id=16324
Beta D 2.073.1-b1
First beta for the 2.073.1 point release. This version resolves a few regressions and bugs in the 2.073.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.073.1.html Please report any bugs at https://issues.dlang.org -Martin
Re: Questionnaire
On Wednesday, 8 February 2017 at 22:52:36 UTC, bpr wrote: On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote: Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that? First, for that to happen, the D leadership would need to chime in with a plan on how they want to address this problem. Second, for me to allocate any more of my resources, I'd have to be convinced that their plan is a good solution to the problem. A -betterC switch is not at all attractive to me. I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved. I'd love to see a D3, but that seems unlikely, and more unlikely if D2 languishes. It seems though that your issues are with the implementation, not the language itself, so if you got your wishes below Instead I suggest following through on things like https://issues.dlang.org/show_bug.cgi?id=12270 and considering this proposal (http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead. wouldn't you be mostly satisfied with D2? Correct, my issue is not really with the language, but with its implementation. Resolving issue 12270 and implementing my proposal for decoupling the compiler and druntime would prompt me to further explore D. I'd also like to see how the recent DIP25 and DIP1000 could be leveraged. I'm looking forward to an article on the topic, or Walter's talk at DConf2017 before I dedicate any of my time to it. At first glance, however, it seems like a lot of attribute patchwork. It's become apparent to me that D just hasn't been designed with bare-metal systems programming in mind, so I'm skeptical that even if issue 12270 and my decoupling proposal were implemented, I'd still run into other disappointments. But I'd at least be willing to give it another try, and would be thrilled to be proven wrong. Mike
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: All my current D project are finished. Probably I will use other languages for production this year, Java/Go/whatever. N... I Guess I'll have to try to convince you to help with DCompute once the necessary compiler stuff gets merged into LDC.
Re: Questionnaire
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote: Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that? I believe D has the potential to bury all other emerging languages out there, but only if it drops its historical baggage. At the moment, I'm of the opinion that D will remain an obscure language until someone forks D and takes it in a different direction (unlikely), or the D Foundation decides to "reboot" and start working on D3 with a new, updated perspective (more unlikely). I'd love to see a D3, but that seems unlikely, and more unlikely if D2 languishes. It seems though that your issues are with the implementation, not the language itself, so if you got your wishes below Instead I suggest following through on things like https://issues.dlang.org/show_bug.cgi?id=12270 and considering this proposal (http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead. wouldn't you be mostly satisfied with D2?
Re: Questionnaire
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? We don't use D. 2. Does your company uses C/C++, Java, Scala, Go, Rust? C/C++. Currently exploring Rust. 3. If yes, what the reasons to do not use D instead? * The powers that be in my company are the kind of C programmers that can't understand why anyone would want to use C++ (i.e. Electrical engineers that write software). Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 * Our customers don't use D. Some of our products are libraries and tools that our customers use. It doesn't make sense to program them in D if our customers don't use D. Though, if D had a minimal runtime, we could write them in D and distribute them with bindings to other languages. * For us, binary size efficiency and minimal runtime are important features. D is not pay-as-you-go; many heavy-weight features are opt-out instead of opt-in. In contrast Rust has "minimal runtime" as one of its pillars making it a much better alternative language choice for us than D. 2. Have you use one of the following Mir projects in production: No 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. N/A 4. Have you use one of the following Tamedia projects in your production: No 5. What D misses to be commercially successful languages? I believe D has the potential to bury all other emerging languages out there, but only if it drops its historical baggage. At the moment, I'm of the opinion that D will remain an obscure language until someone forks D and takes it in a different direction (unlikely), or the D Foundation decides to "reboot" and start working on D3 with a new, updated perspective (more unlikely). 6. Why many topnotch system projects use C programming language nowadays? Which topnotch system projects? * C is the lowest common denominator. All modern languages that I'm aware of can interface with C. If one wants to write a library for mass adoption, the best way to do so is to write it in C and create bindings for other languages. D could be a good substitute for this if it had a "minimal runtime" philosophy. * C is a simple, efficient, and powerful language. Some equate language complexity and heavy runtimes to bloat and inefficiency. Some see too much language complexity as an impediment to productivity. C creates the appearance of simplicity with efficiency. * "Minimal Runtime" is the building block of systems programming. If this is not a core feature of a language, it will never compete with C. Systems programmers in my field need to incrementally opt-in to features in a pay-as-you-go fashion to make precise tradeoffs for their unique requirements and hardware platforms. Rust is the only modern language that I'm aware of that's getting this right. * You may also be interested Dan Sak's recent talk "extern c: Talking to C Programmers about C++": https://www.youtube.com/watch?v=D7Sd8A6_fYU=2631s
Re: Questionnaire
On 02/08/2017 01:27 PM, Ilya Yaroshenko wrote: 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language x. Because I'm self-employed so I get to choose the best tool for the job instead of whatever some know-nothing manager thinks "must be good because its popular". Also, all of the above. 2. Does your company uses C/C++, Java, Scala, Go, Rust? Not when I can help it. 3. If yes, what the reasons to do not use D instead? If, for whatever reason, my hands are tied and it's just not a possibility. Usually platform/framework compatibility. Or somebody above me deciding "You must use language X". (But, after having had more than enough PHP/VB/Java/C++/Python/etc in my life, I'm more inclined now to simply avoid situations that would involve such restraints. Life's too short to suffer bad tools for bad reasons.) 2. Have you use one of the following Mir projects in production: No. I keep hearing about Mir, but still haven't quite wrapped my head around what it is, or how/where to use it. (and that bugs me) 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. N/A 4. Have you use one of the following Tamedia projects in your production: a. https://github.com/tamediadigital/asdf b. https://github.com/tamediadigital/je c. https://github.com/tamediadigital/lincount First I've heard of them. I'll take a look. 5. What D misses to be commercially successful languages? A groupthink mentality and loads of bad ideas and broken reasoning. Ie, the basic requirements for anything to be popular in the computing arena. Seriously. I'm not joking. Well, that and, nobody's ever really been in a situation where they're more or less FORCED to use D. Many, heck probably most, big-name languages got big because there were enough people who didn't have much of a choice: - Earlier days of Unix/Linux dev? Hard to avoid C/C++. - Work for a company that's heavily invested in MS tools? Hard to avoid VB (90's) or C# (2000's). - Work for a non-MS-based enterprise? Hard to avoid Java, because that's what the higher-ups had already been sold on. - Need to use a relational DB? SQL, period. - Need client-side scripting on a web page? JavaScript, period (until just recently). - If you wanted an MVC web framework, for a short while Ruby was the only choice. I guarantee Ruby would be more popular today if that time period had been longer. It's undeniable nobody would've ever heard of Ruby were it not for Rails. - Need to run something on an affordable commodity server in the late 90's/2000's? PHP, period. Unless you paid an extra $5-$10/mo. and restricted your choice of providers - then you could use VBScript/ASP, which was basically the same exact thing as PHP, but just incompatible. - Need low-level hardware access, memory management or other direct control over performance and resource usage? Until recently, had to be C/C++. Then once onboard, stockholm syndrome sets in. Instant popularity. Coercion (and perceived coercion[1] for that matter) makes technologies popular far more than any other factor. The computing sector is NOT a meritocracy, not by a longshot. That right there is D's #1 biggest marketing flaw, period. If you nail that coercion part, it doesn't matter HOW badly you do on any other technical or marketing aspect. Been proven time and time again. And if you DON'T have that coercion, you face an uphill battle no matter how good you do on technical and marketing fronts. Also been proven time and time again. [1] The "I must keep up or get left behind" thought train. See also "Cover Fire" and the Fire and Motion stuff here: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ 6. Why many topnotch system projects use C programming language nowadays? Partly inertia, but also because there was a decade or two (that only ended a few years ago) where nearly all language designers obsessed over VMs and eliminating low-level capabilities, and in general dumbing down their languages to the point of uselessness for anyone but novices, hobbyists, and those who could afford to throw money/hardware at any and all performance/resource/scalability issues[2]. Because of that, for many C/C++ users, there simply was no realistic alternative, period. [2] I'm sure 90's Sun LOVED their JVM/Java - it virtually guaranteed "optimization" could only mean "rent/buy more hardware" - Everything else besides reducing algorithmic complexity was deliberately banned by both the language and the VM...as a self-proclaimed "feature" no less. That "feature" allegedly being for safety, but decades of security patches and exploits for every VM on the planet proved that to be a load of...male cow.
Re: Questionnaire
Plus, it can be enchanted during the GSoC 2017. EDIT: enhanced
Questionnaire
1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some tasks then with any other system language 2. Does your company uses C/C++, Java, Scala, Go, Rust? 3. If yes, what the reasons to do not use D instead? 2. Have you use one of the following Mir projects in production: a. https://github.com/libmir/mir b. https://github.com/libmir/mir-algorithm c. https://github.com/libmir/mir-cpuid d. https://github.com/libmir/mir-random e. https://github.com/libmir/dcv - D Computer Vision Library f. std.experimental.ndslice 3. If Yes, can Mir community use your company's logo in a section "Used by" or similar. 4. Have you use one of the following Tamedia projects in your production: a. https://github.com/tamediadigital/asdf b. https://github.com/tamediadigital/je c. https://github.com/tamediadigital/lincount 5. What D misses to be commercially successful languages? 6. Why many topnotch system projects use C programming language nowadays? = All my current D project are finished. Probably I will use other languages for production this year, Java/Go/whatever. Mir libraries are amazing and good quality. If you use them this would be a good motivation for us to improve the docs and provide regular updates. Plus, it can be enchanted during the GSoC 2017. Thanks, Ilya
Re: vibe.d 0.8.0 and 0.7.31 beta releases
Am 08.02.2017 um 11:30 schrieb Kagamin: On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote: Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee. The problem is that there are two affected call stacks - the @system API function that registers the @system callback, wrapping/casting it as @trusted, and the event handler that later on actually calls the callback. The latter place is where the hidden violation of the @safe guarantees happens. First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise. Being @safe-compatible and provide @safe guarantees are different issues. The latter follows from the former if user code is @safe and doesn't follow otherwise. True, but that goes a bit beside my point. I was just arguing in favor of the @safe system in general here, not about this particular instance. And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component. -boundscheck=on should do it, ldc provides even more control how code is compiled. True, but that also imposes this restriction on all user code, while just requiring -boundscheck=safeonly would enable dependent packages to make a choice (aside from manually sidestepping boundschecks in code). And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state. Fake @trusted annotations don't count as adoption of safety. Pedantically speaking @safe loses its purpose if @trusted code is not verified. Especially if fake @trusted becomes a habit. That's why safety can't be forced and is opt-in. I agree with the pedantic statement, but not with the conclusion. Right now it's simply not possible in practice to write either fully compiler checked code or fully audited trusted code on a large scale. But starting to work towards a fully compiler checked code base makes all of the missing spots visible, so that there is more pressure to actually fix them. I was actually considering to open PRs for each instance, but it quickly became clear that it were too many places for me to be able to do that in a reasonable time frame (also, @trusted is still necessary to support old compiler versions), so that had to be postponed.
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote: Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee. First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise. Being @safe-compatible and provide @safe guarantees are different issues. The latter follows from the former if user code is @safe and doesn't follow otherwise. And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component. -boundscheck=on should do it, ldc provides even more control how code is compiled. And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state. Fake @trusted annotations don't count as adoption of safety. Pedantically speaking @safe loses its purpose if @trusted code is not verified. Especially if fake @trusted becomes a habit. That's why safety can't be forced and is opt-in.
