Random points from a D n00b CTO
Hi all, I'm a CTO at a start up and interested in porting our Java project to D. Some points, I have been lurking on D for years, went to my first D conf recently. Also I was one of top 20 people to join Java Struts, and that grew to 3million plus end users so I have some 'cred'. Hope this helps: - Confusing forum. First listed forum on 'D' is not for D users, but it's called D! It is in fact for D commiters. This causes frustration for both users and commiters. (yes there is 'learn D' but it's 4th down. Commiters forum should be slightly hidden and user questions should not be answered in commuters but politely asked to post in the proper forum.). - I was *very* disappointed that using base library locks you into GC vs ref. counting. Separate, I like how Objective C has NSObject for GC purpose(I'd love a framework that is just ref counting), but there should be dual libs and base should not be GC. - D is/has become complex. metaprograming, generics, macros, etc. This is a culture issue, very hard to fix cultural issues w/o losing most commiters. Just a fast system lang w/o headers, 'boost' and such. All this other stuff can be 3rd party eco system and should be pushed out from D proper into implementations and add ons. - Dub rocks. - Very little 'user' outreach. Meetups such as 'learn D' (set up editor w/ DUB, and write some vibe.d DNS client/server in 4 lessons). Or how to use a c .so lib. So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not commuters) to rewrite the Java project in Dallas and/or San Jose (CA) over the next few months (Feel free to ping me @puppetMaster3, ideal candidate is 'prolific' and career programmer) Cheers, Vic
Re: Random points from a D n00b CTO
commuters = commiters. On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
Re: Random points from a D n00b CTO
bearophile, Inline On Monday, 14 July 2014 at 09:33:27 UTC, bearophile wrote: Are you able to sketch what kind of look you like for this page and show an image? Simple would be to put 'Learn D' first. Better would be that 'D' becomes 'Learn D' and new forum for D commuters is created with a new name and 'enforced'. What's the purpose of the rewrite? What do you hope to improve over the Java code? Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has become cheap to do that. I need a system programing lang to do that better. Also I need to bypass OS sometimes, for example talking to NIC libs. Third, by using system programing lag, I get to hire better programers, not the CLR and JRE types that don't know how assembly or how to call AVX2 instructions, etc. (and minor, just a bit harder to de-compile). cheers.
Re: Random points from a D n00b CTO
On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote: gig = gig of RAM
Re: Random points from a D n00b CTO
To illustrate point on D complexity: https://d262ilb51hltx0.cloudfront.net/max/800/1*_gRpHqzB-1zbG17jdxGPaQ.png It appears that it mission is to be Java, vs a system lang. hth On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
Re: Random points from a D n00b CTO
On Tuesday, 15 July 2014 at 17:15:08 UTC, Kagamin wrote: On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote: Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has become cheap to do that. Java can't hog gigs? Unbelievable. Java is the devil I know. But if D is not my first choice to port(from Java), than my second choice is Qt. It seems simpler to manage memory and Hash Associative Array. Any comments on Qt as choice?
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 12:35:29 UTC, Bastiaan Veelo wrote: I am not sure why you think Qt makes memory management easier. QObjects are generally given a parent that destructs its children when it terminates, but that is merely a convenience in GUI programming I think. Yeah, I don't know if Qt or D makes manual memory easier, but at some point I want to find out. So if any more input, great. I'd hate to have to hire like so: Ideal candidate knows some Qt AND D Lang. I'm not doing GUI, it's a socket server w/ large RAM. Also 'large', if the CPU has 30meg L3, I don't think 128Gig RAM is large anymore. Cheers, Vic
Re: Using D
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote: On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via I think we need to address these issues, because they are of a psychological nature and not really language issues. I'm sure that if we fixed GC and had the best implementation ever, people would find something else to complain about "D doesn't have blah, I don't like it!" I'm sort of getting the idea that D goal would to be a better Java. I'm running away from Java (after 10 years). I hope that someone at D has power and can say NO to a feature the way Linus does as opposed to adding more 'JCP' features, pushing such stuff downstream. Adding more features to be good at everything, aka a submarine that is a law mover. It's all done w/ best intentions. But forcing GC into base library of a system programing language? Maybe D is not a system programing language, but a enterprise app productivity lang. At least give us a choice, to use D why do I have to re-write the base lib. Cheers, Vic
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 16:10:30 UTC, Kiith-Sa wrote: Qt is an excellent framework, but pretty much completely irrelevant to memory management. Its object trees and refcounted containers are convenient for conventional programs, but if you are doing want to extract decent performaare with 100's of gigs, you'll need custom memory management, whether with D or Qt/C++ (and just like *some* parts of Phobos, Qt locks you into is types and whatever memory management they use. STL would make more sense but afaik it's allocator interface is quite a PITA) Thx Kiith.
Re: GCs in the news
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote: If D came without GC, it would have replaced C++ a long time ago! Agree +1000. If GC is so good, why not make it an option, have a base lib w/o GC. If I want GC, I got me JRE. It seems that some in D want to write a better JRE, and that just won't happen ever. Cheers, Vic
Re: Using D
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote: GC phobia is a convenient excuse for people to not use D, people who may have different actual reasons that they don't express for various reasons or may not even realize. Hi Walter, Please give us a bit more respect and benefit of the doubt and assume that we do know what we want when say something. I want to use D! I may be forced to C++ my team because GC built into the base lib. It is possible to build a base lib w/o GC I just am in a small company and can't afford to do that. Cheers, Vic
Re: GCs in the news
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote: On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote: If GC is so good, why not make it an option, have a base lib w/o GC. Much of Phobos already is GC free. The parts that aren't should be easy to convert to use user-supplied buffers. Please add enhancement requests for cases where there isn't a GC-free alternative to a standard library routine. If that is true, I may even do a $ bounty to make Phobos GC free. I may do the same, $ bounty on vibe.d port to GC free. I don't know D enough to be able to do that, but good news to me. Cheers, Vic
Re: GCs in the news
On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote: The quality of GC implementation is probably more important. I disagree, I am a burn victim and don't trust smoke. Ideally it is optional. Cheers, Vic
Looking to hire: 2-3 programmers, candidates will likely need to learn D.
(I hope OK to post:) Location: Silicon Valley /San Jose, CA/ or Dallas TX. Current 'app' version is mostly Java/Tomcat, so will need to maintain that while writing a new version, likely mostly D ( possibly Qt depending on GC ). (Also a few lines assembly, C, IOS Objective C, Andorid as clients) OS will be Gentoo flavor. There is some fun data structures and some boring HTTP in the project, I'll have to tell you more if you ping us, some of it is fun tech but I don't want it public. The company is a 7 digit funded start up, a bit more about the project - http://ceocfointerviews.com/interviews/Apakau14.htm Ideal candiate is a career programmer/developer, prolific coder would be supper. Experience prefered, a few years out of school might be considered. Company culture is tech friendly/introvert (as opposed to marketing/business type orgs). Market rate salary, but first few hire we don't have much for reloaction budget(not looking for remote for first year+). Of course 30" monitor, Xeon workstation, good vacation time, gym and more, of course D conference or similar is company expense. There are some trade secrets to keep. To have a phone chat, please email me your resume/bio to vic (at) apakau.com. Likely we will be done hiring in a week or 2. (I plan to cross post on Qt and Vibe.d forums)
Re: Looking to hire: 2-3 programmers, candidates will likely need to learn D.
Done, thx! On Monday, 21 July 2014 at 15:12:41 UTC, John wrote: You might want to post to D.announce group. Some D users claim they only check D.announce
(Off topic) Linus on GCC v4.9
http://lkml.org/lkml/2014/7/24/584
Re: Algorithms to solve programming contest problems
On Saturday, 25 October 2014 at 20:51:04 UTC, Walter Bright wrote: http://www.quora.com/What-are-the-algorithms-required-to-solve-all-problems-using-C++-in-any-competitive-coding-contest Anyone want to review these and see what we should add to Phobos? I have enormous respect for Walter, this has me betting my company on D. But how I wish this said: hey, anyone know of what we can remove from D or move to downstream? JRE has Oracle and 100 devs, CLR has MS and 100 dec, there are 7 for D, and it should be narrow, like LUA. It should have 7% of their platform. Majority of scared cows must be killed, the sooner leaders realize the better.
2 types of D users, both can live together happily if we adjust
There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments). The 'real project/core' is where we are ( http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable systems language. From 'real project' people, the people that are in the 'experimental platform' currently *shit* where we eat (as per my D programmers that work for me, D is big and unstable). As I see it, the issue is that D is a wide platform(not a small lang) that is hard to maintain with the size of the team. (Similar wide platforms feature wise are JRE and CLR, both w/ > 100 developers). So how many core D developers we have?(*) A more modern language like Go splits btwn stable 'core' and 'experimental feature platform', for example no need for core to have try/catch, when it can be done downstream: - http://github.com/manucorporat/try This is similar to Linux: kernel and gnu; and what I propose for D: to be split up. This would allow users of *real project* to use a core and people that want to have features could do that downstream: let a 1000 flowers bloom! If you are w/ me so far, how big/small should core be? *Small enough to be maintained by the size of the team at hand and no larger. * Something stable for us to lean on. Next, is it feasible to split? Std library has much bloat and is easy to split up into core and downstream experimental feature platform. That leave the compiler. I am not an expert, but this could be done w/ core 'compiler' and the rest in optional pre-processor. I think it can be done w/ backwards compatible (just switch GC to default off) I'll say 90% + should and must be moved to downstream projects. This allows for the famous quote: 'fearlessly peer into the gates of hell’ - all I’m saying do it downstream, let us build projects that can lean on small/simple and maintainable D core. Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split? http://tinyurl.com/q5t2eag
Re: 2 types of D users, both can live together happily if we adjust
I completely understand and support the DIY nature of Open Source and it's something that should be underlined often! If we turn out to be successful, I do plan to resource out D support. But I'm running a startup and don't have the spare cycles. But I am using D, betting the company on it, programmers in my shop do D 100% of time, so I do consider myself a part of the D community. So all I can do is wish for a small and stable D lang, vs a large D experimental platform - and both are possible. If I had resources I would divide Phobos and complier/pre-compiler to support the 2 camps: people that use D on real projects and people that want to experiment as I have outlined. I do think this to be key thing for the active D community to internalize as it relates to D wide adoption or disappearing: the size of project managed as it releases to FTE (~2000 hrs/year) resources that maintain it. Manifested mostly as http://en.wikipedia.org/wiki/Feature_creep or instability (is my code wrong or is it D ) On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via Digitalmars-d wrote: On Thu, Nov 27, 2014 at 10:58:31PM +, Vic via Digitalmars-d wrote: There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments). [...] The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place. While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums. Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens. So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively. T
Re: 2 types of D users, both can live together happily if we adjust
Yes, that is one example of something that could be a downstream feature with alternative implementations. On Friday, 28 November 2014 at 01:29:16 UTC, weaselcat wrote: On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad wrote: The @nogc focus got in by "external" advocacy. It did take some noise, but it got in. It took a lot of noise and IMO rust removing their GC to force something to happen.
Re: 2 types of D users, both can live together happily if we adjust
inline: On Friday, 28 November 2014 at 05:14:31 UTC, Mike wrote:As I see it, D has a lot of contributors willing to maintain and enhance it, but the barrier to entry and learning curve is quite high for anything significant. I say there is very few. I have to challenge your data that there is a lot of contributors. Most projects list their maintainers, what is the number of FTE D maintainers? That is a loaded question of course, relative to surface area: http://dlang.org/comparison.html of sacred cows relative to FTE maintainers. Therefore, the number of contributors that actually make a significant difference is quite small. Also, since it is a volunteer effort, there's really not much accountability. Contributors are free to make significant contributions, and then leave the D scene without anyone able to maintain their work. Contributors are also free to do partial implementations, and move onto something else without completing what they started. I think anyone wishing to leverage D for a critical project should be aware of that, and perhaps D should be more transparent about it. That doesn't mean D shouldn't be used for anything of importance, it just means that by using D we enter into an implicit contract requiring us to either be willing to become significant contributors ourselves, or be willing to partner with and fund D's development. How much $ funding so I consider it? For example for regressions to be done but only for core. (none of silly things, which is a long list of GC, AssociaveArrays, demangle, annotations, higher order functions, pseudo members, transmogrify, goto, try/catch, vardic, traits, variant, sqllite, etc. I am not saying to remove them, just make them downstream like GNU does, not part of regression tested D core. If I wanted to use a big lang I'd do CLR or JRE. When I first approached D, I had high expectations, and as I learned more, I also became disappointed Yes, that is the pattern. Come in, and leave. There has to be more people staying and more D shops (like my shop is pure 100% D ). The regressions are painful, and I propose a way to let people experiment and compete on rich features. My proposal is to make a small stable core that can be maintained, so that people say. and said a few things I this forum I wish I could take back. I misunderstood the culture of this community and how it works, and perhaps I still do. But what is more apparent now is we can't expect to rely on D if we're not willing to make significant contributions ourselves, or fund its development. And, while using D is itself a small contribution, it's not enough. Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split? I would like D core to be small as well, but for different reasons: I would like a nimble language that can be used for both the smallest and largest of machines, and let the libraries differentiate. But, I don't think it should be partitioned based on the size of D's human resources, partially because that is going to fluctuate drastically throughout time. Rather, the division should be made based on architectural and design goals. The culture of the D contributes is 'to bravely peer into gates of hell' - as in experiment. As user of D I want it to be small, stable and maintained. I proposed a path that allows for both, w/o scaring of people that use D for real projects. If that is not so, then I missed that D is an experimental language. You might consider doing what other organizations have done: Allocating your D talent to fix the problems you have encountered by submitting pull requests, or open issues and place bounties on them at https://www.bountysource.com/teams/d/issues. Regardless, I'd still be interested in knowing, more specifically, what problems you're encountering. Mike My problem: I have 3 developers(still hiring more) that work for me please lets not use D, it is not stable release to release (and has a bunch of things no one needs). I told them: we are a D shop because long term I anticipate D and Walter to succeed. So I hope that maintainers consider users of D and not chase them away. Vic
Re: dmd test coverage
On Thursday, 27 November 2014 at 11:32:59 UTC, Martin Nowak wrote: Actually not too bad :). https://dlang.dawg.eu/coverage/ https://coveralls.io/r/MartinNowak/dmd Good step.
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 07:17:48 UTC, weaselcat wrote: IMO rust got it right with immutable by default, but hindsight is grand(To be fair, rust lifetime management is really ugly too) Immutable as default sounds good (in core)
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 11:59:36 UTC, bearophile wrote: and the lack of a rich set of libraries because of bit rot. This is not a valid argument. The lack of D libraries has various causes, probably the main one is the lack of D developers and the lack of their interest in keeping the code updated (perhaps because they have left D community?). ouch.
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 02:59:07 UTC, Mike wrote: and the lack of a rich set of libraries because of bit rot. Yes, D's current business model is not sustainable. It is lacking capable contributors and funds to keep the code maintained. Mike Agree.
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 11:56:31 UTC, Ola Fosheim Grøstad wrote: I got very happy when Walter announced "@nogc" and his intent to create a "better C" switch on the compiler. I felt this was a nice change of direction, but I also feel that this direction has stagnated and taken a turn for the worse with the ref-counting focus… Phobos is too much of a scripting-language library to me, too much like Tango, and hacking in ref counting makes it even more so. To me, a "better C" would have a minimal runtime, a tight minimalistic standard library and very simple builtin ownership semantics (uniqe_ptr). Then a set of supporting libraries that are hardware-optimized (with varying degree of portability). agree.
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 11:35:52 UTC, Paolo Invernizzi wrote: On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote: I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old. I've lost my faith in expecting to see the D core team grasp what the so called "break my code" folks aims to reach. -- Paolo Yup.
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 14:40:47 UTC, Ola Fosheim Grøstad wrote: With a big standard library you get this effect: big monolithic standard library -> other libraries build on it -> many libraries are unsuitable for more restricted applications big monolithic standard library -> hard to keep bug free, performant and makes language changes more difficult What you want is this: tight standard library -> other libraries build on it if they can-> more libraries are suitable for all applications tight standard library -> high degree of stability -> less breakage of other libraries tight standard library -> better results for library-aware optimizations +1 Clearly D is not a "better C", it's a "better C++/Java". You can use D as a "better C" but this needs some adaptation, both for you and the libraries. It is a bit of false advertising to on website promote D as better C, when the efforts are that it is a better C++/Java/CLR. (and I think you can do both w/ a split).
Re: 2 types of D users, both can live together happily if we adjust
On Saturday, 29 November 2014 at 15:46:03 UTC, Ola Fosheim Grøstad wrote: If this is a long term strategy then this makes D unsuitable for contract work. You really don't want any uncertain factors when bidding on a contract since that will skew your estimates. Stability is more important than features in a commercial setting. yes
Re: Phobos - breaking existing code
On Saturday, 29 November 2014 at 11:37:52 UTC, bearophile wrote: Some of this "hibernation" could be caused by the latest "revolution" threads by Andrei. But probably there are also other causes. Yes, Andrei's ref counting and C++ compatibility, etc. There are choices in debate to push: a) Make D small system lang. b) or Keep D large I say there is more choices: c) Both! Split it like linux: kernal and GNU. kernal is of no use w/ out cd and cat, etc. This way people like Andrei can help even people that use D on real projects. In C++ we have active downstream, ex: http://pocoproject.org/features.html. D gets stronger because of Vibe.d. That can be encourage by spliting/reducing D 'core' to be near useless, w/o a lib for key needed features that are in pre-compiler and downstream ecosystem. Win/win. Andrei's of the world could and should be encouraged as the 'GNU' of D. I am saying 90% of 'D' should be in 'Andrei' domain and all the sacred cows. I'd call the non-core 'D' 'frontal lobe', the part that thinks and D 'core' the 'lizard brain' that is just primitive/visceral. Else the endless debate of large vs small. I say both. Cheers, Vic
Re: 2 types of D users, both can live together happily if we adjust
On Friday, 28 November 2014 at 23:06:15 UTC, Mike wrote: On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote: this has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade. Amen. Here is the problem w/ that: Lets stay that we use GDC (because of debugger) equivalent of D 2.066(or whatever) for ~ year. In essence, we check out of the D community. And when we come back, we find that the D community pool has not grown (due to some of the challenges we found). This means our project is not developed in an unsupported language, and we have to port. (In forums I see maintainers talking about GC in core. I think that hooks for ref. counting should be in core, but move the implementation for the average case downstream. Plus many other things. To me, as a manager, figure out what your resources to be good at it, and no more). I want to D, and the only way I see that is smaller D and the only way I see that is via a split so that the pool can grow. Cheers, Vic
Re: LogLevel [was std.experimental.logger formal review round 3]
(I don't want to hijack the thread, and I'm so happy for donated hours. If I my just touch on that JRE size maintenance team did not add logging till 1.4 http://www.onjava.com/pub/a/onjava/2002/03/06/topten.html - instead people used downstream. Pardon me)
Re: D Meetup in SF?
http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there.
Re: D Meetup in SF?
On Saturday, 6 December 2014 at 01:37:03 UTC, deadalnix wrote: On Friday, 5 December 2014 at 20:08:30 UTC, Vic wrote: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. Is that new ? I was unaware of this. Not sure I'll be able to come as I have no car, but I'll try to figure out something. If you Cal-Train, we will pick up at station.
Re: D Meetup in SF?
On Saturday, 6 December 2014 at 09:12:30 UTC, Shammah Chancellor wrote: On 2014-12-05 20:08:28 +, Vic said: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. I was thinking of something in SF proper, but Sunnyvale may be possible for me. -S We can co-ordinate Caltrain schedule and have somoneone pick up at the train station.
Re: Do everything in Java…
On Saturday, 6 December 2014 at 16:23:46 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 03:48:42PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2014-12-06 at 07:14 -0800, H. S. Teoh via Digitalmars-d wrote: > […] > Oh, I *know* there are Javascript testing frameworks out > there... > the problem is convincing people to actually incorporate > said tests > as part of the development process. Sure, *I* can run the > tests with > my own code changes, but there are 50-100 developers working > on the > project who are also constantly making changes, and unless > they also > regularly run unittests, the whole exercise is kinda moot. If the team is 50 to 100 programmers 1 of whom thinks testing is a good idea then I can see an unmitigatable disaster looming and the technical bosses (*) being sacked. Best bet, get a new job now. (*) management and accounting bosses never get sacked, because it is never their fault. [...] Disaster *looming*? Haha... disaster has been *happening* for the past how many years now... Hence my earlier references to regressions spiralling out of control and new features breaking old ones like there's no tomorrow, and developers scrambling like mad to fix them all in a whack-a-mole bid to bash the product into shippable form by the deadline, of which we tend to be informed the week of (or sometimes, the Friday afternoon before a Monday deadline)... Fortunately(?), no one has been sacked yet. Part of it may have to do with the fact that practically all our customers are corporate, and corporate customers tend to value business relationships and deals above actual product quality, even when they're on the receiving end. (Just my cynical guess, though. I have no concrete evidence of this. :-P) T +1,000 ( D scope should be smaller than C. JRE/CLR should be of limits. Also this one dude(Linus) talks about a big lang(C++) and it's advocates: - http://harmful.cat-v.org/software/c++/linus I'm sure he he has no credibility /s )
Re: What is the D plan's to become a used language?
> We have : - a huge cemetery of D project + 1 What to do: - Stop to add new feature in D (new annotation or whatever is not an urgent needs) +1000. But this is not the culture of the creators. They think adding features is fun. Vic blog.apakau.com - company built on top of D in Silicon Valley
Re: Questions at D reddit (benchmarks game, D worms)
In a world of limited resources, one can chose to have one good supported community, or 2 poorly supported communities. On Friday, 19 December 2014 at 01:06:12 UTC, Kiith-Sa wrote: Noticed 2 non-bot threads at Reddit (sorry for spam, but due to all D talk being here newcomers may get the impression of a dead community), maybe someone here is able to answer them? https://www.reddit.com/r/d_language/comments/2ppxya/is_there_any_interest_in_writing_algorithms_in_d/ https://www.reddit.com/r/d_language/comments/2pov92/worms_in_d/
Re: What's missing to make D2 feature complete?
As a commercial user (but non contributor) of D, here is my suggestion: - remove GC and memory management as default - find all features that are not being maintained or are just top heavy and deprecate. - find features that should or could be downstream, and deprecate. Vic - http://www.quotationspage.com/quote/26979.html On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. For me it's these 3 points. - tuple support (DIP32, maybe without pattern matching) - working import, protection and visibility rules (DIP22, 313, 314) - finishing non-GC memory management
Re: What is the D plan's to become a used language?
First, thank you all the committers for a 'gifted free' lang that we use to build a company, we could have used any lang, we chose D. My point is on 'management' more than on 'software'. On management, *EVERY* project is resource constrained, so imo, D should figure out what resources it has at hand. Based on that prioritize what can be maintained and what can't be maintained and hence marked as deprecated (so those that do care for it can move it downstream). It's painful to kill many scared cows. I used example or CLR and JRE team size relative to their 'features surface area'. Also, I'm pleased that 'no' is said at times (but ... we are still adding things right, w/o saying: and if we add that, what are 2 features we can move downstream?'. Last I'm hearing is Andreii will gift C++ compatibility, etc into core. **: reason to split up forum into users and public comitters so people like me don't panic) Cheers, Vic ps: Second smaller thing I 'elude' to but don't verbalize in that argument is my personal preference for a smaller language. Less is better/faster. I proposed to move those deprecated features 'downstream', just like Linux Kernel and Linux GNU are separated (but can't exist w/o each other). To build an eco system. (here is comments on C++ having more features, one of the reasons I like smaller http://harmful.cat-v.org/software/c++/linus I do see 'featuritis' http://bit.ly/1wzVPMR as a way to doom projects in a compound way ) As to Walter (yes I used Wacom c compiler) saying No, I think he is to nice and 99.5% is not good enough, I'd like him to be a mean - http://www.brainyquote.com/quotes/quotes/l/linustorva141511.html and start removing things. The list of candidates is long, GC has been brought up as something that can be moved downstream. D could have reference counters in base classes, but end users could INJECT a 3rd party GC mechanism they like. It's same thing, but downstream. Also I showed example of Go exceptions being downstream. I'm not saying these 2 (our of 100) are not nice features, I'm saying if 'we' were forced, they could be moved downstream. You can just open Andreii's D book table of contents and find over weight things - if you are motivated to do that. On Friday, 19 December 2014 at 16:44:59 UTC, Joakim wrote: On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath wrote: On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote: On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote: As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;) You don't need to be around the D community forever to feel that D still has too many features that made it in. Care to name a few and justify why exactly those features should be gone? No, as that's not really my problem. I was simply trying to clarify the argument others have made, that the language seems overstuffed and overwhelming, which I have experienced at times but I'm not personally complaining about.> It is a worthless claim to make that there is too much of something, if you cannot come up with an concrete example. "I've got that gut feeling, that" is not even remotely an argument and just kills time of everyone in this discussion. If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal. I have no dog in this fight. I was merely pointing out to Walter and Mike that it's possible to say "no" a lot and still have others wish you had said "no" even more. :) There's no particular feature that I wish wasn't there, though of course there are many features that many wish were implemented or worked together better, as deadalnix points out. When Vic suggested a split into a stable core and an experimental layer, I suggested documenting the perceived stability of various features instead, so that users could have a guide for what features might be more problematic without having to do a deep-dive in bugzilla to figure it out for themselves. I didn't back a split or have not suggested removing features.
D lang sillicon valley pre-planning meeting week of 12th
Respond/participate here: http://www.meetup.com/D-Lang-Sillicon-Valley/messages/boards/thread/48587409
ot: vibe.d forum
vibe.d forum is down, can't post messages.
Re: What is the D plan's to become a used language?
I think you nailed the argument. On Sunday, 21 December 2014 at 09:36:00 UTC, Dicebot wrote: On Saturday, 20 December 2014 at 19:11:53 UTC, Vic wrote: Second smaller thing I 'elude' to but don't verbalize in that argument is my personal preference for a smaller language. Less is better/faster. I think this is the main reason why we have different perspective on necessity of change. Smaller language simply means that you need to put more complexity into actual applications and while D looks all cool at the first glance trying to get deeper (== implement BIG projects) inevitably makes you encounter fundamental design quirks that affect maintenance costs. Deadlnix has provided pretty good list of suck problematic points. While there is some value in splitting the spec into core language and extensions I don't believe it is wise for D to compete in simplicity domain. Core and extensions/ plugins is a way to manage complexity and resources. I cite some 'random dude' http://www.codingninja.co.uk/best-programmers-quotes : "Controlling complexity is the essence of computer programming." I am a user of D, and I need something stable to lean on - if I don't know the bug is what I wrote or what the compiler wrote, it gets harder. Further D does not have choice but to be excellent (via simplicity) - there is not enough paid maintainers. (Struts what I worked w/ before was written in 48 hours and had several million 'users/developers' using it). So the pain of limited resources forces excellence. D does not have a choice but to make GC a DI/IOC - it will happen as the only choice, popular or not. People can be upset about the sacred cow or be confident of the outcome. I am in the second case. Alternative is death and I am optimist the committers will be forced to trim down. Vic
Re: What is the D plan's to become a used language?
I assume in order for your company to be happy in using D, you'd want it work, right? That is all I'm saying as well, lots of git examples and commercial projects using D. And I'm not saying to remove *any* features at all. I'm saying *MOVE* some features, tbd. For example Linux has Kernal and GNU, who cares where in git they sit, right? (but GNU needs a working Kernal). The example I linked(do you have it?) is like a more modern/younger language GO has exceptions. Or w/ GC, DI/IOC a 'generic' GC that makes you happy. But it does not make you sad to have an eco system, right? Anyway, you have to hear maintainers start saying/doing things to make things more maintainable before you can worry, since I am not a committer my opinions ads up to 0 basically in open source world. (if I was, I'd fork it until 'CW' catches up and backports it). Vic On Monday, 22 December 2014 at 01:08:00 UTC, ZombineDev wrote: NO. Just don't use features that you don't understand or like, but don't punish happy D users by demanding a crippled D version. On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote: ...
cross post hn: (Rust) _ _ without GC
https://news.ycombinator.com/item?id=8781522 http://arthurtw.github.io/2014/12/21/rust-anti-sloppy-programming-language.html c'est possible! Oh how much free time and stability there would be if D core *moved* GC downstream. Vic ps: more cows waiting for slaughter: http://dlang.org/comparison.html
Re: cross post hn: (Rust) _ _ without GC
On Monday, 22 December 2014 at 22:02:46 UTC, ketmar via Digitalmars-d wrote: On Mon, 22 Dec 2014 12:28:16 + . what we really need is a better GC, not "no GC". I am not saying no GC; I am saying: a) something needs to be moved out of core. If not GC, what would you move downstream? b) move, not remove. So you can plug in any gc implementation you like - the current GC if you still like it. Like linux kernal needs gnu to do 'cd'. hth, Vic
Re: DConf 2015?
On Tuesday, 23 December 2014 at 00:25:33 UTC, Walter Bright wrote: On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote: On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but Looks like it'll be May 27-29. By the way, who ever is co-coordinating this can also get help from SV D meetup and likely Berlin and help each other.
Re: cross post hn: (Rust) _ _ without GC
On Tuesday, 23 December 2014 at 00:49:57 UTC, anonymous wrote: On Monday, 22 December 2014 at 23:21:17 UTC, Vic wrote: I am not saying no GC; I am saying: a) something needs to be moved out of core. And many don't agree. Dear Anonymous, IMO D needs to be more stable, the alternative is more and more features and less and less commercial users and followed by less maintainers that don't want a dead project to work on. D 'marketing' brings people in, who then leave. So I proposed: Do like GO does w/ Exceptions ( I can send link again if need) *What* would be another way to get stability that is not fantasy? I consider the surface area of features vs available volunteer maintainers at hand. If you are not sold, look at CLR and JRE features relative to D features. Now look at the size of their maintenance teams as relative FTE. Does that look as sustainable? Hence a prediction: major things will be moved out of core to 3rd party plugins to slim down the lang, because now it's more than a lang: it is a platform. Vic
Re: cross post hn: (Rust) _ _ without GC
On Tuesday, 23 December 2014 at 04:06:33 UTC, ketmar via Digitalmars-d wrote: On Tue, 23 Dec 2014 03:32:11 + Vic via Digitalmars-d wrote: Hence a prediction: major things will be moved out of core to 3rd party plugins to slim down the lang, because now it's more than a lang: it is a platform. D is not a platform. besides, GC is a core feature of D. As per http://en.wikipedia.org/wiki/Java_%28software_platform%29 Java is a platform as per wikipedia. D, I'll argue has more features. Hence: D *IS* a platform. It is obese. Instead of 'what if academics didn't write a language, but a compiler writer writes a language, the new culture is: academics are writing a sugary platform. (and do they use it on projects, a big part of open source is that you use what you write, at their day job their team use something else). D 'has' a 'GC' for certain 'values' of working. Data point: My company has 6 *full* time Sr Developers (15 years +) in Silicon Valley - one of the larger commercial D users(sad) - so I say that we use D (and only D) and for heavy lifting month in and month out. So when all 6 tell me GC does not work (for example allocate a large associative array and run a few threads - I may present this example at the 'D meetup silicon valley' in Jan meetup and publish example in git). So I tell you, when I see focus of the volunteer maintainers on 'what can I add' and not on 'what can I remove' it scares me to the bone as the CTO. Difference w/ Linus and Walter? Both are smart, Walter is a nice guy, and not a bastard. So if maintainers decide that one of the thing to move is GC, one way,not the only way, is IOC | DI pattern (you can look up DI and IOC), it's doable, but it is like watching a fat person run 10 yards, they would rather eat a donut). Leave the method(init, destroy) hooks and ref counting in core. People(p/t users of D) than inject the default GC(amateurs by definition as they don't get paid to D). So it would be just like now. Professional teams/commercial users write a GC that fits that situation, possibly create a D utils open source project - and now you have an eco system of downstream open source projects and commercial users doing heavy lifting in D and 3rd: the corner case of people that use D just a little a few hours a week for a few weeks in a year. But, I don't know I'm saying move GC, I'm saying move somethings. Exceptions like GO, the 12 generics features are sugary, etc. just open up Andreii's book and go to town. If it's not GC, remove something else to the point it is maintainable and commercial users can lean on a working D. I am saying lots of things should be moved, ex: split the compiler into core and pre-compiler for the academic but still needed plugins. Also, people, I' am a user, so I'm just wagging the tail. Listen to the maintainers as to the future direction, I focus on bigger or smaller as the leading indicator of weather forecast of future stability in D. I'm hearing C++ compatibility will be added, and nothing will be removed. I'm hearing other features being added. Did anyone hear of something being moved downstream? Nope. God forbid users of D have to go to another git repo to get something they require. Vic
Re: cross post hn: (Rust) _ _ without GC
On Tuesday, 23 December 2014 at 14:39:30 UTC, ketmar via Digitalmars-d wrote: mind if i say that i don't give a shit about what "commercial users" want? and the last thing i want is cutting out language features. yes, "moving out of the core" == "cutting off". half-baked feature annoys people, so eventually somebody will do something with it. non-existant feature will remain non-existant for a long time. and i have a great way to know what "commercial users" really wants: the things they are paying for. no, that's not working like "do what we want and maybe we'll give you a cent or two". it's quite contrary, actually: "here's the money we'll pay for what we want". FOSS is not the box to which you shouting and then magically pulling the results for free. Hi Ketmar, 1)I quote me: "How much $ funding so I consider it?" here in D form- http://tinyurl.com/ks7z9jy 2) http://www.meetup.com/D-Lang-Sillicon-Valley This is us hosting and operating it, I hope people join 30 members so far for the first meet up in Jan. 3) I pay salaries for 6 full time D users, who use D. So I hope you do care about D, and hence we have to work together. I have a suggestion that one can have lots of features w/ stable core, both. Adding features will not work, that is a fact that some don't see. Moving them is painful, no question about that. Current situation is we are stuck, ex: " Anyone want to review these and see what we should add to Phobos?" from http://www.digitalmars.com/d/archives/digitalmars/D/Algorithms_to_solve_programming_contest_problems_246363.html#N246363 Cheers, Vic
Re: DIP66 has been approved contingent to a few amendments as noted
http://wiki.dlang.org/DIP66 One more feature. On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu wrote: Congratulations, Igor! -- Andrei
another feature added: C++ compatibility
Coming soon to *upstream*: http://tinyurl.com/myc8h9y
Re: My wish for 2015...
On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote: I'm going to make a stark proposal to the you all, the community and all D users as whole. I wish for us to set an ultimate goal to be made top priority and complete by the end of next year. My wish is to resolve the issue of memory management for D by the end of 2015. This is a significant issue that has affected most of us at one point or another. I think this gives D a bad rap more than anything else and is a point of contention for many, especially those with a background in C/C++. I think the problem of memory management can be reduced to two points: (1) The garbage collector for D is sub-par. (2) There are too many implicit allocations in Phobos. I think three goals need to be met for the problem of memory management to be satisfied: (1) We need a precise garbage collector. The fact that a garbage-collected language experiences memory leaks truly reflects poorly on on D. (2) Furthermore, we need to improve the performance of the garbage collector. There are some things the developer can do to reduce the time and frequency collection cycles, but the current situation is far from optimal. (3) We need a viable alternative to the garbage collection. Whether that be allocators, ref counting, or full-fledged manual memory management, there is great demand for the ability to use D without the GC with little hassle. I sincerely believe that this is the greatest issue facing D today and something that should have been resolved a long time ago. The fact that relatively simple programs can crash with out-of-memory errors (especially 32-bit executables) and high-performance code experiences frequent or lengthy collection cycles means we have a bad situation on our hands. Things like @nogc are a start but much more needs to be done. I'm not hoping for an optimal solution, nor am I expecting a state-of-the-art garbage collector. I think we should simply aim for "good enough". Then once we have a better memory management scheme, we can begin incorporating these changes into Phobos. What do you all think? Can we make improving memory management the top priority for 2015 with the goal of developing an adequate solution by the end of next year? +1. Seems like a reasonable compromise. (but to be a negative Nancy: to be realistically achieved: it must be the only goal and w/ a laser focus. D community still has to demonstrate discipline, here is an inspiration: http://youtube.com/watch?v=iYWzMvlj2RQ ). Still cheers and hope, Vic
D mention w/ LLVM on hacker news.
D mention on hacker news: https://news.ycombinator.com/item?id=7800445 #dlang re LLVM
Andrei on Channel 9
http://channel9.msdn.com/Blogs/Charles/Conversation-with-Andrei-Alexandrescu-All-things-D-the-language-?utm_source=dlvr.it&utm_medium=twitter
Can't implement conformant memset/memcpy without compiler -ffreestanding support
Current implementation of compilers assumes libc implementation, which leads to an infinite loop if we want to implement primitives like memset with our own code because the compiler will optimize consecutive set with "memset". This suggests that we cannot write a freestanding program without supports from compiler. With "-betterC" flag, ldc also comes into this issue, which also applies to C/C++[1] and rust [2][3][4]. gcc and clang provides an option "-ffreestanding" to bypass optimizations that need libc support. Although we can hack around this issue by making our implementation complicated enough/using assembly to bypass the optimizer, it would be better to provide a standard flag like "-ffreestanding" for all compilers to disable such optimizations, so that developers won't have to hack around different compiler implementations. [1] https://godbolt.org/g/5gVWeN [2] https://play.rust-lang.org/?gist=64f2acafa8cec112893633a5f2e12a9a&version=stable&mode=release&edition=2015 [3] https://github.com/rust-lang/rust/issues/10116 [4] https://github.com/thestinger/rust-core#freestanding
Re: Can't implement conformant memset/memcpy without compiler -ffreestanding support
Minimal example in D: https://run.dlang.io/is/EYVTzb. Affects at least dmd and ldc.
Re: Can't implement conformant memset/memcpy without compiler -ffreestanding support
On Wednesday, 25 July 2018 at 09:16:19 UTC, rikki cattermole wrote: On 25/07/2018 8:59 PM, Zheng (Vic) Luo wrote: Minimal example in D: https://run.dlang.io/is/EYVTzb. Affects at least dmd and ldc. https://run.dlang.io/is/8tPOVX Note that switch void* to ubyte* won't matter once its extern(C)'d. My version (_memcpy_impl2) is just the regular old memcpy without optimizations. Your example is syntax sugar for a function call. There is no guarantee that a compiler (in a future version or after enabling some optimization flags) will not optimize _memcpy_impl2 into "call memset". Maybe it just happens that the optimizer is not smart enough to optimize this, because nothing with -beeterC prohibits the compiler to do so.
Re: Can't implement conformant memset/memcpy without compiler -ffreestanding support
On Wednesday, 25 July 2018 at 09:16:19 UTC, rikki cattermole wrote: On 25/07/2018 8:59 PM, Zheng (Vic) Luo wrote: Minimal example in D: https://run.dlang.io/is/EYVTzb. Affects at least dmd and ldc. https://run.dlang.io/is/8tPOVX Note that switch void* to ubyte* won't matter once its extern(C)'d. My version (_memcpy_impl2) is just the regular old memcpy without optimizations. Your example is syntax sugar for a function call. A naive implementation of memset also lead to "call memset": https://run.dlang.io/is/k3Hl04
Re: Can't implement conformant memset/memcpy without compiler -ffreestanding support
On Wednesday, 25 July 2018 at 09:37:56 UTC, rikki cattermole
wrote:
You misunderstand.
It isn't optimizing anything.
You requested the call to memcpy, explicitly when you said 'I
want this copied ASAP'.
By the looks, the spec doesn't clearly explain this properly.
Well, it seems that this is not a good example to show. I didn't
notice its semantics :)
A naive implementation of memset also lead to "call memset":
https://run.dlang.io/is/k3Hl04
Okay yup, that is an optimization.
This won't optimize:
extern(C) void* memset(ubyte* dest, int val, size_t count) {
immutable c = cast(ubyte)val;
foreach(i; 0..count) {
dest[i] = c;
}
return dest;
}
And yes the name is important :)
First, IIRC, the name hacking is a technique used to bypass llvm
optimizers, I'm not sure if it also applies to gdc. Moreover, I
think this *is* a hack around compiler because this forces memset
implementer to write all code in that function.
