Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:21:39 UTC, Joakim wrote: In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". I find that hard to believe: we are talking about a technical tool here. How many times have you been in this conversation: -- - What language are you using? - D. - I know next to nothing about D. - Oh, it's very good, I even built a business on it! list of arguments and features>. - Oh no thanks. I should try Rust, it's secure, fast, modern blah blah; facts don't matter to me. But in reality I won't even learn a new language, I'm happy with a language without multi-threading. -- It happens to me ALL THE TIME. This pattern is so predictable it's becoming boring so now I just keep silent. What happens? Rust / Go have outmarketed us with words. The battle (of marketing) is on words not technical features, Rust happen to own "programming language" + "safety", what do we own? D is good in all kinds of directions and the marketing message is less simple. The leaders choose to own the word "fast" (see our new motto "fast code, fast" which is very accurate) and it's important to get aligned. Also, regardless of how languages are chosen as they get into the majority, D is very much still in the innovators/early-adopters stage: But the current state of D would very much accomodate the middle-of-the-curve adopters. The language rarely breaks stuff. People making money with it, making long-term bets. Hell, I could make a laundry list of things that are better in D versus any alternatives! That doesn't bring users. With people like that, it's almost impossible to get them in the early adopter stage. They will only jump on the bandwagon once it's full, ie as part of the late majority. There is a gap where we are, but "People like that" are almost everyone. Those people actually are middle-of-the-curve adopter, if you see a true late adopter in the wild it takes 3 relatives programming in D so that they start to be interested. Who doesn't want to be out of the early adopter stage, and get into the "officially endorsed safe choice" cohort? D is remarkably ready as a safe choice for lots of software. Given how well it did on HN/reddit/lobste.rs, I think Vlad's gamble probably paid off. We can't run the counterfactual of choosing a safer title to see if it would have done even better, let's just say it did well enough. ;) Alternative darker view: ever remarked how D articles often goes downvoted on HN? The title who says something bad about D is upvoted ; it's easy to see events as going our way. I, for one, didn't really read the article. Who has time for that?
Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:21:39 UTC, Joakim wrote: I agree that it was a risky title, as many who don't know D will simply see it and go, "Yet another slow compiler, eh, I'll pass" and not click on the link. Whereas others who have heard something of D will be intrigued, as they know it's already supposed to compile fast. And yet more others will click on it purely for the controversy, just to gawk at some technical bickering. I don't actually think it was risky. What are the odds that someone was going to start using D for a major project but then changed her mind upon seeing a title on HN or Reddit? Probably very small that even one person did that. On the other hand, it says a lot of other things: - There's an active community that cares about the language. - It's not a dying language. - Fast compilation is a realistic possibility. - There are users with the technical ability to make the compiler faster. And then there is always the fact that there was a story on HN/Reddit about D. It's hard for publicity for a language like D to be bad when so few people use it.
Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:00:36 UTC, Guillaume Piolat wrote: On Thursday, 22 November 2018 at 04:48:09 UTC, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that. Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else. If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose. Please don't get me wrong, it's an excellent article, a provocative title, and fantastic work going on. I didn't meant to hurt! In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". I find that hard to believe: we are talking about a technical tool here. Also, regardless of how languages are chosen as they get into the majority, D is very much still in the innovators/early-adopters stage: https://en.m.wikipedia.org/wiki/Technology_adoption_life_cycle That is a very different type of sales process, much more geared towards what the new tech can actually do. Actually no less than 3 programmer friends came to (I'm the weirdo-using-D and people are _always_ in disbelief and invent all sorts of reasons not to try) saying they saw an article on D on HN, with "D compilation is slow", and on further examination they didn't read or at best the first paragraph. But they did remember the title. They may rationally think their opinion of D hasn't changed: aren't we highly capable people? With people like that, it's almost impossible to get them in the early adopter stage. They will only jump on the bandwagon once it's full, ie as part of the late majority. I'm not making that up! So why is it a problem ? HN may be the only time they hear about D. The words of the title may be their only contact with it. The first 3 words of the title may be the only thing associated with the "D language" chunk in their brain. The associative mind doesn't know _negation_ so even a title like "D compilation wasn't fast so I forked the compiler" is better from a marketing point of view since it contains the word "fast" in it! That's why marketing people have the annoying habit of using positive words, you may think this stuff is unimportant but this is actually the important meat. Reasonable people may think marketing and biases don't apply to them but they do, it works without your consent. I agree that it was a risky title, as many who don't know D will simply see it and go, "Yet another slow compiler, eh, I'll pass" and not click on the link. Whereas others who have heard something of D will be intrigued, as they know it's already supposed to compile fast. And yet more others will click on it purely for the controversy, just to gawk at some technical bickering. Given how well it did on HN/reddit/lobste.rs, I think Vlad's gamble probably paid off. We can't run the counterfactual of choosing a safer title to see if it would have done even better, let's just say it did well enough. ;)
cachetools v.0.0.1
Hello, I released cachetools - package with @safe and @nogc cache and hashtable implementations. It inherits nogc propery from key toHash and opEquals methods and can store immutable keys and values (with restrictions). Currently implemented only LRU cache with TTL. http://code.dlang.org/packages/cachetools https://github.com/ikod/cachetools Performance of underlying hash table seems to be better in my benchmarks in comparison with std associative arrays and with emsi containers (see https://github.com/ikod/cachetools/tree/master/testhash ) Test inserts and lookups int[int] = |std | 303 ms, 541 μs, and 3 hnsecs| GC memory Δ 41MB| |c.t.| 181 ms, 173 μs, and 2 hnsecs| GC memory Δ 0MB| |c.t.+GC | 184 ms, 594 μs, and 5 hnsecs| GC memory Δ 16MB| |emsi| 642 ms and 120 μs | GC memory Δ 0MB| Test insert, remove, lookup for int[int] === |std | 327 ms, 982 μs, and 1 hnsec | GC memory Δ 17MB| |c.t.| 229 ms, 11 μs, and 7 hnsecs | GC memory Δ 0MB| |c.t.+GC | 240 ms, 135 μs, and 4 hnsecs| GC memory Δ 16MB| |emsi| 678 ms, 931 μs, and 9 hnsecs| GC memory Δ 0MB| Test inserts and lookups for struct[int] === |std | 468 ms, 411 μs, and 7 hnsecs| GC memory Δ 109MB| |c.t.| 392 ms, 146 μs, and 1 hnsec | GC memory Δ 0MB| |c.t.+GC | 384 ms, 771 μs, and 5 hnsecs| GC memory Δ 88MB| |emsi| 1 sec, 328 ms, 974 μs, and 9 h | GC memory Δ 0MB| ... Thanks for bugreports and proposals.
Re: D compilation is too slow and I am forking the compiler
On Thursday, 22 November 2018 at 04:48:09 UTC, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that. Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else. If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose. Please don't get me wrong, it's an excellent article, a provocative title, and fantastic work going on. I didn't meant to hurt! In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". Actually no less than 3 programmer friends came to (I'm the weirdo-using-D and people are _always_ in disbelief and invent all sorts of reasons not to try) saying they saw an article on D on HN, with "D compilation is slow", and on further examination they didn't read or at best the first paragraph. But they did remember the title. They may rationally think their opinion of D hasn't changed: aren't we highly capable people? I'm not making that up! So why is it a problem ? HN may be the only time they hear about D. The words of the title may be their only contact with it. The first 3 words of the title may be the only thing associated with the "D language" chunk in their brain. The associative mind doesn't know _negation_ so even a title like "D compilation wasn't fast so I forked the compiler" is better from a marketing point of view since it contains the word "fast" in it! That's why marketing people have the annoying habit of using positive words, you may think this stuff is unimportant but this is actually the important meat. Reasonable people may think marketing and biases don't apply to them but they do, it works without your consent.