Re: Is @safe still a work-in-progress?
On Friday, 17 August 2018 at 07:19:25 UTC, Peter Alexander wrote: My question is: what is the status of @safe? I am quite surprised to see such a simple case fail. Is @safe believed to be fully implemented (modulo bugs) and this is just an unfortunate corner case, or is it known work-in-progress? Years ago (2012-2013 https://forum.dlang.org/post/xibbzslaunogifsom...@forum.dlang.org) I was arguing that @safe is crippled: 1) there is high probability that some loopholes are missing (several of them were posted to bugzilla and still not fixed since then) 2) fixing loopholes will make using @safe inconvenient. My point is somewhat different from expressed already here by Jonathan. He speaks about whitelisting/blacklisting and that the former model will always contain loopholes. In my view, the reason is that memory safety in (essentially good old C) memory model depends on runtime memory type which is unrelated to static type. Taking random variable - it can be allocated on stack, heap, GC-heap, thread-local and there is no way at CT to determine this in general case. In other words, static type rules is bad approach to determine memory safety. It can be used to detect some obvious bugs, but does not work across compilation boundaries. The better approach in my view is to insert runtime code which performs some tests (at least this how C# works).
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: I never ever (I think) did something provocative, something to finally see: ... My 5 cents inspired by experimenting with D some years ago. 1. Programming became niche oriented and quite diverse. Writing new language requires significant manpower. 2. D manpower is not sufficient for finishing language in low level niche. AFAIK Walter estimated manpower around 2013 to be equivalent of bus factor of 10. This is not enough to deliver stable language, it will always be "tasted as raw" comparing with c++. 3. D strategic mistake is ad-hoc design. Some features are added or extended and because of complexity result in corner cases (this is exacerbated because sometimes backward compatibility is preserved and sometimes not). Fixing corner cases sometimes produces more questions. As a result language has some mess which is unlikely to be fixed coherently (c++ is at least a documented mess). 4a. Limited developers' efforts are consumed by fixes and internal code optimization rather than important issues. 4b. Dips (related to language design) mostly fail because proposal authors do not write code and developers are busy. 5. My view of D future. Walter and developers will continue to improve and develop D but at low pace. Low-level niche will be dominated by c++ as a common denominator. D and some alternative languages would compete for different parts of this niche. In long-term low-level niche will be broken into smaller niches with languages specializing in them. Being "just low level" would be wrong as "just language". This would raise questions what D goal is. I am from area of economic, financial and scientific calculations used in decision making. It is dominated by python, c++ and statistical software. In most cases it does not require absolute speed (except financial markets rt trading, big data processing or some hard mathematical problems which are relevant for researchers in top institutions with supercomputers). It is hard for me to provide arguments for using D (meaning from professional area view) because c++ can be used for performance and D is poor in statistical libraries. Because it is applied area nobody cares whether exceptions have root class or whether virtual is default.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 19:26:23 UTC, Joakim wrote: On Monday, 4 June 2018 at 19:06:52 UTC, Maksim Fomin wrote: Unlikely, you don't spend $7.5 billion on a company because you want to send a message that you're a good dev tools company, then neglect it. You have no idea about how big corporations' management spends money. As with Nokia and Skype - I don't know whether it was initially a plan to destroy products or management was just silly. I suggest you look at their online slides linked from the Nadella blog post to see their stated plan, such as integrating github into VS Code more: http://aka.ms/ms06042018 and likely vastly overpaid for an unprofitable company in the first place :) this is exactly how such deals are done - paying $7.5 bl. for nonprofitable company. Unfortunately, their books are unavailable because they are private company, but scarce information in the web suggests that in most of their years they have losses. Just as rough estimate: to support $7.5 bl valuation Microsoft must turn -$30 ml. net loss company into business generating around $750 ml. for many years. There is no way to get these money from the market. Alternatively, the project can have payoff if something is broken and Microsoft cash flows increase by $750 ml. This is more likely... but they emphasize that they intend to keep github open and independent. They can claim anything which suits best their interests right now. Or, as alternative, github can be broken in a such way, that their promises on surface are kept. Business is badly compatible with opensource by design.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 08:42:08 UTC, Walter Bright wrote: On 6/3/2018 8:51 PM, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). We'll stay on Github as long as it continues to serve our interests, which it has done very well, and I have no reason to believe will change. We have a number of ties to Microsoft: 1. It's just down the street. 2. Many D users work at Microsoft. 3. Microsoft has always been helpful and supportive of Digital Mars, note the files licensed from Microsoft in the distribution. 4. Microsoft has invited myself and Andrei to speak at Microsoft from time to time. 5. Microsoft hosts the nwcpp.org meetings, which provide a venue for me to try out D presentations to a friendly crowd. 6. Microsoft has been generous with helping me solve some vexing compatibility problems from time to time. OK, so Digital Mars is in good relationship with Microsoft (I am surprised because have never heard about it). However, judging by Microsoft acqusition experience my prediction is that github will slowly but surely degradate (as suggested on some forums, everything will be firstly switched to Microsoft account - to track data, then everything will be mangled by ads, then some features deemed unnecessary by Microsoft will be removed, then linux will be badly supoorted, then some features incompatible with Microsoft services will stop working, then servers will start work poorly like skype...). P.S. My second reaction after reading news (after shock) was to visit D forum.
Re: D vs nim
On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote: Not so long as destructors don't reliably run. $ rdmd test.d A(1) constructed A(2) constructed A(1) destructed Caught: Constructor failed https://issues.dlang.org/show_bug.cgi?id=14246 Good catch. This is a variant of bug reported 5 years ago. The funny part of this bug is that the fix was reverted ... because of excessive code breakage. I like D pretty much and wish to use it in serious code, but I cannot tolerate such sort of things.
Re: Note from a donor
On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote: A person who donated to the Foundation made a small wish list known. Allow me to relay it: * better dll support for Windows. Andrei This should be better sent to Walter rather then here.
Re: D on Tiobe Index
On Thursday, 31 August 2017 at 16:37:35 UTC, SrMordred wrote: On Thursday, 31 August 2017 at 14:57:28 UTC, bitwise wrote: https://www.tiobe.com/tiobe-index/d/ What happened in 2009? My guess is constant random methodology changes. I was tracking TIOBE index each month from 2011 till 2016. I remember they announced changes in methodology in title page approximately once per 3-4 months. For example, changing the base from 100% to sum of percentages of all languages(<100%) increased reported % of each language. Taking this into account means that changes in particular month tells nothing. The trend is, however, positive: in 2014-2017 years D stands higher than in 2011-2014 (if you have faith in TIOBE averages). I see sometimes positive discussions about D at completely unexpected local tech sites. Although D's position becomes higher in TIOBE, I don't see progress in other statistics, for example in github.
Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum
On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote: On 8/4/2017 1:33 AM, RazvanN wrote: That could have never happened if they would have used D with @safe That's mostly true, but not absolutely true. 1. There can be bugs in D's @safe checking and inference. 2. Function interfaces (such as in C interface files) are labeled @safe or not, and the D compiler has no way to check. Hence, functions can (and have been) mislabeled. On the other hand, @safe does greatly reduce the attack surface. And as I've prognosticated before, the utter lack of machine checkable memory safety in C will herald the end of its use in anything connected to the internet. So, you agree that @safe cannot solve the problem because of C function interfaces and 'lack of machine checkable memory safety in C'. In this case, why does @safe relies on static analysis in CT and type inference when memory safety is determined by the 'C memory sate' at RT? Either @safe is wrongly presented (it is not memory safety tool, but something else) or (if the intention was to provide memory safety tool) it is a flawed feature. Of course, memory safety is impossible in C. In my opinion, D's @safe is wrongly marketed as a fully safety tool (look at a user above). This is dangerous, because leads to unfounded assumptions and later disappointment. By the way, I see that DIP 100 followed the same way - impose static type restrictions in CT to prevent memory errors. I believe, due to growing language complexity any combination of resctrictions can have loopholes. Back in 2013 I was collecting type system holes and posted them in Bugzilla after your request. It appears, that scope has its own loopholes too [1]. [1] https://issues.dlang.org/show_bug.cgi?id=17718
Re: The progress of D since 2013
OK. Thanks everybody for information!