This is a rather long read, but since we'd like to change Nim's exception hierarchy anyway, we need to consider to replace the existing exception mechanism with something better, we should look around to see where the state of the art is heading:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf
I like "Let it crash" Erlang, haha.
I suggest having non pure function to be able having some block of body that handle in case it returns error e.g.
proc readALine(filename: string): string =
result = ""
var file = open(filename).whenError:
# return empty string when some error happens
# during opening it
return
# in case of success, the function continues
result = readLine file
close file
Exception is easy to misuse, even worse, some people use it as if it's like ordinary control-flow.
Thanks for the summary, I didn't read the whole document :P
As far I can tell, it's to limit exception to something simpler (like value-type object or reference-type that not accessing OS resource) instead of catch-em all .
Personally, I prefer function should return something, maybe users can provide the default value, and they can choose the path of operations based on value returned.
There's always a bigger system in which the nim program will be embedded. It could be the responsibility of the next layer to handle a catastrophically failed nim program. The program can't do everything on its own. For example the operating system can monitor available memory and provide warnings moving outwards without nim being the wiser. There is a lot of philosophy and ideology in the first three pages thatneed to be reviewed.
Does fail fast mean that we can't get the programmers to meet preconditions and we fail the business project?
Mark
There's always a bigger system in which the nim program will be embedded.
I think that's exactly the assumption that Nim should not make. Nim is a systems programming language and as such should be designed to work without an OS. In fact, this whole "let it crash / exit / quit" idea only makes sense if you have an OS or some comparable supervisor, preferably with memory isolation.
The bigger system is most notably the human society that has processes for requesting the computer run, evaluating the results, requesting a different run, etc. Somebody has to plug in the computer and somebody has to know that it has successfully entered service and when it isn't working as desired.
The paper refers to reporting some anomalies to a human. Who? The keyboard operator? Their supervisor? Customer support? Field engineering? Can the nim spec identify human roles that are external to the program?
I was attracted to and intend to make use of nim because of --gc:none (and compile to c, not c++.) The availability of --os:standalone is convenient but it isn't too hard to scrape the important parts of generated c into an embedded system regardless. So I'm on board with not needing a co-located computer-based os. It is a requirement for my projects.
So back to some specifics. Is there a www registry of xml or uuid exceptions that can fit in a fixed-size value? Can we pick a specific exception for discussion? How about divide by 0? What will be its uuid?
I see that nimforum uses exceptions. I'll see if I can see a pattern to how they are used.
Regards, Mark
Which space? Systems programming? C++ does that and more. C++ is also used in scientific computing, and while Rust will probably attract a few users there, I think most will find it less useful there. Nim has overloading and good macros. C++ templates are very powerful, and Rust generics are not as powerful (I think Nim is also less powerful here but has good macros) and their macros are not great yet.
Rust will become a serious competitor, but I'd say "not quite ready yet". I like it though, lots of good ideas. Steal what's useful that fits into Nim and look at the other parts for inspiration.
BTW, I work in a C++ shop that's banned exceptions, but uses template metaprogramming. Google style guide bans exceptions and template metaprogramming. I understand that exceptions can be good (like GC!) but they're not zero cost.
Dom, It seems you really don't want Nim to compete with Rust; why?
I actually came to Nim looking for a better Rust, or more generally a better systems language that isn't C++. My intuition tells me I'm not the only one. I think there is a reasonable subset of the community that wants this. Then again, I haven't seen the latest Nim Survey results :-P
Where do you think Nim should position itself in the programming language market?
I do want Nim to compete with Rust. I think it's a mistake to chase every feature it has when we are so early to a 1.0 release. Even if Nim gets rid of GC and exceptions, Rust will have had a large lead on Nim. We need to distinguish ourselves from Rust, not copy its every feature.
By chasing Rust you're also pushing away those users that want a systems programming language that offers a good balance between zero-cost abstractions and ease-of-use. I started using Nim because I wanted an alternative to Python and there are many others just like me. A GC and exceptions are familiar to us.
Where do you think Nim should position itself in the programming language market?
As a fast statically-typed and highly portable Python. This forum is a good example of this, Nim is running in your browser and communicating with a server that is also written in Nim.
I think it's a mistake to chase every feature it has when we are so early to a 1.0 release
I don't know what Araq's plans are, but I never thought that this was a 1.0 feature? I thought we were just discussing the idea as a valid RFC to put on the roadmap. I agree that getting 1.0 finished is more important than this.
We need to distinguish ourselves from Rust, not copy its every feature. Rust definitely does not work like this RFC, it would very much be a distinguishing feature from Rust.
I never implied that we should be copying every Rust feature, and I don't think anybody else has in this thread either. I do believe in stealing the best parts of other ecosytems, but nobody is advocating for a whole sale copy of Rust or any other language.
A GC and exceptions are familiar to us.
Nim has a lot of things that are different from Python, such as macros and static typing. Does that mean we should not pursue alternative features just because they are not familiar to a Python audience?
As a fast statically-typed and highly portable Python.
I disagree with this, there is already cython and the like. But hopefully we can live together anyway. I actually think Nim can be a language that makes us both happy :-P
Nim is running in your browser and communicating with a server that is also written in Nim.
This is an awesome feature. It is definitely something I love about Nim. I don't want to take that away. In fact, I want to take it to the next step: Nim in the browser communicating with a server written in Nim that is running on an operating system written in Nim.
Nim is the only language I've seen that has been able to reasonably extend that far across a tech stack while still maintaining sane syntax and semantics. I want to keep pushing in that direction. I know it won't happen overnight, I don't think anybody expects that. But I do think it's an important goal to pursue.
The Destructor runtime is the other big example in this same vein. It is not a copy of another language feature, but more like a hybrid of C++ and Rust. It's a unique feature and It's the best of both worlds in my opinion.
It allows Nim to be used for more use cases, like writing shared libraries that can interact with other languages much easier, or writing lower level systems code, while not changing the semantics of the language so much that it can't be used for the current use cases.
The GC isn't going away either. The GC is still there if you want or need it. This RFC feels very much in the same vein, or at least I think we can have a compromise that gets us there.
Nim is the only language I've seen that has been able to reasonably extend that far across a tech stack while still maintaining sane syntax and semantics.
Yes, for me that's Nim's top selling point, one could call it abstraction level scaling. It would be okay to market the language as "a type safe python" or "some of the best parts of C++, Rust and Go combined" to different audiences, if these labels are half-way true.
But the core thing of Nim is IMHO that it lets you write everything from a device driver to a high-abstraction-level application. Without learning every detail of the tons of powerful features which were bolted onto C++ over the years, without wrestling the compiler over the ownership of everything like in Rust, without the awful limitations of Go and without puking every high-level abstraction in the source code on the shoes of the run-time like JavaScript.
Two main features which support this are IMHO type classes (concepts and generics) and meta-programming (templates and macros). If these are implemented well and function together well (and they have to), I will be much less nervous about Nim's future.
Somehow the discussion getting derailed :P
Personally, I use exception when the function I need to use is throwing and handle when it throws and return the default value. If possible, I would avoid several try-except layers and keep it flat.
So, having simple exception is preferable. And it's good to know C++ going to that direction too :D
Somehow the discussion getting derailed :P
Yes, but the people with informed on-topic opinions emigrated here, so derailing what's left wasn't that problematic :o)