Re: How Different Are Templates from Generics
Thanks for the thorough explanation. Most of that is how I was
thinking it worked. However, that leaves me perplexed. If
templates just generate code then how come:
Wouldnt..
class SomeClass(T) : ISomeInterface!T
and..
class SomeOtherClass(T) : ISomeInterface!T
...generate two different interfaces? Two interfaces that do the
same thing, but two interfaces nonetheless? I assume each type in
D has some form of type id underlying everything, which wouldn't
that make the follow:
if (instance1 is ISomeInterface)
{
Console.WriteLine("Instance1 is interface!");
}
fail? Or is there some extra magic that is making it work with my
experiments?
How Different Are Templates from Generics
I come from both a C++ and C# background. Those have been the
primary languages I have used. In C# you can do something like
this:
public interface ISomeInterface
{
T Value { get; }
}
public class SomeClass : ISomeInterface
{
T Value { get; set; }
}
public class SomeOtherClass : ISomeInterface
{
T Value { get; set; }
}
public static class Example
{
public static void Foo()
{
var instance1 = new SomeClass(){ Value = 4; };
var instance2 = new SomeClass(){ Value = 2; };
if (instance1 is ISomeInterface)
{
Console.WriteLine("Instance1 is interface!");
}
if (instance2 is ISomeInterface)
{
Console.WriteLine("Instance2 is interface!");
}
}
}
Expected output is both WriteLines get hit:
Instance1 is interface!
Instance2 is interface!
So now the 'D' version:
interface ISomeInterface(T)
{
T getValue();
}
class SomeClass(T) : ISomeInterface!T
{
private:
T t;
public:
this(T t)
{
this.t = t;
}
T getValue()
{
return t;
}
}
class SomeOtherClass(T) : ISomeInterface!T
{
private:
T t;
public:
this(T t)
{
this.t = t;
}
T getValue()
{
return t;
}
}
...which seems to work the same way with preliminary testing. I
guess my question is...templates are different than generics, but
can I feel confident continuing forward with such a design in D
and expect this more or less to behave as I would expect in C#?
Or are there lots of caveats I should be aware of?
Re: Difference between template and mixin template
On Thursday, 10 October 2019 at 15:56:36 UTC, Just Dave wrote:
I'm trying to get my head around mixing templates. I'm using it
as kind of a replacement for class inheritance as it seems to
fit better composition over inheritance. So I do something like:
mixin template NumberTemplate()
{
private:
int number = 0;
public:
int getNumber(int number)
{
return number;
}
}
interface INumber
{
getNumber(int number);
}
class Number : INumber
{
template NumberTemplate;
};
So two questions:
a) Is this correct usage?
b) It compiles if I just do:
template NumberTemplate()
{
private:
int number = 0;
public:
int getNumber(int number)
{
return number;
}
}
what is the difference between template and mixin template?
Sorry I messed up the above code example the following should
look like:
class Number : INumber
{
mixin NumberTemplate;
};
Re: C#'s 'is' equivalent in D
On Thursday, 10 October 2019 at 15:53:20 UTC, Adam D. Ruppe wrote:
On Thursday, 10 October 2019 at 15:47:58 UTC, Just Dave wrote:
if (obj is Person person)
Looks the same as D's
if(auto person = cast(Person) obj) {
// use person in here
} else {
// it was some other type
}
Excellent!
Difference between template and mixin template
I'm trying to get my head around mixing templates. I'm using it
as kind of a replacement for class inheritance as it seems to fit
better composition over inheritance. So I do something like:
mixin template NumberTemplate()
{
private:
int number = 0;
public:
int getNumber(int number)
{
return number;
}
}
interface INumber
{
getNumber(int number);
}
class Number : INumber
{
template NumberTemplate;
};
So two questions:
a) Is this correct usage?
b) It compiles if I just do:
template NumberTemplate()
{
private:
int number = 0;
public:
int getNumber(int number)
{
return number;
}
}
what is the difference between template and mixin template?
Re: C#'s 'is' equivalent in D
Even though static solutions would be more performance minded, I'd actually prefer to see the runtime equivalent so I don't have to rethink how I think as performance isn't really my major concern right now.
C#'s 'is' equivalent in D
In C# you can do something like:
if (obj is Person)
{
var person = obj as Person;
// do stuff with person...
}
where you can check the type of an object prior to casting. Does
D have a similar mechanism? It's so widely useful in the C# realm
that they even added syntactic sugar to allow:
if (obj is Person person)
{
// do stuff with person...
}
I would presume since D has reference objects there must exist
some mechanism for this...
Re: Dynamic Arrays as Stack and/or Queue
Thanks for the advice. I used a quick and dirty range solution as was suggested. It allowed me to move on as I really wasn't looking to fully implement a queue or stack. Just get something that semantically behaved as such. I'll return later and optimize it with the later suggestions if it's a major issue.
Re: Dynamic Arrays as Stack and/or Queue
On Monday, 7 October 2019 at 17:24:19 UTC, Ferhat Kurtulmuş wrote: On Monday, 7 October 2019 at 17:11:08 UTC, Just Dave wrote: I need a stack and a queue and I noticed that the standard library doesn't appear to have one. Which is ok. I just need something that can logically behave as a stack and queue, which I think the dynamic array should be able to do (if I understand correctly this is effectively the equivalent of vector in C++ or List in C#). However, I'm having a hard time figuring out the best way to push, pop, enqueue and dequeue using D. I'm not seeing here: https://dlang.org/spec/arrays.html, anyway to remove from the array. What's the correct syntax/method call for this? I see you can easily concatenate with '~', but I see no corresponding delete. Sorry for the newbie question, but I'm just unsure where to look for this. Built-in D arrays rely on garbage collector, and you don't need an explicit delete. For nogc arrays, there are 3rd party libs and std.container.array. take a look at https://dlang.org/phobos/std_container_array.html I'm not talking about memory deletion. I'm talking about push, pop, enqueue, and dequeue behavior. I'd assume in a garbage collected language letting the reference float off should be picked up by the GC.
Re: Dynamic Arrays as Stack and/or Queue
On Monday, 7 October 2019 at 17:18:03 UTC, bachmeier wrote: On Monday, 7 October 2019 at 17:11:08 UTC, Just Dave wrote: I need a stack and a queue and I noticed that the standard library doesn't appear to have one. Which is ok. I just need something that can logically behave as a stack and queue, which I think the dynamic array should be able to do (if I understand correctly this is effectively the equivalent of vector in C++ or List in C#). However, I'm having a hard time figuring out the best way to push, pop, enqueue and dequeue using D. I'm not seeing here: https://dlang.org/spec/arrays.html, anyway to remove from the array. What's the correct syntax/method call for this? I see you can easily concatenate with '~', but I see no corresponding delete. Sorry for the newbie question, but I'm just unsure where to look for this. Does slicing do what you need? x[1..$] I have no clue. My problem is I need a stack and queue and I'm a little unsure the 'd' way to do it.
Dynamic Arrays as Stack and/or Queue
I need a stack and a queue and I noticed that the standard library doesn't appear to have one. Which is ok. I just need something that can logically behave as a stack and queue, which I think the dynamic array should be able to do (if I understand correctly this is effectively the equivalent of vector in C++ or List in C#). However, I'm having a hard time figuring out the best way to push, pop, enqueue and dequeue using D. I'm not seeing here: https://dlang.org/spec/arrays.html, anyway to remove from the array. What's the correct syntax/method call for this? I see you can easily concatenate with '~', but I see no corresponding delete. Sorry for the newbie question, but I'm just unsure where to look for this.
Re: Does Visual D actually work?
A machine reboot seems to have fixed the problem...
Does Visual D actually work?
I downloaded it after experiencing debugging issues with CodeBlocks (it wouldn't attach the provided debugger). I downloaded Visual D and after some fiddling with Visual Studio 2019 not supporting third party templates in my version (had to update it), I haven't been able to get Visual D to compile anything. It looks like it doesn't know where phobos lives? I'm getting this: std.file.FileException@std\file.d(872) project directory>: The system cannot find the path specified. I've tried configuring both 'Additional Import Paths' and/or 'String Import Paths' under Compiler in properties and 'Library Search Path' in Linker (not sure why I would need this...but I was desperate). I keep getting a popup that says: 'The operation could not be completed. The parameter is incorrect'. It would help if there was a setup guide for this instead of assuming it all works. What IDE should I be using on Windows, because so far the ones I've tried are not even close to working out of the box (my bare minimum for 'working out of the box' would be to at least build and be able to reference the standard library). When dmd installed i put itself on my C:\ drive in a folder called 'D'. I've done zero custom here. I just let all of the installers do their thing. Advice?
C++ base constructor call vs. D's
I was reading the C++ to D page, and came across this little bit about when to call the base class constructor: "It's superior to C++ in that the base constructor call can be flexibly placed anywhere in the derived constructor." Isn't there some inherent danger of not calling the base constructor first? Wouldn't C++'s method actually be equal in the effect that you could just overwrite whatever value the base class set in the derived class?
Specifying executable names in DUB
Greetings, This might be totally obvious, but I can't seem to figure out how to specify an executable's name to be different for each build types in my DUB package. For example, if my project is named "dlang_test", I might want something like so: dub build --build=debug yields either bin/dlang_test-debug.exe or possibly bin/debug/dlang_test.exe if I did dub build --build=release I might get either bin/dlang_test-release.exe or bin/release/dlang_test.exe When I read the section on build types (https://dub.pm/package-format-json.html#build-types), it specifically mentions that a "buildTypes" entry can override the build settings, but *not* "targetName" and "targetPath", which is what I think I want here. Is there any reason why this is disallowed? Or is there a more canonical way of achieving this with DUB? What I described above is often found in other build tools, such as CMake and Visual Studio, which makes me think I'm missing something obvious here. Thanks!
Re: xlsxd: A Excel xlsx writer
On Monday, 12 November 2018 at 10:38:28 UTC, Robert Schadek wrote:
On Saturday, 10 November 2018 at 10:55:04 UTC, Dave wrote:
Could you please elaborate a bit on your workflow for D with
Vim? E.g. what do you use for debugging, refactoring, ... ?
I had a lot of functions looking like this
void chart_axis_set_name(lxw_chart_axis* handle,
const(char)* name)
I had to transform into
void setName(string name) {
chart_axis_set_name(this.handle, toStringz(name));
}
For that I created a handful of (neo)vim macros that basically
it the transformations for me.
On my neovim setup. I use dutly. Dscanner generates ctags
recursively when I press F7. Which Ctrl-P uses for jump marks.
I use kdbg to debug, its just a somewhat pretty frontend to
gdb. Thats pretty much it.
Many thank! I have followed your setup and it helps :-)
Re: xlsxd: A Excel xlsx writer
On Thursday, 8 November 2018 at 08:43:10 UTC, Robert Schadek wrote: dpp and a handful of vim macros did most of the work Could you please elaborate a bit on your workflow for D with Vim? I often struggle with the tooling around D but consider Vim as a great tool to use for D development. I am aware of dutyl and also use it but you seem to have more tools at hand ... E.g. what do you use for debugging, refactoring, ... ?
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis wrote: > The problem is Teoh that learning a language in Vim or a IDE > are two totally different things. vim is a fantastic tool but it can be time consuming to configure. So I am wondering if some vim-D users would kindly share their vim setup for D and maybe even give some insights into their vim-D work-flow? Thx Dave
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try? against reading subtitles?
Re: Optimizations and performance
On Thursday, 9 June 2016 at 17:36:28 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 16:47:28 UTC, Kagamin wrote: A language optimized for performance of spontaneous code written by newbies, who never learned the language and don't use best practices? Could you stop pretending to completely misunderstand the point? -Wyatt Surely there is something between newbie and specialized expert.
Re: Optimizations and performance
All of this goes back to knowing what you are truly benchmarking.
Re: Optimizations and performance
On Thursday, 9 June 2016 at 15:44:04 UTC, Ola Fosheim Grøstad wrote: On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote: Appender!string is a great example, as it's easy to add and it almost always results in measurable speed increases. You can see how one simple change using D features can make your program 5% faster. Every language has idiomatic uses to speed up your program, the real question is how much faster those make the code and how easy it is to implement those in your own code. I don't think you should benchmark library constructs like Appender. That's essentially pointless. Why? Maybe not John Doe's library, but certainly the standard library should be included in benchmarks as that is supposed to be highly reflective of the language... Benchmark the naked language. If D provides concatenation, benchmark concatenation and how the optimizer turns them (or don't) into something more efficient. I don't even see how that's useful. It will help you make a better compiler. But not give to much information about the language. For instance if you benchmark a while loop in C, C++, Rust, and D all with LLVM backends...well the slower language really is just pointing towards some ineffectiveness of the compiler itself, as in a simple example, there really shouldn't be much difference. However, if you want to say "D has this feature which produces better performance than what those language can provide", that's a different story. Otherwise people would benchmark numpy instead of Python etc.
Re: Optimizations and performance
On Thursday, 9 June 2016 at 14:16:08 UTC, Jack Stouffer wrote: On Thursday, 9 June 2016 at 13:32:14 UTC, Dave wrote: [...] I agree with your general point, but what I find most useful about benchmarks is the ability to find the lower bound of performance without resorting to inline asm or making the program ugly as sin. If you can find, "In this particular task, D has these tricks it can use to make it really fast", I think that's useful as many other languages won't have those options. You can see how much you as a programmer can optimize the hot points in your code and how easy that is to do just by looking at the benchmarked code. Appender!string is a great example, as it's easy to add and it almost always results in measurable speed increases. You can see how one simple change using D features can make your program 5% faster. Every language has idiomatic uses to speed up your program, the real question is how much faster those make the code and how easy it is to implement those in your own code. Based off what you said, I'm not sure we disagree at all. :) My main point is no what you are really benchmarking. And just because you can make it go away doesn't mean it's not a problem still. Especially if it's the way you are supposed to use the language.
Re: Optimizations and performance
On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"? Also, the last I checked, one of D's selling points is that it is 'fast'. So it seems to be at least a design goal of this particular language.
Re: Optimizations and performance
On Thursday, 9 June 2016 at 13:56:37 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 13:52:38 UTC, Dave wrote: But it is the point of benchmarking So it's not "languages should be fast by default", but "benchmarks should be fast by default"? No. It's languages should be fast by default if you care about your language's performance. Benchmarks should be done on the more common cases to actually see how your language design decisions perform under scrutiny. Otherwise, why not use D's inline assembler and you'll probably crush all others. The reason is...because that's not what you should be measuring. Nor should it be tweaks you make to the common case. Now I do think it is useful to ask yourself "Ok, can we at least get there with the language?", and make the tweaks. But you should never forget the case of where your language performed using the common case. Unfortunately, I feel people do the tweaks and forget the failures discovered during the common case
Re: Optimizations and performance
On Thursday, 9 June 2016 at 13:48:36 UTC, Kagamin wrote: On Thursday, 9 June 2016 at 12:16:25 UTC, Wyatt wrote: On Thursday, 9 June 2016 at 01:46:45 UTC, Dave wrote: Languages should be fast by default. This. 4,000,000,000% this. If the naïve cases are bad, they're bad and trying to pretend that doesn't matter is some insidious denial. Sure, nearly any code can be optimised to be some sort of "fast", but 99% of it never will be. Performance is not the only thing to worry in a language. But it is the point of benchmarking
Re: Optimizations and performance
On Thursday, 9 June 2016 at 00:25:28 UTC, Seb wrote: On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote: D definitely needs some optimizations, I mean look at its benchmarks compared to other languages: https://github.com/kostya/benchmarks I believe the first step towards better performance would be identifying the specific areas that are slow. I definitely believe D could do much better than what's shown. Let's find D's performance weaknesses and crack them down. I wouldn't put too much emphasis on that benchmark as the implementations appear different? Note that Felix compiles to C++, yet beats C++ in the same test? Yes, Felix claims to do some high level optimizations, but doesn't that just tell us that the C++ code tested wasn't optimal? While I appreciate that someone puts the time and effort in such benchmarks, what do they really say? In the brainfuck example the most expensive function call is the hash function, which is not needed at all! We can just allocate an array on demand and we beat the Cpp implemention by the factor of 2! (and use less memory). https://github.com/kostya/benchmarks/pull/87 (n.b. that this small change makes D by far the fastest for this benchmark) So what do we learn? 1) Don't trust benchmarks! 2) D's dictionary hashing should be improved I think you can trust benchmark. I think the bigger key is understanding what you are truly benchmarking. Most of the time it's actually just the compilers more than the language. From what I see it's very difficult to actually 'benchmark' a language. Especially when you shy away from the ways the language was designed to be used. A good example I see almost all of the time is declaring classes in most languages. Which generally involves the class itself being created to be inherited and to utilize polymorphism. But the first thing you see people doing in benchmarking tests is slap 'final' or 'sealed' onto the class to eliminate the overhead in setting up a traditional OOP class, to get that extra performance. But that is not how the language is generally used... And at that point if your implementation performs slower than whatever you are benchmarking against (lets say for the sake of comparison Java and C# which the upper example would fit well), well...it's most likely not one language being better than the other, because they both accomplish the same thing the same way, so it's most likely some other feature, or more likely, some detail of the compiler or IL language they are using. When the clear blemish of the language is showing in both cases, classes should be 'final' or 'sealed' unless explicitly stated otherwise. So both languages are slower here. And the implementations with their workaround is really comparing something else. Benchmarking is important, but it takes nuance and thought to actually find what you benchmarked. For instance the vast majority of benchmarking cases I see have nothing to do with the language, but more so how a library call was implemented.
Re: Optimizations and performance
On Wednesday, 8 June 2016 at 22:32:49 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote: D definitely needs some optimizations, I mean look at its benchmarks compared to other languages: https://github.com/kostya/benchmarks I believe the first step towards better performance would be identifying the specific areas that are slow. I definitely believe D could do much better than what's shown. Let's find D's performance weaknesses and crack them down. I wouldn't put too much emphasis on that benchmark as the implementations appear different? Note that Felix compiles to C++, yet beats C++ in the same test? Yes, Felix claims to do some high level optimizations, but doesn't that just tell us that the C++ code tested wasn't optimal? Languages should be fast by default. I always find it missing the point when people go crazy during these benchmarking tests trying to make the code as fast as possible by tweaking both the code and the compiler flags. Go through that effort with a 2 million line app. Tell me how long that takes. In short, the truer metric is how fast does the code run casually writing code. Good languages will run fast without having to think super detailed about it. Now it is also useful to know how fast the language can get when someone dives into the details. Don't get me wrong. I just think the casual case is far more important. I've also noticed that during these benchmark wars people tend to compare compilers more than languages anyhow. And they tout their ability to tweak the compiler and write (at times very esoteric code for the sake of performance) as a win for their language. That's also missing the point.
Re: Andrei's list of barriers to D adoption
On Tuesday, 7 June 2016 at 20:48:13 UTC, Jonathan M Davis wrote: On Tuesday, June 07, 2016 18:33:01 Dave via Digitalmars-d wrote: [...] IMHO, it's bad practice to mass apply attributes with labels or blocks. It's far too easy to accidentally mark a function with an attribute that you didn't mean to, and it makes it way harder to figure out which attributes actually apply to a function. And when you add templates into the mix, applying attributes en masse doesn't work anyway, because pretty much the only time that you want to mark a template function with an attribute is when the template arguments have nothing to do with whether the attribute is appropriate or not. [...] So we should not follow the advice of Walter?
Re: Andrei's list of barriers to D adoption
On Tuesday, 7 June 2016 at 19:07:03 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 7 June 2016 at 18:59:13 UTC, ketmar wrote: side note: garbage-collected OS is possible, and written, and is working. Inferno. Yes, the Go guys was involved. So it is possible yes, but why would you want to have a garbage collected kernel? What do you gain from it? Extra trouble is what you gain from it. I also 'never' claimed it wasn't possible. Nor that you couldn't do it in Go. However, should you...I'm not that convinced it's a good tool for the job.
Re: Andrei's list of barriers to D adoption
On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote: On 6/7/2016 11:19 AM, Jack Stouffer wrote: On Tuesday, 7 June 2016 at 18:15:28 UTC, Walter Bright wrote: [...] But you can't grep for @system because 99% of the time it's implicit. This problem becomes harder to find when using templates for everything, which I do. Add: @safe: at the top of your D module and you'll find the @system code. The D compiler is the static analysis tool. It's true that @safe should have been the default, but too much code would break if that were changed. Adding one line to the top of a module is very doable for those that are desirous of adding the safety checks. You can also add: @nogc: at the top, too. It isn't necessary to tediously annotate every function. Seems fair. But perhaps phobos should also follow this standard? Which might be why people get the mindset that they have to annotate everything...
Re: Andrei's list of barriers to D adoption
On Tuesday, 7 June 2016 at 09:29:35 UTC, Russel Winder wrote: Their "strap line" is effectively that GC is not a problem for systems programming. And they are right. Which is why D has no problem with being a GC language. Incorrect. Pike, on a panel with D's Andrei, even said that when they labeled Go a systems programming language it was kind of taken in a way they didn't mean. It's more of a server programming language. I don't think Pike would agree that Go would be the best choice for an OS. I'm sure you can create one, and I'm sure he'd agree with this, but I doubt he'd personally reach for it. Go has blossomed due to the Web niche but it is used elsewhere. No. It's blossomed because of its tooling and standard library, which gets traction from the funds of Google.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 20:33:14 UTC, Walter Bright wrote: On 6/6/2016 12:44 PM, Satoshi wrote: [...] More complex? Wow! [...] C++ for junior programmers is easier? Wow! [...] Most learn C++ in college. So they have a 'headstart'
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 18:47:25 UTC, Karabuta wrote: On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: [...] Tutorial, tutorials, tutorials Serach youtube for D tutorials and you will find none that is helpful to many people. Check rust tutorials, yeah JavaScript tutorials, abundance. Go tutorials, plenty. Java tutorials, yeah. Clearly there seem to be a problem with tutorials. For instance, Apple pretty posted a great series of tutorials within a week (days?) of launching Swift.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 18:21:49 UTC, Johnjo Willoughby wrote: On Monday, 6 June 2016 at 04:24:14 UTC, Jack Stouffer wrote: On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: * Documentation and tutorials are weak. I never understood this, as I've always found D's docs to be pretty average. If you understand why they are "pretty average" you can imagine what would make them better, that gives you two reference points from which you can extrapolate back to a point at which they are "fairly crap". "fairly crap" on the graph is where new users come in because... 1. They are not yet fully invested in D, so do not have the inherent bias of a convert. 2. They do not have long familiarity with the docs. All that aside, it doesn't actually matter what you think or whether you understand why it is a common complaint. It is simply a fact that a lot of new users find the documentation to be "fairly crap". So you can either choose to... 1. Flap your hands and bury your head in the sand. 2. Say it doesn't make sense, these people must be morons. 3. Fix the documentation to make it more accessible to new users. 1 and 2 are the current solution from what I can see. There documentation can also be classified as broken as broken links were quite the annoyance for me. It's a minor inconvenience, but one that has an additive effect every time I encountered one using their site. That being said. My major complaint is lack of coherent, relevant or useful examples of what a function/type/template is actually useful for. Most are just ripped out of unittests, provide no context, and often use other library calls that aren't really needed to solve a non-common, non explained problem.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 14:00:29 UTC, Seb wrote: On Monday, 6 June 2016 at 13:53:13 UTC, BigDog wrote: On Monday, 6 June 2016 at 09:12:19 UTC, Ethan Watson wrote: On Monday, 6 June 2016 at 08:00:30 UTC, Laeeth Isharc wrote: D is still ahead of the pack in terms of features. I always think of Jurassic Park, when the D community talks of features. Specifically Jeff Goldblum's line of "Your scientist were so concerned if they could, they didn't stop to think if they should". D has pretty much most of the features present in every programming language. I'm not sure if that is a positive or negative personally. How about doing a collaborative poll and giving Andrei and Walter some feedback (backed with "some" number)? This time I found a platform that allows everyone to add new answers and select from the existing ones: http://www.rkursem.com/poll/view.php?id=7f7ebc16c280d0c3c Happy voting! Disclaimer: I am _not_ affiliated with this website by any means. One thing I mentioned in another post is the documentation is lacking...particularly parts don't work and the examples are rather chaotic. As I dig into the language further (for some reason I haven't determined why yet) I also find that the standard library is has big giant holes. Particularly in the graphics department, which pretty much was a deal killer for my project I was gonna try using D with. But also it seems to be missing formal data structures that it should have. Deques, Queues, Stacks, etc. Also no formal official http support is also a bummer... I would dismiss this as "growing pains for a new language" then you find out D is almost 20 years old O.o
Re: Google Summer of Code 2016 Only A Few Hours Left
On Friday, 19 February 2016 at 21:10:45 UTC, Dave wrote: On Friday, 19 February 2016 at 17:03:57 UTC, Craig Dillabaugh wrote: The GSOC deadline is Feb 19th 19:00 UTC (or 2 PM Wawa time) so any last ideas for the Idea's page are welcome. Our application is completed, but changes can still be made to the ideas page. In fact I suppose we can go on making modifications even after the deadline, as I have no idea at what time Google takes the snapshots of these pages for evaluation. Thanks to Martin Nowak's suggestion we are now participating as "The D Foundation" (rather than Digital Mars). Thanks to all who have helped out to this point. Cheers, Craig D is a fantastic efficient and fast replacement of Python which even has great plotting and other analysis features as ggplotd! To gain traction in numerical and statistical computing it is important to provide great optimization, automatic differential (AD) (reversed-mode AD (e.g. in mc-stan.org for Bayesian stuff) and/or forward-mode as e.g. for R at GSOC-2010 - there is no reason for numerical diff these days anymore, and you may mess-up your stuff using it!), and Bayesian routines. D is laking on these basic features (my personal opinion - correct me if I am wrong). Good starting points for a GSOC project would be "to port" mc-stan.org or some optimization algorithms from Coin-OR.org (please let me be more particular and independent of existing work if there is any interest for such a project!). I am not a D specialist but getting more and more into it and up to happily mentor this GSOC-project (maybe there would be (co-)mentors with more D experiences). (I already initiated a successful GSOC application on algorithmic differentiation in R together with John Nash for GSOC 2010 (student: Chidambaram Annamalai) - unfortunately I did not have the capacity to mentor/support the project as I had to finish my PhD during this time) Sorry, I just missed that the deadline is UTC 19:00. Maybe next year :-)
Re: Google Summer of Code 2016 Only A Few Hours Left
On Friday, 19 February 2016 at 17:03:57 UTC, Craig Dillabaugh wrote: The GSOC deadline is Feb 19th 19:00 UTC (or 2 PM Wawa time) so any last ideas for the Idea's page are welcome. Our application is completed, but changes can still be made to the ideas page. In fact I suppose we can go on making modifications even after the deadline, as I have no idea at what time Google takes the snapshots of these pages for evaluation. Thanks to Martin Nowak's suggestion we are now participating as "The D Foundation" (rather than Digital Mars). Thanks to all who have helped out to this point. Cheers, Craig D is a fantastic efficient and fast replacement of Python which even has great plotting and other analysis features as ggplotd! To gain traction in numerical and statistical computing it is important to provide great optimization, automatic differential (AD) (reversed-mode AD (e.g. in mc-stan.org for Bayesian stuff) and/or forward-mode as e.g. for R at GSOC-2010 - there is no reason for numerical diff these days anymore, and you may mess-up your stuff using it!), and Bayesian routines. D is laking on these basic features (my personal opinion - correct me if I am wrong). Good starting points for a GSOC project would be "to port" mc-stan.org or some optimization algorithms from Coin-OR.org (please let me be more particular and independent of existing work if there is any interest for such a project!). I am not a D specialist but getting more and more into it and up to happily mentor this GSOC-project (maybe there would be (co-)mentors with more D experiences). (I already initiated a successful GSOC application on algorithmic differentiation in R together with John Nash for GSOC 2010 (student: Chidambaram Annamalai) - unfortunately I did not have the capacity to mentor/support the project as I had to finish my PhD during this time)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
Originally (.Net 1) there was only 'Parse', 'TryParse' came in .Net 2, I guess they had to admit that exceptions are not always practical. I think TryParse (and anything marked prefixed with Try) is meant for quick stuff. It doesn't return any error. Just a boolean indicating that it failed. The entire function seems to be a wrapper around the actual try mechanism. So Parse will give you an error, TryParse will just tell you it failed.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
Exceptions are for when something went wrong. Returned errors are for when the function can't do what you asked it to do, but that doesn't mean that something went wrong. You seem to be implying this as a fact, when traditionally this is not how things are done. For example, if you try to write to a file and fail that's an exception, because something went wrong(e.g. - not enough disk Agreed. Traditionally handled with an exception. But if you have a function that parses a string to a number and you call it with a non-numeric string - that doesn't necessarily mean that something went wrong. Maybe I don't expect all strings to be convertible to numbers, and instead of parsing each string twice(once for validation and once for the actual conversion) I prefer to just convert and rely on the conversion function to tell me if it's not a number? Disagree. Traditionally also handled by throwing exceptions. C# throws a Format exception if a parse fails. Java throws...a ParseException. Just for some real-world examples. Note that doesn't mean that every time a function returns an error it's not a problem - they can indicate problems, the point is that it's not up to the callee to decide, it's up to the caller. The conversion function doesn't know if I'm parsing a YAML file and if field value is not a number that just means it's a string, or if I'm parsing my own custom file format and if something specific is not a number that means the file is corrupted. In a lot of C/C++ code a lot of functions just inform you that it failed. Sometimes they push it onto an error queue you can check. Sometimes they throw exceptions. Sometimes the return is an error code itself. But you very rarely see them return an error code AND throw an exception or push on an error queue. If they do they are being redundant. In the latter case, I can convert the returned error to exception(the returned error's type should have a method that returns the underlying result if it's OK and if there was an error raises an exception), but it's the caller's decision, not the callee. The implementer makes the decision on how errors are communicated.The caller has no control over the mechanism minus editing their code. Exceptions are not hard fails. They can be if they go unaccounted for (depending on the language/environment). Java has the infamous, NullPointerException that plagues Java applications. C# has the NullReferenceException. Even if they go unaccounted for, you still get a nice stack trace that helps you debug them. You still would. This is not being debated. However, programmers seem to forget their code is often for customers. They care more that their program just crashed. Very rarely are the exceptions in forms where they can go you know what would fix this?. No. They write a defect up and send it to the company that made the product. Maybe we have different definitions for hard fail... A crash? Or abrupt termination of an entire execution stack? Often unnecessarily? Even with no throw you can't guarantee a function won't cause problems with unhandled errors - unless you use a very strict definition of handling errors, that include discarding them or crashing the program. A very strict definition of handling errors is EXACTLY what I am advocating for. You should be able to do what you want. But when you do something naughty or potentially disruptive, you should inform others. nothrow can only guarantee the function won't expose any problems That's a solid guarantee. I'd advocate that so much I might even go as far as suggesting it as a default ;) If you insist on forcing developers to handle exceptions close to the source, or to explicitly pass them on, I guess it can be useful let them know what it is that they are require to handle/pass on. Exactly. Still, I don't think it's a good idea to needlessly burden people just so you could provide them with the tool to better handle that burden. I am not sure any *real* burden is here. People should be doing this in the form of documentation anyhow. However, if it's part of the definition, the work on documenting a function or type becomes easier. Because functionally they have an idea of what is needed by the language's definition and the header of the function or type. It has panics, which are different from exceptions in that you can't catch them(unless it's from another thread), but close in their usage to what I have in mind when referring to exceptions - they don't allow you to go on with what you where trying to do, but allow you to debug the problem and/or back down from it gracefully. I know very little about Rust. I only recently encountered a discussion about RAII where one of the developers said Rust has RAII but no exceptions. That is the only reason why I commented about anything regarding Rust with any certainty. It's not a matter of preferences, just like choosing between int and float is not a
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
It seems to be a controversial subject: https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986 As the topic has been argued for the past 50 years. No one ever agrees on the best way to handle errors. But I think most of this is because programmers tend to be the most stubborn and unchanging type of folks in the world. They often care that they look right. Not that they are right ;) Exceptions are not meant to force handling errors at he source. This attitude is why so many exceptions go unhandled at the upper layers. When you have a top level that calls a function that calls 50 other functions, each that throw a handful or more different exceptions, it's unreasonable to expect the upper layer coder to account for all of them. In fact, in practice they usually don't until bugs arise. This is provably bad practice. If you want to force handling errors at the source they should be part of the return type. Again what errors are worth throwing as exceptions in your paradigm? Which ones are worth returning? This separation is very arbitrary for my taste. Exceptions are not hard fails. They can be if they go unaccounted for (depending on the language/environment). Java has the infamous, NullPointerException that plagues Java applications. C# has the NullReferenceException. You don't have to crash the entire program just fail the action the user was trying to do and display a nice error message with whatever information you can and want to provide to the user. Even if you don't handle them, they provide information useful for debugging. Not gonna disagree there. It doesn't really guarantee the functions not annotated as throwing won't crash Combined with other guarantees (such as immutability, thread local storage, safe memory management, side-effect free code, no recursion, etc), you can make a reasonable guarantee about the safety of your code. And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air. Not really sure how to parse this...Doesn't seem like you have any good argument against what I said. Again I said you can make a *reasonable* guarantee. And I am not alone here. If you look at Rust, it really does illustrate a trend that functional programming has been pushing for a long time. Provable guarantees. Problems are very rarely unique. There are a core set of things that happen frequently that cause problems. And these things are easily recognizable by compilers. You can't prevent everything, but you can prevent a good deal of the obvious stuff. This is just an extension of that mindset. So it is not really that outlandish. It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO. Without the nothrow, you cannot guarantee it won't cause problems with unhandled errors ;) Seems like a nice guarantee to me. I would at least like this option, because library writers often try to write in an idiomatic way (and I tend to use the most reputable libraries I can find), which gives you some guarantees. The guarantee would be better served by default IMHO though. Having a 'throw' keyword is also useful for IDE's. Anybody that has used Visual Studio and C# will tell you a nice feature is that Visual Studio can tell you what exceptions get thrown when calling a method (very useful). C# does it in a different way, but a 'throw' keyword would actually help scanners figure this out very trivially as well as programmers just reading the header of a function. Scala and Rust seem to maintain both paradigms just fine. It's actually beneficial to have both - you have to acknowledge return-type-based exceptions, and you can always bypass them by turning them to exceptions, which are good for logging and debugging. I do not believe Rust has exceptions. I don't mind a language having multiple ways to handle errors. Seeing how its a topic no one ever is on the same page about, it's actually a wise design decision. But you don't often see library writers mixing them for consistency purposes. It's just easier for people to learn your library when you have one error handling scheme. It's usually encountered only where two libraries written by different vendors have to interact in application code. If exception handling is enforced, they can only be bypassed by converting them to errors or crashes, which are much less nice than exceptions when it comes to debugging, logging and cleanup. Exceptions have many benefits. They have many disadvantages too. They are often very slow on the exceptional path, which occur more frequently than most admit. Writing code that acknowledges that this code can fail due to an exception somewhere else does not count as ignoring it. You could not handle it all the way up the chain (at the cost of adding something to a
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
I should also mention that D has essentially enabled this philosophy that I am speaking about concerning errors by using the 'scope' keyword. I believe handling errors with scope literally translates to try\catch blocks behind the scenes. I also believe this is an encouraged way of dealing with errors in D.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Thursday, 11 June 2015 at 20:06:45 UTC, Kagamin wrote: On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote: Disagree. Traditionally also handled by throwing exceptions. C# throws a Format exception if a parse fails. https://msdn.microsoft.com/en-us/library/f02979c7%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/bb299639%28v=vs.110%29.aspx Forgot the one named Parse... https://msdn.microsoft.com/en-us/library/b3h1hf19(v=vs.110).aspx Microsoft does lets you opt out (as I suggested). The default function, the one actually named Parse (Int32.Parse), throws an exception by default.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
He is saying that now anything that throws will not only be slow but also have the same limitations as returned errors. nothrow by default is combining the slowness of exceptions with the limitness of returned errors. He literally said combine the slowness of exceptions. So I don't know how to read that other than he said it's slow. But perhaps I am just misunderstanding his wording, so perhaps it's best I just assume I misunderstood him. but also have the same limitations as returned errors That is a legitimate concern, but I don't think it is correct. The transitive nature would enforce that you at least handle it at some point along the chain. Nothing would force you to handle it right away. Although I think in most cases it's far better to do it when the error occurs(but this is my style). But when you don't there would be at least a flag saying this might fail that you and others could see. You can ignore that all the way up the turtles, but at some point you are going to be like I should handle these errors. If you have to acknowledge it anyways, then might as well just use returned errors because they are faster. I guess you could think of nothrow as an acknowledgement. I'd view it more like a warning to others. As I said before, I don't think you should be *forced* to do anything. Handle it right away and you don't have to mark your own function as 'throw'. Don't handle it, then your function should be marked 'throw', and the compiler can help others out and tell them to expect to have to handle the exception at some point. In regards to being faster, I'm not a big fan of exceptions in the first place. This probably explains my perspective on them, but I am familiar with their typical use case. And it's to communicate errors. I'd much prefer something like what Andrei presented during one of his C++ talks (ExpectedT). If I were to design a language today, I might try to incorporate that somehow with some semantic sugar and a handle by default mentality.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
It should be noted that functional languages that utilize monads often make you consider the exceptional case, and this is enforced by the compiler (sound familiar?) I also literally said with the limitness of returned errors.. That part is important part of the sentence. My point is that the exception mechanism is much less limited from the returned value mechanism, because it lets you handler the error in a higher level without modifying the middle levels to acknowledge it. The price for this is slowness. The benefits of nothrow by default come naturally with returned errors - the users can't implicitly ignore them, and since the possible errors are encoded into the return type any tool that can display the return type can show you these errors. With nothrow by default, you are paying the performance price of an exception mechanism, and then do extra work to add to it the limitations of returned errors, just so you can get the benefits that come naturally with returned errors. Wouldn't it be better to just use returned errors in the first place? Perhaps I am missing something big, but I don't see the performance price that is being paid with nothrow as an annotation nor as a default. Even with your explanation. No throw means no throw. No expensive exception mechanism is used. You can still return whatever you want. You are just guaranteeing no exceptions. This is not very different than returned errors: you either handle the error or change the function's signature so it can pass the error to it's caller. I agree for the most part on this. The big benefit of unchecked exceptions is that they require minimal effort to use - when I code and encounter a path that you can't handle, I just throw an exception(I can also use helper assert/enforce functions). I don't need to interrupt the flow and start adding `throws` all over the project, making my brain do a context switch that makes me forget the immediate thing I was working on, and increasing the chances of my commit conflicting with other concurrent commits(because it was touching general functions all over the place). No - I throw the exception, and leave worrying to how it will be handled to later. The one issues with returned errors is unless you wrap it up in something like ExpectedT or a specialized struct of some sort, you can only return one thing in many languages. Even if the language supports a tuple syntax, in the desired case (where things work as expected) you return information that is unneeded (the error). This is something that the ExpectedT object considers. I'd say this is where exceptions are beneficial (not the fact that you can throw them and not worry about them), because you only pay the price when needed, at the expense of some overhead with the exception handler and the code slowing on the exceptional path. Take as a counter example of Go which uses multiple return values to inform users of errors, you get information that is only useful sometimes. The alternative is not that I leave my current task to implement something that'll handle the exception at the right place - the alternative is that I continue my current task without throwing the exception, and only deal with it later on when something crashes or doesn't work properly. Why? Because I have a task to do, and if every time I encounter a place that *might* indicate an error I'll need to make sure that error is handled, I won't be able to focus on the actual task. Dealing with the exceptional case should be part of the task. It may be boring, but that is how you write solid code. Because if your sequence of logic requires Parse() to succeed to get a result to pass into B(), but Parse() fails, continuing on and using B() may cause issues. Now throwing an exception is really useful in this case because you guarantee that you aren't going to do B with undefined data or defaulted data. However, unless it is clear, people may not know they need to catch an exception. Thus the exception propagates up to the top and we now have a problem. So now imagine a call server where we have multiple processes each handling thousands of calls. A call comes in and during the processing of the call an error occurred and an exception is thrown. Now if you catch the exception at it's source, no problem. You can just log that something unexpected happen and not accept that specific call. If you don't handle the exception and it manages to escape to the top of the process, bye bye to all those calls rather than just one. You now have thousands of upset customers rather than one. If you are using returned errors and you ignore the error for some reason and continue on with the process and try to use a pointer that you expected to be set by a function in which you didn't check the error for, bye bye thousands of calls (if your lucky...). Long story short. Respect your errors. You can often get away with not catching exceptions in UI code,
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
I usually agree that the more restrictive option should be the default, but exceptions is... well... the exception. The whole point of the exceptions system is to limit the number of points where you need to worry about something going wrong to the place where it happens and the places where you want to do something special with it. The point of exceptions is to communicate errors and where they originate. As long as this is respected, then I am not following your complaint. you have to care about the exception at every single point in between. That's the point. If you don't annotate the function (with a throw keyword for instance), then you are forced to catch and handle the exception. If you annotate it (saying this function will throw), no catch is needed, but at least you are communicating to the next layer that this code *does* have errors that should be accounted for. nothrow by default means you can't do that Actually no guarantees by default means you can't do what I explained above.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 17:34:55 UTC, jmh530 wrote: 3) Immutability by default. Someone (somewhere) made an interesting point that it can be conceptually convenient to have the most restrictive choice as the default. I'm not sure I agree with that (maybe the most common choice used in good code), but at least immutability by default it can be helpful for concurrent programming. I am one of those that think that a language should allow you to do whatever you want, but be restrictive by default. For example immutability unless you explicitly ask for mutability (like in Rust). D sort of has the ability to do this, but it's sort of backwards due to it's defaults. For instance D is mutable by default (an inherited trait due to the C subset of the language), with the ability to explicitly mark values as immutable. Another backwards annotation is nothrow. I don't really care if something doesn't throw, I care when it throws, because then I have to do something (or my program may crash unexpectedly). Even if the enforcement is kind of there (although unannotated functions can do whatever), it would have been a better guarantee to disallow this by default. Then you have purity, garbage collection and final which also seem backwards from what they should have been (although better arguments can be made for these than immutability and nothrow). D did get thread local storage correct, but I think people are starting to get on board with having restrictions by default because it prevents bugs (and the annotations are grepable). Kind of like what Rust is doing. If this is the case, D might find itself being discarded in favor of languages that offer better guarantees. Just a thought from a random spectator ;)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 21:09:23 UTC, jmh530 wrote: On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote: Just a thought from a random spectator ;) Interesting perspective. While I find the plethora of keywords in D a tad confusing (nowhere near as confusing as rust's borrowing!), I won't try to defend Rust's syntax (and they certainly don't let you opt out of a whole lot). I'm not sure it would necessarily mean that D would be discarded in favor of something else. There's a lot to like about D as a language. If that something is more favorable why would they not? Only answers to that is stubbornness and resistance to change ;) More generally, it's a question of what paradigm you are trying to enforce. I think your paradigm is really about minimizing bugs, rather than necessarily wanting restriction. If someone wants to annotate @system and do all the dirty things they want. So be it. At least others that use their code (assuming transitiveness) knows that they are doing it. Nevertheless, I'm sure there are many who agree. My preference is a bit simpler: I want to write good code without a lot of clutter. So I think that the default option should be whatever enforces that. I don't see a reason why you should have a whole string of keywords before every function. That would depend on the syntax of the language mostly. I'm sure if designed well, you could avoid unnecessary clutter. Maybe by allow people to define their own attributes that can be used in place of many attributes (as long as it is easy to look it up). To your grepable point, another alternative is that you allow the annotations in either case so you could have a throw keyword and a nothrow keyword. Problem with opt-in constructs, is if people don't have to they generally opt-out. So expect the default to be the most common. You might get library writers writing idiomatically, but I wouldn't expect it from an application development side. Adding an extra keyword per function is probably not that big of a deal in the long run. Especially if it prevents code. All of this is kind of late for D. Wy too many breaking changes. But maybe something for D3...;)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
There's a lot to like about D as a language. Agreed.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
The promise of exceptions isn't to not have to specifically handle errors in every layer Correct me if I am wrong, but aren't exceptions in D used for general error handling? Doesn't Phobos prefer exceptions over return codes? it's to not care about exceptions in every layer. My second job was working in the sustaining department of a large company. One of the most frequent cause of bugs were people not checking errors. The fix was almost always handle the error at its source and log or signal a message to some IO informing the user. Users tend to prefer messages over complete meltdowns. Too many avoidable outages and crashes came by my desk due to this attitude. Very few domains/cases require hard fails. I don't want to pass the annotation in each and every intermediate layer Seems like an odd comment to have on the forum of a language that frequently has functions in the standard library annotated like this: pure nothrow @nogc @safe real abs(Num)(Num y) The middle layers should be written like there is no exception, and when there is one, they will simply fail and let RAII to automatically do the cleanup. Everything works better than expect... I've programmed enough Java to know how harmful nothrow-by-default is. I disagree one this. Lets agree to disagree. It doesn't really guarantee the functions not annotated as throwing won't crash Combined with other guarantees (such as immutability, thread local storage, safe memory management, side-effect free code, no recursion, etc), you can make a reasonable guarantee about the safety of your code. Of course, nothrow as the optional annotation is a different syntax for the same semantics, so it suffers from the same drawbacks but it has the benefit of seldom being use therefore seldom getting in your way. Which leads me to the final conclusion - there shouldn't be nothrow, not by default and not as special annotation! The guarantee is useful in many cases. Again lets agree to disagree. But I agree most people will opt-out. (I'm not talking about D here - this isn't worth the code breakage - but generally on programming languages) As am I. My initial comment was not meant to encourage change in the D language. But perhaps it may spin the right dials on someone else and they may think of a better fitting solution. If it's an error that the caller needs to know about - make it part of the return type. If it doesn't need to know about it - throw an exception and let someone up the line handle it. I don't agree with this. Too much to worry about. Impractical to maintain both paradigms. What errors don't you need to know about? Rust got it right - though they made it a bit cumbersome to catch `panic`s. Why would I need to catch panic? To display them nicely to the user(don't just dump to stderr - pop up a window that apologizes and prompts the user to email the exception data to the developers) or to rollback the changes(yes, there was an irrecoverable error in the program. I am not anywhere near proficient enough in Rust to really comment much on it's methods. handle it or ignore it. The process I mentioned would not prevent this in anyway. Just inform others of the decision you made that may have adverse effects on the stability of their code.
