Re: Pitching D to a gang of Gophers
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu wrote: On 03/07/2016 02:17 PM, landaire wrote: I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei It's typical in an embedded target development environment that you are working on Windows (or nowadays Linux) and developing for some target platform (though yeah, perhaps it doesn't make much sense to build on Windows for FreeBSD, I assume the idea is to make target platform development sort of generic). It also helps if you are trying to develop a multi-platform tool and prefer to develop on just one platform -- a single build could potentially generate binaries for all the target platforms.
Re: Pitching D to a gang of Gophers
On 14-Mar-2016 00:32, cym13 wrote: On Sunday, 13 March 2016 at 21:16:45 UTC, Dmitry Olshansky wrote: On 13-Mar-2016 22:13, kdmult wrote: On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1 Thanks, both fixed! Also some typos: "ellimination" -> "elimination" http://slides.com/dmitryolshansky/deck/fullscreen/#/4/5 "usefull" -> "useful" "simillar" -> "similar" http://slides.com/dmitryolshansky/deck/fullscreen/#/5/6 Thx, fixed these too. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Sunday, 13 March 2016 at 21:16:45 UTC, Dmitry Olshansky wrote: On 13-Mar-2016 22:13, kdmult wrote: On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1 Thanks, both fixed! Also some typos: "ellimination" -> "elimination" http://slides.com/dmitryolshansky/deck/fullscreen/#/4/5 "usefull" -> "useful" "simillar" -> "similar" http://slides.com/dmitryolshansky/deck/fullscreen/#/5/6
Re: Pitching D to a gang of Gophers
On 13-Mar-2016 22:13, kdmult wrote: On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1 Thanks, both fixed! -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1 --- zzz0.d 2016-03-13 22:10:44.548974800 +0300 +++ zzz1.d 2016-03-13 22:11:54.653984600 +0300 @@ -2,7 +2,7 @@ // slice is dynamic array on GC heap int[] slice = [1, 2, 3, 4, 5]; // slice the range of [1:3) -int[] a = slice[1..3]; +int[] a = slice[1..4]; assert(a == [2,3,4]); a ~= 6; // append 6 @@ -15,7 +15,7 @@ int[] b = a.dup; // duplicate (=copy) b[0] = 10; -assert(a[0] == 8); +assert(a[0] == 4); assert(*a.ptr == 4); int k = 1;
Re: Pitching D to a gang of Gophers
On 12-Mar-2016 11:56, Russel Winder via Digitalmars-d wrote: On Sat, 2016-03-12 at 11:09 +0300, Dmitry Olshansky via Digitalmars-d wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. Switching from PHP to Go is not a bad idea as CloudFlare have blazed that trail and created a who community around it. I does go fairly well considering the simultaneous pressure for more features and overall poor state of the original PHP codebase. Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ std.concurrency working only with threads and lack of better integration of fibers in std is our weak spot as prompted by further questions. Clearly there are many feature similarities between D and Go as well as differences (slices vs. generics). looked like a nice selection of example in teh slides to pick up on this. Indeed I've picked up a lots of similarities esp. between D1 and Go. For instance, Go slices do allow stomping just like their D1 counterparts. OOP model and direct access to C are the major differences. Thread pool and work stealing is clearly the way forward for actor/dataflow architecture, though explicit threads have their place as well. std.parallelism has a task pool system. I wonder if there should be a strategic move to (in some sense) merge std.concurrency, std.fibers and std.parallelism into a single consistent whole (possibly remaining three separate by connected packages rather than a single monolith. Yeah, preferably we'd have future+async style concurrency together with actor system all riding on top of some core functionality like thread pools with work-stealing. IO complicates matters as it also has to be a part of the picture for 'fiber as actor' model to work really well. Java has had great benefit from having a single concurrency/parallelism strategy even though it ends up with different leaves not a monolith. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote: On 05-Mar-2016 14:05, Dmitry Olshansky wrote: Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ Very nice slide deck. Thanks for publishing. --Jon
Re: Pitching D to a gang of Gophers
On Sat, 2016-03-12 at 11:09 +0300, Dmitry Olshansky via Digitalmars-d wrote: > On 05-Mar-2016 14:05, Dmitry Olshansky wrote: > > > > I'm having an opportunity to do a small tech-talk on things D in a > > eCommerce shop that is currently sold on Go (migrating to SOA from > > PHP > > monolith). I do not intend that to become Go vs D battle but it > > gives > > the context. Switching from PHP to Go is not a bad idea as CloudFlare have blazed that trail and created a who community around it. > The talk went better then I would expect with lots of good > questions. Sounds like some good people, using Go for good reasons not blind fashion. > Compile-time features generated the most favorable discussion. This is now a bit topic again in C++, witness all the debating over constexpr and C++17 and C++20. > Obligatory slides: > http://slides.com/dmitryolshansky/deck/fullscreen/ > > std.concurrency working only with threads and lack of better > integration > of fibers in std is our weak spot as prompted by further questions. Clearly there are many feature similarities between D and Go as well as differences (slices vs. generics). looked like a nice selection of example in teh slides to pick up on this. Thread pool and work stealing is clearly the way forward for actor/dataflow architecture, though explicit threads have their place as well. std.parallelism has a task pool system. I wonder if there should be a strategic move to (in some sense) merge std.concurrency, std.fibers and std.parallelism into a single consistent whole (possibly remaining three separate by connected packages rather than a single monolith. Java has had great benefit from having a single concurrency/parallelism strategy even though it ends up with different leaves not a monolith. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Pitching D to a gang of Gophers
On 05-Mar-2016 14:05, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. The talk went better then I would expect with lots of good questions. Compile-time features generated the most favorable discussion. Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ std.concurrency working only with threads and lack of better integration of fibers in std is our weak spot as prompted by further questions. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu wrote: On 03/07/2016 02:17 PM, landaire wrote: I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei Well, at least in a commercial environment, not having to have multiple pools of build machines is very helpful. That is to say, I don't need 10 windows machines sitting around waiting to accept a job, since I can just cross compile with `GOOS=windows GOARCH=386 go build` on linux. This is also why gofmt is so awesome -- if you're working with a team of 40 other engineers, you don't want to be messing with formatting holy-wars. And another item for this thread that D really shines at: const and immutable -- Golang lacks const and immutable. When working with large-ish teams, it's pretty annoying not to be able to require a library take a const, or immutable parameter. -S
Re: Pitching D to a gang of Gophers
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu wrote: On 03/07/2016 02:17 PM, landaire wrote: I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei You can't use all target platforms as development platforms - e.g. Apple Watch, microcontrollers, and so on. Sometimes you don't have any other options than cross-compilation. It is also more flexible from a DevOps perspective. You can setup a Linux build server and use it to produce builds for several targets.
Re: Pitching D to a gang of Gophers
On 03/07/2016 02:17 PM, landaire wrote: I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: - tooling, tooling, tooling (IDE plugins and build tools work great) I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. Things I really like about D though are the UFC makes for really pleasant method chaining and cleaner code (along with map/filter/reduce for things), code reuse as you pointed out, and Dub being an actual package manager that seems to have common issues with dependency management solved. At least with my limited experience with D I haven't run into any Dub-related issues. I'd like to toss in that D's lack of solid and stable `io` APIs in phobos is kind of sad and resulted in one of my recent projects being rewritten in Go.
Re: Pitching D to a gang of Gophers
On Sunday, 6 March 2016 at 14:02:25 UTC, Dmitry Olshansky wrote: On 06-Mar-2016 10:21, Shammah Chancellor wrote: On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: [snip] Here's some stuff D shares with Go: "Single" binary deployments. Garbage Collector In-language slices and maps Foreach (Although D is much more powerful here) Some things D is weak on: * The name -- all I ever hear are penis jokes. Thankfully not in my country ;) * Garbage Collector (!) This is indeed a sore spot, Go rapidly advanced their GC and even took advantage of it being non-copying to deliver on lower-latency front. Wonder if we could squeeze some more bang out of GC. * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I understand they will be much more difficult to get to parity due to the feature set of D) Strangely people love single imposed code style of Go, and in many ways other enforced conventions. * Docs -- although these have gotten much much better recently -- the current implementation of concepts makes it hard for people to know where and when they can use a type. E.g sort docs (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know what types of things I can sort as a newcomer? Even if I figure out that I need to look at isForwardRange, the docs there aren't terribly helpful either (https://dlang.org/phobos/std_range_primitives.html#isForwardRange) I would put up a PR, but I don't know how to fix it without introducing a language structure for Concepts -- but this has been veto'd for a variety of reasons (primarily type explosion as I understand the arguments) * Libraries Probably the biggest issue. Another one I'd pull is complexity, there is sooo many moving parts in D by now that we consistently fail to deliver a feature complete spec and/or compiler for it. Some things D is much better on (and would cause me to choose it every time and just contribute fixes where I could to the external tools): * Package management/build tools * Integration with existing build systems/libraries * Reusable algorithms that are FAST * Empowering programmer expressiveness without enabling magic Overall my impression is that if we were to compare D and Go as tools, D would be more of meta tool - i.e. a tool to create tools whereas Go is ready made toolkit that is nicely crafted but quite limited. Now I only need to appeal to the former somehow ;) -S. Just to temper some points that I agree with in principle: * Garbage Collector (!) D doesn't need a better GC in my opinion. Go's GC has to be really good because AFAIK there is no other way to manage memory. Same for Java. But as good as a GC can be it will never be good enough for all applications. D solved the problem by proposing other memory management schemes so when the GC isn't good enough you just don't use it. Developping such schemes is *way* more important to D's future than a better GC that can never be more than good enough for more people but never everybody. * Libraries There again as using C libraries in Go is tiresome there is more incentive not to reuse them. OK, this is a weak point, I too think this is maybe the most proeminent D flaw.
Re: Pitching D to a gang of Gophers
On 06-Mar-2016 10:21, Shammah Chancellor wrote: On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: [snip] Here's some stuff D shares with Go: "Single" binary deployments. Garbage Collector In-language slices and maps Foreach (Although D is much more powerful here) Some things D is weak on: * The name -- all I ever hear are penis jokes. Thankfully not in my country ;) * Garbage Collector (!) This is indeed a sore spot, Go rapidly advanced their GC and even took advantage of it being non-copying to deliver on lower-latency front. Wonder if we could squeeze some more bang out of GC. * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I understand they will be much more difficult to get to parity due to the feature set of D) Strangely people love single imposed code style of Go, and in many ways other enforced conventions. * Docs -- although these have gotten much much better recently -- the current implementation of concepts makes it hard for people to know where and when they can use a type. E.g sort docs (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know what types of things I can sort as a newcomer? Even if I figure out that I need to look at isForwardRange, the docs there aren't terribly helpful either (https://dlang.org/phobos/std_range_primitives.html#isForwardRange) I would put up a PR, but I don't know how to fix it without introducing a language structure for Concepts -- but this has been veto'd for a variety of reasons (primarily type explosion as I understand the arguments) * Libraries Probably the biggest issue. Another one I'd pull is complexity, there is sooo many moving parts in D by now that we consistently fail to deliver a feature complete spec and/or compiler for it. Some things D is much better on (and would cause me to choose it every time and just contribute fixes where I could to the external tools): * Package management/build tools * Integration with existing build systems/libraries * Reusable algorithms that are FAST * Empowering programmer expressiveness without enabling magic Overall my impression is that if we were to compare D and Go as tools, D would be more of meta tool - i.e. a tool to create tools whereas Go is ready made toolkit that is nicely crafted but quite limited. Now I only need to appeal to the former somehow ;) -S. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On 2016-03-06 10:05, Dmitry Olshansky wrote: However the opposite is also bad - in D you need to re-implement ALL of network/IO libraries from scratch to use async+fibers like e.g. vibe.d. Our famous C/C++ interop actually hurts us in this case because it's TRIVIAL to stumble on a blocking call in a fiber via some 3rd party library. I'm wondering how much work it would be to expose the read/write functions from vibe.d, update a C library to use the read/write functions from vibe.d and use that C library together with vibe.d. -- /Jacob Carlborg
Re: Pitching D to a gang of Gophers
On 06-Mar-2016 01:13, Walter Bright wrote: On 3/5/2016 3:05 AM, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Interfacing to existing C and C++ code. They have no C/C++ code to interface to, so it makes little sense to them. Many prominent C libraries actually have fine Go bindings for things like compression/encryption, in fact there most likely more of them then for D (because of popularity of Go). -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On 05-Mar-2016 14:31, John Colvin wrote: On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. [...] Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read. Rings true with my (limited) experience with Go. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On 05-Mar-2016 20:17, Chris Wright wrote:
On Sat, 05 Mar 2016 14:05:09 +0300, Dmitry Olshansky wrote:
What features you'd highlight to enterprise-ish user?
Go isn't bad from an enterprise perspective -- it's better than D, in
fact. Go has a major company heavily invested in it, and a number of
other companies are supporting it.
D is much more programmer-friendly, and that's where it tends to shine.
C# is close enough that there's no order-of-magnitude difference, plus
it's got corporate support, so for an enterprise crowd I'd sooner
recommend it.
All true. In fact I've been worried that D may look like just another C#
with a bit different set of trade-offs. Like native code C/C++ inter-op
friendly C# with strong compile-time meta-programming capabilities.
Keeping in mind that folks sometimes are just fine with run-time
meta-programming as in being able to use compiler as a library...
Things I might talk about:
Interacting with the fiber scheduler explicitly. Goroutines are
hermetically sealed. D Fibers are much more open.
Interacting with scheduler directly is a type code these folks would
LOVE to avoid. And looking at in-house library I can wholeheartedly
agree, there is just not enough system-level expertise to meaningfully
use this kind of control.
* Need fiber-local storage? Subclass Fiber and you're a cast away from
it. Need goroutine-local storage? There's a library for it, but it's a
terribly ugly hack.
* Need to shut down a goroutine and stop it from running? You have to
have it explicitly check in every location another goroutine might want
to stop it, and it's not a trivial check either. Plus you need to
propagate a channel down the stack somehow. In D, it's almost trivial to
stop a Fiber.
* Need to schedule things precisely?
Most likely the answer would - why should I. And indeed for the most
purposes of a web-service there is rarely a good need for it.
Impossible. You can sleep, or you
can wait on IO, but that's it. You can't rate-limit an operation,
or add thread affinity so one set of goroutines is reliably scheduled
independently of another. In D, you can implement all of that.
However the opposite is also bad - in D you need to re-implement ALL of
network/IO libraries from scratch to use async+fibers like e.g. vibe.d.
Our famous C/C++ interop actually hurts us in this case because it's
TRIVIAL to stumble on a blocking call in a fiber via some 3rd party library.
Templates vs interface{}. interface{} is nice to have sometimes, and
we've got std.variant for those times. But almost always we want actual
type safety and not to put casts everywhere.
Working with JSON could be an interesting example as Go's solution
involves lots of type-casting when working with dynamic structure.
Better control over the garbage collector. You can prevent collections
from running in D and have the compiler enforce non-usage of the GC.
Then there are all the ways in which Go deviates from standard practices
and gets things wrong.
I count a lot of these, mostly all of them have to do with the fact that
writing anything non-bogus by default requires great discipline to write
highly repetitive non-trivial patterns. For instance, channels are
awkwardly non-composable low-level primitives that are easy to get wrong
in so many ways.
There's a giant list of them, and D doesn't give a
specific advantage.
--
Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. What guys seem to like of Go from my observation: - goroutines instead of direct asynchronous programming* - fast runtime with state of the art GC - host of ready-made libraries esp. http & networking** - lightweight OOP that doesn't get in your way - tooling, tooling, tooling (IDE plugins and build tools work great) *Note: all of standard I/O is transparently handled with goroutines much like vibe.d but goroutines are migrating across thread pool ** That being said there are tons of 1-man projects of dubious quality, So far I'd thought of a few big themes: - little nice things (slices/maps, things like 1_000_000 and e.g. a < b && d < e is parse error, UFCS) - code reuse (templates & ranges, with examples like generic min and some algo) - compile-time works (CTFE, need simpler example then regex) I'm still pondering whether I should dive into UDA, I'd try to stay simple as simplicity is one of things Go guys known to love. What features you'd highlight to enterprise-ish user? I work in a 99% Go shop (a splash of C, and some smattering of scripts for in-house tools.) I've tried to use D for a few things, and tried to get other people interested in it. So, here's my perception: Everything you've said is true, and D should focus on making some of these things much better. Additionally, the compiled (mostly single binary nature) of Go makes it very nice for deployments. Focusing on dfmt, and dfix would be a huge win. Here's some stuff D shares with Go: "Single" binary deployments. Garbage Collector In-language slices and maps Foreach (Although D is much more powerful here) Some things D is weak on: * The name -- all I ever hear are penis jokes. * Garbage Collector (!) * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I understand they will be much more difficult to get to parity due to the feature set of D) * Docs -- although these have gotten much much better recently -- the current implementation of concepts makes it hard for people to know where and when they can use a type. E.g sort docs (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know what types of things I can sort as a newcomer? Even if I figure out that I need to look at isForwardRange, the docs there aren't terribly helpful either (https://dlang.org/phobos/std_range_primitives.html#isForwardRange) I would put up a PR, but I don't know how to fix it without introducing a language structure for Concepts -- but this has been veto'd for a variety of reasons (primarily type explosion as I understand the arguments) * Libraries Some things D is much better on (and would cause me to choose it every time and just contribute fixes where I could to the external tools): * Package management/build tools * Integration with existing build systems/libraries * Reusable algorithms that are FAST * Empowering programmer expressiveness without enabling magic -S.
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:31:27 UTC, John Colvin wrote: On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. [...] Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read. That article is correct -- I've used go extensively at this point. This is also a good article: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 22:13:40 UTC, Walter Bright wrote: On 3/5/2016 3:05 AM, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Interfacing to existing C and C++ code. If they were a PHP shop, then this wouldn't matter much to them.
Re: Pitching D to a gang of Gophers
On 3/5/2016 3:05 AM, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Interfacing to existing C and C++ code.
Re: Pitching D to a gang of Gophers
On Sat, 05 Mar 2016 14:05:09 +0300, Dmitry Olshansky wrote:
> What features you'd highlight to enterprise-ish user?
Go isn't bad from an enterprise perspective -- it's better than D, in
fact. Go has a major company heavily invested in it, and a number of
other companies are supporting it.
D is much more programmer-friendly, and that's where it tends to shine.
C# is close enough that there's no order-of-magnitude difference, plus
it's got corporate support, so for an enterprise crowd I'd sooner
recommend it.
Things I might talk about:
Interacting with the fiber scheduler explicitly. Goroutines are
hermetically sealed. D Fibers are much more open.
* Need fiber-local storage? Subclass Fiber and you're a cast away from
it. Need goroutine-local storage? There's a library for it, but it's a
terribly ugly hack.
* Need to shut down a goroutine and stop it from running? You have to
have it explicitly check in every location another goroutine might want
to stop it, and it's not a trivial check either. Plus you need to
propagate a channel down the stack somehow. In D, it's almost trivial to
stop a Fiber.
* Need to schedule things precisely? Impossible. You can sleep, or you
can wait on IO, but that's it. You can't rate-limit an operation, or add
thread affinity so one set of goroutines is reliably scheduled
independently of another. In D, you can implement all of that.
Templates vs interface{}. interface{} is nice to have sometimes, and
we've got std.variant for those times. But almost always we want actual
type safety and not to put casts everywhere.
Better control over the garbage collector. You can prevent collections
from running in D and have the compiler enforce non-usage of the GC.
Then there are all the ways in which Go deviates from standard practices
and gets things wrong. There's a giant list of them, and D doesn't give a
specific advantage.
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: I'm having an opportunity to do a small tech-talk on things D in a eCommerce shop that is currently sold on Go (migrating to SOA from PHP monolith). I do not intend that to become Go vs D battle but it gives the context. [...] Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read.
Re: Pitching D to a gang of Gophers
On 05-Mar-2016 14:11, Jakob Bornecrantz wrote: On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Have go solved stacktraces in gorutines, last I checked this was a big pain point for go developers, otherwise its a good issue to bring up. Cheers, Jakob. Sort of, yes - there is a tool that trims down stacktraces from irrelevant goroutines on panic if that is what you refer to. Also it's done by default in the latest v1.6. -- Dmitry Olshansky
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Have go solved stacktraces in gorutines, last I checked this was a big pain point for go developers, otherwise its a good issue to bring up. Cheers, Jakob.
