Nim versions 1.4.4 and 1.2.10 | Hacker News Reader

Nim versions 1.4.4 and 1.2.10

nim-lang.org

119 points0-_-041 comments

One thing I'm missing in all these languages is 100% auto-completion like the one you have in Java or C#. I have yet to experience a single instance of Intellij not being able to auto-complete something or not do it completely.

I know Nim and Rust have good VS Code plugins that do that to some extent but it is not something I can rely upon.

Maybe I'm just spoiled.

Kite is doind pretty well for me in Python.

In my experience a lot of stuff that is auto-completed in java is boilerplate, stuff that I don't really need in python.

The names of methods and parameters are boilerplate? I'd be interested to hear how you avoid the need for those in Python.

Many of these languages rely on code generation, whether it's templates, macros, preprocessor. Since a lot of the code doesn't exist until compile time, it's hard to have the same level of autocomplete as in Java/C#, where everything is basically known from the start.

That can be a minor complication compared to just, writing a good autocomplete system at all. Microsoft went to a lot of effort, they have some good video talks about it out there. But being able to give compiler feedback in realtime requires thinking about the compiler with that in mind from the start, other wise it is too slow and resource consuming.

This issue is taken seriously and there are plans for improving developer tooling:

https://github.com/nim-lang/RFCs/issues/300

Most languages (that aren't Java) don't really need autocomplete.

Nim, in particular, has rather terse but elegant ways to package abstractions so that use is "obviously" locally scoped.

Just as one example (more fully elaborated here [1]), there is no pointer arithmetic by default, but one can write a tiny little template to add those operators and then invoke it in a local scope like:

    ...surrounding code...
    ptrMath:
      let address = base + offset
    ...surrounding code...

In this way many different & arbitrary "generally unsafe but also sometimes very convenient" constructs can still be used at an author's discretion, but be used in a way to make a reader (perhaps) pay better attention in a way that is more specific than some "generically 'unsafe'" block.

This is, of course, just the tip of a meta-programming iceberg.

[1] https://forum.nim-lang.org/t/1188#7366

If you mean that autocomplete saves you less typing in other languages, I agree, but as long as it's a language with methods (where you're not always sure how the method you want to use is called) and parameters (where you're not always sure about the order), autocomplete is helpful. Of course, if you're a rockstar ninja genius who has every single method of every single class memorized, you're not gonna need it, but us mere mortals appreciate it...

Nim (like Python) has keyword argument calling that softens the need to remember the out-of-n! order of parameters (by either author|reader). I.e. you can say at the call site `myAPIcall(foo=1, bar="hi")` even if the definition is `proc myAPIcall(bar: string, foo: int)`.

Arguably, this puts more pressure on code completion systems figuring out parameter names. So, I am not really disagreeing with @rob74 -- just adding some color related to this specific programming language.

I've always been a bit mystified that named parameter calling was not far more popular. Its use in programming languages seems quantitatively rare, but the upsides seem far more valuable than any downsides. Its use for either short or long options when calling commands has been a very strong de facto standard since, well, the dawn of commands (there are always exceptions, of course).

I guess you can code without auto-complete but that would mean having to check the documentation at every step instead of having it auto-completed on the go. Depends what people prefer, for me it's a step back.

When I started enjoying autocomplete Java did not even exist!

C and C++ development on VC++ on Windows and XEmacs on UNIX.

I'm very spoiled from C# and Visual Studio 2019. I have recently started working professionally in Rust and while I do feel the drop in ergonomics, half of the problem is from downgrading from full IDE like Visual Studio to Visual Studio Code. I'd say what I currently miss the most in Rust+VSCode is better debugging experience. I used to mostly develop features and fix bugs via interactively using the debugger and immediate window in C# while here it's not possible

I'm normally pretty anti IDE but one thing visual studio got really really right was the debugger UI. GDB isn't too bad but it's no visual studio.

FYI last week on my windows box : I miss clicked and launched a rust test in debug mode which launched the integrated debugger view in vscode but of course the test ran to completion without stopping since I didn't set a breakpoint, that triggered curiosity in human me, so I set a breakpoint in vscode, clicked "debug" and voilà, it actually worked and I didn't feel like I had to setup anything in particular. (I have VS2019 installed, and use the rust-analyzer vscode plugin)

CLion offers a debugger for Rust.

This is the biggest downside I've found with Elixir as well, it's just not as easy/enjoyable to write code without really good autocomplete.

There is an official Nim plugin from JetBrains now. It won't be as polished as Java support for obvious reasons, but at least you can stick with your preferred environment.

Excellent news, thank you !

In which editor? This would really help me. IdE support and no pandas/numpy are the main things holding me back from full nim adoption

There is NimData [1] and ggplotnim [2] and Arraymancer [3]. Also, neovim works well with the alaviss plugin [4], though it's not quite a full IDE. Most Nim coders use VS.

[1] https://github.com/bluenote10/NimData

[2] https://github.com/Vindaar/ggplotnim

[3] https://github.com/mratsim/Arraymancer

[4] https://github.com/alaviss/nim.nvim

I know your pain. Have you used Rust lately with the Rust-Analyzer plugin? Don't use the old "rls" one. You might be pretty happy with it these days.

It's great indeed and it's advancing quickly. I hope it'll reach 100% coverage at some point but I don't know whether that's achievable.

Oh right, I was using "rls" as part of the MS VSCode plugin and gave up using Rust in the end as it was so bad to me. I might check this one out.

25 years ago I would have said people were just being lazy for expecting autocompletion.

Now I think we should demand autocompletion, and much more.

We should want both our languages to be smarter (type inference) so we can type less, and our tools are should know what we want to type.

https://www.tabnine.com/

Type strong to type less. :)

If I don't remember how to use some function it's a sign that I have to read the documentation. The documentation can have important tips around performance, security & recommended usage patterns that I need to know.

And if you don't remember a lot of methods it means you might be out of your league and need to read the documentation and go through a tutorial to understand what you are doing.

Keyword, method and variable completion is ok, but overzealous completion encourage churning out code on "autopilot".

If you are not Torvalds it's better to write code good slowly than the opposite.

Unfortunately, there are functions where I know how to use them, and still can't reliably spell them correctly. Also it helps preventing confusion between languages. Is it length or size? Are the math operations qualified with type information or overloaded (e.g., labs/abs/fabs in cmath)?

Lastly, at least the auto completion I used in intellij and visual studio is a peak into the documentation, it lists the full method signature, including all other methods, and opens the documentation on click.

My feeling is we (developers) should be able to figure out how to use a function reliably and safely from just the signature for 95% of functions...if you can't then the API is badly written.

The rust plugin for intellij is pretty good and keeps getting better, both in terms of intellisense and refactoring.

nimsuggest and nim-mode work quite well in Emacs with auto-complete, go to definition, and find references. There's also an LSP server in the works IIRC.

If you want good auto-complete for less popular languages, you need to use an editor which is both popular enough and makes writing completers easy enough. From my experience, Emacs with company or auto-complete packages is just like that, and I have auto-completion set up for 10+ languages, but I'm sure there are other editors out there you could use.

Congratulations to the Nim development team for another solid release. I'm really enjoying working with Nim.

I wish more effort was made by the NIM team to focus on web development as a use for NIM.

A Javascript backend is better focus than one usually sees. There are also quite a few web dev projects in the nimbleverse, and https://forum.nim-lang.org is written in Nim and there is much support code in the Nim stdlib.

Frameworks/simplifications are better left to the broader community that knows their own web-needs. It took many years for things like Django for Python or Rails for Ruby to appear. Even now, those are not part of the respective core languages, but external projects.

Anyway, it's open source. Instead of just wishing for more effort, adding your own effort might be even better! :-)

This! Nim has shown it has capable JS support and web support, but it can't do everything on it's own. There are web frameworks popping up but they need more contributors to them. But one can get far right now with Nim and web development.

Agreed that there is room for improvement, but the Nim community is working on some promising web projects. Prologue framework, Norm (orm), and Karax (FE framework) are all great examples of how Nim can excel in the web environment.

What do you currently feel is missing for web development? I'm using Karax on a few projects and I really like it

How does Nim's static typing compared to TypeScript and (Simple) Haskell?

Comparable to TypeScript, but a little weaker in the advanced features. Nim object types and tuple types are similar to TypeScript interface definitions and just as light weight. The type inference is pretty similar, but Nim's is a little weaker. Nim also has object variants, which can achieve most of what I want out of union types. TypeScript has a pretty long list of advanced typing features, like key types, mapped types, and conditional types, which Nim cannot express. But the Nim macro system can work here in taking code and modifying it before the type system runs.

Sorry, not just a little weaker. A _lot_ weaker. It lacks union and intersection types, and to my mind this is kind of inexcusable in a modern language. I'm not even talking about pattern matching, union types are simply necessary in an expression oriented language. It's that simple. Then, intersection types are the dual of union types.

(By the way, Rust lacks union types too, and it makes the language absolutely insufferable. Simply adding, say, a print statement as the last expression in one branch of an if statement changes that branches type, producing an error due to A/B type mismatches There is often no valid reason, e.g. in the case your branch isn't assigned to an expression. Even if it were, the type of that expression should be a union type: problem solved. It's so basic and so obvious, that Algol 68 got it right back in the 60s. Why on earth would you add discriminated unions but _not_ unions? It makes no sense.)

(I'm going to go off on a second tangent now: can we please just dust off the cool ideas in that language, like references represented in the type system, rather than replicating C++'s god-awful value categories and even _more_ reference squiggles? Consider how C++'s awfully complex [] move semantics could be expressed in that language!]).

[] https://www.reddit.com/r/cpp/comments/ll2azr/move_simply_sut...

Relevant sections [1] [2] in the Nim Manual might be of interest. Nim has nice type classes and can constrain generics to only apply to one (or a sum type of them, etc.). It also has concepts [3] that are a sort of compile-time duck-typing construct (under active development).

[1] https://nim-lang.org/1.4.4/manual.html#types

[2] https://nim-lang.org/1.4.4/manual.html#generics

[3] https://nim-lang.github.io/Nim/manual_experimental.html#conc...

Reply on news.ycombinator.com