4 ms·

Major negatives: - Destructors are avoided for reasons, but then a full GC is wedged in. Unless you enable a particular flag, then you have to do all memory ma

Major negatives: - Destructors are avoided for reasons, but then a full GC is wedged in. Unless you enable a particular flag, then you have to do all memory management manually, making code non-portable. Why on earth wouldn't you just use reference counting with destructors? Unless I'm missing something, that's better in every case. - Avoids LLVM because 'C code works everywhere', then doesn't support MSVC. - 1-indexed in libraries copied from Lua, 0-indexed elsewhere. That's just about the only worse thing you could do than 1-indexing everywhere. - Preprocessor model instead of the features being a more integrated component of the language. Zig has proved a function-based approach can work well and C's legacy has proved that preprocessors absolutely blow. - Aforementioned preprocessor directives get seriously wedged. You need them for polymorphism, varargs, etc. - No closures. This one seems the most baffling to me because Lua has the __call metamethod, which is exactly what you'd use for that, and they're 99% of the point of anonymous or inner functions.

edubart 5y ago
> Destructors are avoided RAII in general is avoided, because supporting it gives many unwanted consequences, increasing the language complexity and simplicity going against the goals. > Unless you enable a particular flag, then you have to do all memory management manually, making code non-portable. You can make portable code to work with or without the GC, the standard libraries do this. Of course you have more work to support both, but you usually don't need to, choose your memory model depending on your problem requirements (realtime, efficiency, etc) and stick with one. > Why on earth wouldn't you just use reference counting with destructors? Reference counting is not always ideal because it has its overhead, and the language is not to be slower than C, relying on referencing counting would impact a lot. The user can still do manual reference counting if he needs to, like some do in C. Also referencing counting requires some form of RAII which is out of the goals as already explained. > Avoids LLVM because 'C code works everywhere', then doesn't support MSVC. MSVC-Clang can be used, naive MSVC is just not really supported running directly from the Nelua compiler, but the user can grab the C file and compile himself in MSVC. Better support is not provided for MSVC just because of lack of time and interest. But Nelua supports many C compilers like GCC, TCC, Clang. Supporting more backends than just LLVM is still better than not officially supporting MSVC. > 1-indexed in libraries copied from Lua, 0-indexed elsewhere. 1-indexing is used in just a few standard library functions for compatibility with Lua style APIs. On daily use this usually matters little, also you can either make your code 1-indexed in Lua style, or 0-indexed in systems programming style, it's up to your choice. The language is agnostic to 1/0-indexing, just some libraries providing Lua style APIs use it, you could completely ignore and not use them, you can not even use the standard libraries or bring your own (like in C). > Preprocessor model instead of the features being a more integrated component of the language. Aforementioned preprocessor directives get seriously wedged. You need them for polymorphism, varargs, etc. The language specification and grammar can remain more minimal, by having a capable preprocessor, instead of having many syntax, semantics and rules. Also Nelua preprocessor is not really just a preprocessor, as it provides the context of the compiler itself while compiling, this gives the language some powerful capabilities that only meta-programming the language to understand better. Calling a preprocessor does not do it justice, but the name is used due the lack of a better name. > No closures. This one seems the most baffling to me because Lua has the __call metamethod, which is exactly what you'd use for that, and they're 99% of the point of anonymous or inner functions. The language is under development, not officially released yet, and this feature is not available yet but on the roadmap. Nevertheless people can code fine without closures, many code in C without closures for example.
- hyperhopper 5y ago
  Having some very widely used things being 0 indexed, and others 1 indexed, kind of points to a problem in the language, regardless of if it's technically a language syntax issue: At the end of the day you're still going to have a ton of time wasted by devs having to check, and there will be bugs eventually of things being not converted or double converted between the two index schemas
- nextaccountic 5y ago
  Hello, are you the language author? I've a question, the page says > Safe > Nelua tries to be safe by default for the user by minimizing undefined behavior and doing both compile-time checks and runtime checks. And > Optional GC > Nelua uses a garbage collector by default, but it is completely optional and can be replaced by manual memory management for predictable runtime performance and for use in real-time applications, such as game engines and operational systems. But of course, if one prefers manual memory management, then the code will be unsafe, right? Because use-after-free might occur. (More specifically, free() is always unsafe in every low level lang, unless you have some static checking like Rust's borrow checker or ZZ and ATS compile-time proofs, which I think nelua doesn't have.)
  - edubart 5y ago
    You are correct, when not using the GC and doing manual memory management the code will be unsafe as similar as in C, but the language generate some runtime checks (that can be disabled) to minimize undefined behavior. Nelua does not provide safety semantics like Rust because this increases the language complexity a lot, thus out of the goals. Nelua is not another safe language, and the compiler will not stand in your way when doing unsafe things, the user can do unsafe things like in C.
    - nextaccountic 5y ago
      Okay, thanks! And props for making a simple language.
moonchild 5y ago
> 1-indexed in libraries copied from Lua, 0-indexed elsewhere. That's just about the only worse thing you could do than 1-indexing everywhere I'll do you one worse: in APL, you can set the index origin to 1 or 0 at will using the special variable ⎕IO. APL also uses dynamic scoping, so if you're in the habit of passing functions around, zaniness will result. (Thankfully this is not common.) There was even a practice at one point of writing code that would work correctly with any value of ⎕IO.
xiphias2 5y ago
Also GC by default and systems programming language just don't mix. Rust tried to have GC in it at the early stage of development, but the developers realized that it must be get rid of to make it compete with C/C++.
- pull_my_finger 5y ago
  > Also GC by default and systems programming... GC is _not_ the default though. Not sure why you brought that up.
  - xiphias2 5y ago
    ,, Nelua uses a garbage collector by default, but it is completely optional and can be replaced by manual memory management''
    - skocznymroczny 5y ago
      Sounds like D, where D is also in theory optional, but in reality most of the standard library and external libraries rely on GC.
davidthewatson 5y ago
I'd suggest you submit a pull request, but then you'd get this response from the PR parser: "Nelua is open source, but not very open to contributions in the form of pull requests, if you would like something fixed or implemented in the core language try first submitting a bug report or opening a discussion instead of doing a PR. The authors prefer it this way, so that the ideal solution is always provided, without unwanted consequences on the project, thus keeping the quality of the software." See https://github.com/edubart/nelua-lang/blob/bb5e71784f4065d255e0ef3bc27b6ce06191e370/CONTRIBUTING.md https://github.com/edubart/nelua-lang/blob/bb5e71784f4065d25...

edubart 5y ago

> Destructors are avoided RAII in general is avoided, because supporting it gives many unwanted consequences, increasing the language complexity and simplicity going against the goals. > Unless you enable a particular flag, then you have to do all memory management manually, making code non-portable. You can make portable code to work with or without the GC, the standard libraries do this. Of course you have more work to support both, but you usually don't need to, choose your memory model depending on your problem requirements (realtime, efficiency, etc) and stick with one. > Why on earth wouldn't you just use reference counting with destructors? Reference counting is not always ideal because it has its overhead, and the language is not to be slower than C, relying on referencing counting would impact a lot. The user can still do manual reference counting if he needs to, like some do in C. Also referencing counting requires some form of RAII which is out of the goals as already explained. > Avoids LLVM because 'C code works everywhere', then doesn't support MSVC. MSVC-Clang can be used, naive MSVC is just not really supported running directly from the Nelua compiler, but the user can grab the C file and compile himself in MSVC. Better support is not provided for MSVC just because of lack of time and interest. But Nelua supports many C compilers like GCC, TCC, Clang. Supporting more backends than just LLVM is still better than not officially supporting MSVC. > 1-indexed in libraries copied from Lua, 0-indexed elsewhere. 1-indexing is used in just a few standard library functions for compatibility with Lua style APIs. On daily use this usually matters little, also you can either make your code 1-indexed in Lua style, or 0-indexed in systems programming style, it's up to your choice. The language is agnostic to 1/0-indexing, just some libraries providing Lua style APIs use it, you could completely ignore and not use them, you can not even use the standard libraries or bring your own (like in C). > Preprocessor model instead of the features being a more integrated component of the language. Aforementioned preprocessor directives get seriously wedged. You need them for polymorphism, varargs, etc. The language specification and grammar can remain more minimal, by having a capable preprocessor, instead of having many syntax, semantics and rules. Also Nelua preprocessor is not really just a preprocessor, as it provides the context of the compiler itself while compiling, this gives the language some powerful capabilities that only meta-programming the language to understand better. Calling a preprocessor does not do it justice, but the name is used due the lack of a better name. > No closures. This one seems the most baffling to me because Lua has the __call metamethod, which is exactly what you'd use for that, and they're 99% of the point of anonymous or inner functions. The language is under development, not officially released yet, and this feature is not available yet but on the roadmap. Nevertheless people can code fine without closures, many code in C without closures for example.

hyperhopper 5y ago
Having some very widely used things being 0 indexed, and others 1 indexed, kind of points to a problem in the language, regardless of if it's technically a language syntax issue: At the end of the day you're still going to have a ton of time wasted by devs having to check, and there will be bugs eventually of things being not converted or double converted between the two index schemas
nextaccountic 5y ago
Hello, are you the language author? I've a question, the page says > Safe > Nelua tries to be safe by default for the user by minimizing undefined behavior and doing both compile-time checks and runtime checks. And > Optional GC > Nelua uses a garbage collector by default, but it is completely optional and can be replaced by manual memory management for predictable runtime performance and for use in real-time applications, such as game engines and operational systems. But of course, if one prefers manual memory management, then the code will be unsafe, right? Because use-after-free might occur. (More specifically, free() is always unsafe in every low level lang, unless you have some static checking like Rust's borrow checker or ZZ and ATS compile-time proofs, which I think nelua doesn't have.)
- edubart 5y ago
  You are correct, when not using the GC and doing manual memory management the code will be unsafe as similar as in C, but the language generate some runtime checks (that can be disabled) to minimize undefined behavior. Nelua does not provide safety semantics like Rust because this increases the language complexity a lot, thus out of the goals. Nelua is not another safe language, and the compiler will not stand in your way when doing unsafe things, the user can do unsafe things like in C.
  - nextaccountic 5y ago
    Okay, thanks! And props for making a simple language.

moonchild 5y ago

> 1-indexed in libraries copied from Lua, 0-indexed elsewhere. That's just about the only worse thing you could do than 1-indexing everywhere I'll do you one worse: in APL, you can set the index origin to 1 or 0 at will using the special variable ⎕IO. APL also uses dynamic scoping, so if you're in the habit of passing functions around, zaniness will result. (Thankfully this is not common.) There was even a practice at one point of writing code that would work correctly with any value of ⎕IO.

xiphias2 5y ago

Also GC by default and systems programming language just don't mix. Rust tried to have GC in it at the early stage of development, but the developers realized that it must be get rid of to make it compete with C/C++.

pull_my_finger 5y ago
> Also GC by default and systems programming... GC is _not_ the default though. Not sure why you brought that up.
- xiphias2 5y ago
  ,, Nelua uses a garbage collector by default, but it is completely optional and can be replaced by manual memory management''
  - skocznymroczny 5y ago
    Sounds like D, where D is also in theory optional, but in reality most of the standard library and external libraries rely on GC.

davidthewatson 5y ago

I'd suggest you submit a pull request, but then you'd get this response from the PR parser: "Nelua is open source, but not very open to contributions in the form of pull requests, if you would like something fixed or implemented in the core language try first submitting a bug report or opening a discussion instead of doing a PR. The authors prefer it this way, so that the ideal solution is always provided, without unwanted consequences on the project, thus keeping the quality of the software." See https://github.com/edubart/nelua-lang/blob/bb5e71784f4065d255e0ef3bc27b6ce06191e370/CONTRIBUTING.md https://github.com/edubart/nelua-lang/blob/bb5e71784f4065d25...