On Tuesday, 14 July 2015 at 05:00:47 UTC, Laeeth Isharc wrote:
On Tuesday, 14 July 2015 at 00:22:21 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:
Today, one wouldn't want to build a business around depending
on Andrei's allocator.
Not really sure what you are referring to.
It will be dependable soon enough, so I wanted to head off any
discussion centred around it not yet seasoned.
As I've written elsewhere. Ready-made-library-allocators don't
solve any real world challenges I have.
I can make do with malloc and mmap where needed. I can write my
own specialised allocator in 10-20 minutes, which I almost never
need, and which is much more likely to perform well than a
library solution since it is written for a specific scenario.
What makes D "need" library-allocators is that it was designed
for having a GC and is perhaps over-focusing on generic
programming that is agnostic to GC/non-GC. That may or may not be
an interesting experiment, but it does not solve many real world
problems. It might solve some problems D have aggregated by not
addressing the GC issues at an early stage.
bang! - when I am done. In addition there is instrumenting etc
built into the allocators that I suppose will help track down
many kinds of problems.
If the language makes problems related to memory a likely issue,
then you are already in a worse position than the competing
solutions where such issues are very very unlikely. That means
you are off-the-map.
There's a big advantage in having a coherent compiler-backed
memory model and let the compiler optimize transparently based on
static analysis, profiling and hints. That's basically what all
high level languages should and do aim for.
(C is not a high level language)
problem. I suppose implicitly from what you write it must be
for web services on a large scale, and if you have anything you
can point me to on this then I would be curious to see it.
It applies to all scales. It has to do with having a system that
is robust to modifications and affords agile evolutionary
development over time.
Web services are updated, modified and extended several times
every year over many years sometimes on short notice. Glitches,
and especially hard to track down glitches, are very bad.
One good reason for going for a statically typed language with
solid memory management is to get close to zero glitches with
less development time spent on development, testing and debugging.
So if you cannot have a GC, then you need another solution that
is equally robust, which is what new no-GC languages like Rust
and Pony try to offer. That does give them an advantage.
Client side game development has completely different
requirements since you don't have to ship on a few hours notice
if the architecture is reasonable. So I agree with weaselcat that
D could be better of gearing itself towards that use scenario
where linear typing is more likely to be a liability than an
advantage.
But either way, you have to provide a feature set that maximise
utility within a domain that is sizeable in order to grow an eco
system. Otherwise you get all these libraries with 1-2 developers
behind them that end up rotting because nobody are willing to
maintain them long term.
