On Friday, 22 December 2017 at 18:59:34 UTC, John Gabriele wrote:
I'm new to D. Coming primarily from Python these days, I'm
looking at D not as a better C++ (haven't used that in many
years), but as a better Python.
I'm quite similar. New to D (been using it for a month now). I
see it as a b
When I wanted something like
static if (enum var = expr)
{ ... }
I did
static foreach (enum var; { auto x = expr; return x ? [ x ] : [
]; }())
{ ... }
The only drawback is, there is no `else`.
You can use the trick even for normal if when the condition is
not identical to the expre
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder
wrote:
I think we are now in a world where Rust is the zero cost
abstraction language to replace C and C++, except for those
who are determined to stay with C++ and evolve
On Fri, Dec 22, 2017 at 06:21:04PM +, Russel Winder wrote:
> On Fri, 2017-12-22 at 09:42 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> > that are a pain to manage. Yes I know dub does it "automatically",
> > but the problem with dub is that it tries to do too much -- it wants
> > to be a b
On Fri, 2017-12-22 at 09:42 -0800, H. S. Teoh via Digitalmars-d wrote:
[…]
> that are a pain to manage. Yes I know dub does it "automatically",
> but
> the problem with dub is that it tries to do too much -- it wants to
> be a
> build system in addition to being a packaging system. The former is
>
On Friday, 22 December 2017 at 17:42:57 UTC, H. S. Teoh wrote:
The main reason I went to vibe.d was because of HTTPS support,
that cgi.d didn't have.
You shouldn't be running a homemade HTTP server in public. The
way you should do it is putting the application behind a real web
server (you ca
> On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote:
> > 0. Since when did you or company start using D in this area?
Unfortunately I'm presently not able to use D at my job.
[...]
> > 1. Do you use a framework? Which one?
I've used Adam Ruppe's cgi.d for a bit, but recently switched to
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder
wrote:
I think we are now in a world where Rust is the zero cost
abstraction language to replace C and C++, except for those
who are determined to stay with C++ and evolve
On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:
Making the GC more like in Go and JVM means adding write
barriers, it means making general code slower (we're not
fast-as-C anymore), it means losing easy C compatibility (hello
FFI!)
What exactly will be lost? And do we even have
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder wrote:
I think we are now in a world where Rust is the zero cost
abstraction language to replace C and C++, except for those who
are determined to stay with C++ and evolve it.
Why should we settle for this ? D code (efortless) is easie
On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote:
Making the GC more like in Go and JVM means adding write
barriers, it means making general code slower (we're not
fast-as-C anymore), it means losing easy C compatibility (hello
FFI!), it means forbidding many current language featur
bpr wrote:
It seems that there's an effort from the top to bring more higher level
features into --betterC. I agree with you that more should be there, that
it should really be betterC++ and strive for feature parity with modern
C++.
we already have better c++: it is titled "D".
On Friday, 22 December 2017 at 13:38:25 UTC, Dan Partelly wrote:
It works as a "betterC" it seems, but you loose a lot of
functionality which should be in a "better C" and again, a lot
from the standard libraries is lost. Template C++ 2017 works
well for a better C as well, and I retain 0 cost
On Fri, 2017-12-22 at 14:48 +, thedeemon via Digitalmars-d wrote:
> […]
>
> D is not there for the only reason of that benchmark maintainer
> unwilling to include D. Technically you can take any C solution
> there, translate it to D (mostly by renaming from .c to .d) and
> with LDC get the
On Fri, 2017-12-22 at 13:38 +, Dan Partelly via Digitalmars-d
wrote:
> […]
>
> I wanted to look at D as a "beter C++", with simple and sane
> metaprograming and metaligusitic features. It is almost there,
> but unfortunately, not 0 cost abstraction without loosing too
> much. You depend to
On Friday, 22 December 2017 at 11:39:48 UTC, user1234 wrote:
If benchmarks based on DMD are published, the article will be
subject to the criticism that is that the shorter build time is
due to the optimization pass, since it's known not to be super
deep in DMD backend.
Well, Go folks don't
On Friday, 22 December 2017 at 11:46:49 UTC, Chris wrote:
http://benchmarksgame.alioth.debian.org/
No D there? Performance must be bad because its not listed at
all ( for a language that exist 20 years )?
D is not there for the only reason of that benchmark maintainer
unwilling to include D.
On Friday, 22 December 2017 at 12:13:39 UTC, Emma Watson wrote:
On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing
wrote:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright
wrote:
"C, Python, Go, and the Generalized Greenspun Law"
http://esr.ibiblio.org/?p=7804
I'm still
On Fri, 22 Dec 2017 11:34:21 +, user1234 wrote:
> On Friday, 22 December 2017 at 05:50:15 UTC, drug wrote:
>> 22.12.2017 01:11, Steven Schveighoffer пишет:
>>> On 12/21/17 4:55 PM, Walter Bright wrote:
>>> [...]
>> We should also consider provider's name - github, bitbucket,
>> gitlab etc. Bec
On Friday, 22 December 2017 at 09:46:40 UTC, Jacob Carlborg wrote:
On 2017-12-22 00:11, Atila Neves wrote:
I tried lld on Linux for D binaries and some of them crash.
That might not mean anything on Windows, but given that I've
run into 2 dmd bugs so far in which picking one of ld.bfd or
ld.g
On Tuesday, 19 December 2017 at 12:21:19 UTC, I Love Stuffing
wrote:
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright
wrote:
"C, Python, Go, and the Generalized Greenspun Law"
http://esr.ibiblio.org/?p=7804
I'm still not sure why this precludes GC from just being a
standard librar
On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
This one of the main strengths of D, it is what Walter focuses
on, yet I have seen almost nothing on the D blog talking about
this. What brought me to emphasize this today is this recent
post about how long it takes to compile the most
On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
This one of the main strengths of D, it is what Walter focuses
on, yet I have seen almost nothing on the D blog talking about
this. What brought me to emphasize this today is this recent
post about how long it takes to compile the most
On Friday, 22 December 2017 at 05:50:15 UTC, drug wrote:
22.12.2017 01:11, Steven Schveighoffer пишет:
On 12/21/17 4:55 PM, Walter Bright wrote:
[...]
We should also consider provider's name - github, bitbucket,
gitlab etc. Because there can be different (real) users with
identical names.
So
This one of the main strengths of D, it is what Walter focuses
on, yet I have seen almost nothing on the D blog talking about
this. What brought me to emphasize this today is this recent
post about how long it takes to compile the mostly-C++ Chromium
web browser and the reddit discussion about
On 2017-12-21 21:13, Steven Schveighoffer wrote:
What do you all think?
What Docker is doing on the public Docker registry [1] is that all
images are namespaced based on the account name. Instead of just "dwt"
it would be "jacob-carlborg/dwt". In addition to that they have what
they call "off
On 2017-12-22 00:11, Atila Neves wrote:
I tried lld on Linux for D binaries and some of them crash. That might
not mean anything on Windows, but given that I've run into 2 dmd bugs so
far in which picking one of ld.bfd or ld.gold produced crashing
binaries, I'd be wary of using lld on Windows
On 2017-12-22 00:43, H. S. Teoh wrote:
But still, that error message is exceedingly unhelpful. If possible I'd
love to track it down and file an enhancement to improve the error
message.
You can get that error when using two different symbols with the same
local name but different fully qual
28 matches
Mail list logo
