Nim 2.0.0 RC2

Nowadays atleast Nim has multiple compenent http libraries, see https://nimble.directory/search?query=http

Companies base their choice of tools on how easy is to find developers to hire, therefore Nim and other similarly young but very powerful/optimized languages (Crystal, Zig, ...) need many independent developers, who can base their choice purely on technical merits and personal taste, to use it and put it into their resumes before the corporate world can notice and add them into their list of accepted tools. It's a quite slow process though.

I had a brief look at F#, it didn't fit my mental model and I looked away. Meanwhile I do like using the tacked-on functional features in traditional languages because it allows me to get the benefits when it fits what I'm doing instead of having to fully buy in.

> Microsoft should have just made F# the C# successor.

You underestimate the importance of compatibility and familiarity for existing developers. You can show C# code to any C++, Java or even JS programmer and expect them to grasp the idea of what's going on very quickly. This is a big deal and should not be discarded lightly

F# is such a nice language. A great modern ML language on the .net runtime with full MS package support that's pretty awesome. But unlike something like Scala on the JVM F# is so simple and straightforward, it has a lot of features without feeling bloated. The fact that MS has just abandoned F# is disappointing.

> Microsoft should have just made F# the C# successor.

their target audience does not want this

Do you do FPGA designs with it, or just bare metal software?

If only it supported RV32IMAC and/or XTensa one could use it on one of the ESP32 variants.

In general you are correct. However, language adoption can skyrocket when some new library/framework arrives which has a compelling reason to switch (e.g. Rails for Ruby)

I can't see how there should be a reliable pattern in language usage like that. Javascript is more used that ever - who knows were the all-time market share peak is - but we're well beyond your 5-10 year time frame. Could you name any languages that actually have this pattern? Julia maybe.

C++ was designed in the late '70s-early 80's and reached peak popularity in the mid-to-late '90s. JavaScript appeared in the mid-'90s and didn't see broad adoption until about the '10s. I would say that the norm is for peak adoption to happen at around the 10-15 year mark of original release. Languages that get adopted faster than 7 years are unusual, and it indicates that they came out at highly opportune times to address specific needs. I'm thinking in particular of Java and Rust, for example, which both reached critical masses of adoption very quickly.

ocaml managed, but it took a significant effort to improve the general tooling ecosystem

What app are you developing with it?

he said he works on some internal tool, but not clear how wide is adaptation outside of that.

Its set to produce a compiler "Warning" by default now.

That’s just python, and I’m only half joking.

Another idea for that would be GraalVM’s Truffle. It’s not a language, more of a universal VM, but it can actually already just eval some python code, use the resulting code from Java and pass it on to JS. It also has support for any LLVM language, so C can be invoked from/be invoked from any of the aforementioned languages. And it can even optimize across language boundaries, pretty incredible.

ha - I've had my "interop" language in my head forever. FFI primarily by generating code directly into every lang (haxe-style), but ideally with a better lang behind it (imagine Python and Rust had a baby). Oh if I had the time...would be fun.

It also makes it harder to grep. If you're on a team of 10 devs someone could have accidentally forgotten an underscore sometime last year. So you can't just grep for 'ready_for_upload', you have to use 'ready_?for_?upload'

It would be one thing (but still a weird feature that calls the rest of their decision making into question) if it normalized fooBar into foo_bar (or the opposite). But that's not what it actually does, it normalizes both into foobar, which introduces new ambiguities. In fact, you can often end up with the opposite meaning! For example, a few Swedish examples:

- hand tvättas (wash your hands) != handtvättas (wash by hand)

- sjuk gymnast (sick gymnast) != sjukgymnast (physical therapist)

- sjuk sköterska (sick nurse) != sjuksköterska (hospital nurse)

- lång hårig (tall and hairy) != långhårig (long-haired)

- sjö nära tomt (lake near a house) != sjönära tomt (house near a lake)

Another situation is when you have to interface with some other language that doesn't have this feature and where nameLikeThis and name_like_this both exist and mean different things. Thus requiring you to work it around with a third naming convention.

Here's one illustration: https://github.com/nim-lang/RFCs/issues/456#issuecomment-111...

We have partial case-insensitivity in PHP. Can't say I'm very fond of it, but I'm ambivalent as long as it's not abused.

> The only situation I can imagine this causing a problem in your codebase is if you intentionally want to mix camelCase and snake_case in your codebase and these 2 meaning different things.

This is literally idiomatic Python style! Classes are TitleCase and everything else is snake_case.

I have also used a mix of camelCase and snake_case for different purposes, eg in Haskell where conventions are mixed (and I am far from an expert), I've written names like "fooBar_prev"

This is done a lot in Python Libraries the module with lower_case and class name with TitleCase . In Nim's Case (No Pun Intended) it is a fatal mistake.

I'm not sure I understand the rationale of it if using a consistent naming approach (best practice) renders it transparent, and compiler warnings alert you to instances where one is using e.g. my_var and myVar. Seems like the capability is there but the typical advice and compiler both warn against taking advantage of it. Just seems like a footgun to me. What am I missing?

Plenty of programming languages have "did you mean xxx?" in error messages. Plus using IDEs means you will mostly autocomplete identifiers anyway. I don't buy it.

Carmack's tweet seems like more of a thought provoking question than an indictment of case sensitivity. I'm not sure I am convinced that a child stumbling over case sensitivity is a smoking gun. I just explained it to my nontechnical partner and before I had finished and proposed a "what do you think?" kind of question, she had given a "oh,hmm" to the idea that "abc" and "ABC" might mean the same thing when used as variables. Again, no smoking gun here either.

Nobody wants codebases with different take_action() and Take_Action() functions. That's a straw man.

The issues are:

1. Difficult to search code. Even just case insensitivity makes this worse because often you do have names that only differ in case (but in an acceptable way, e.g. they're different kinds of thing, or namespaces). But ignoring underscores makes it much much harder - now every search needs to be a regex.

You can say "use an IDE!" and you absolutely should but you still sometimes need to search with dumb grep style tools.

2. Case insensitive rules are always more complex and difficult to remember. Where do they apply? All identifiers or just variables? What about keywords. Nim's rule is especially complex. It adds cognitive load.

3. Extra bike shedding. I imagine they added it to avoid bike shedding? But it will have the opposite effect. They should have just made a language wide convention like Rust. Nobody debates case style in Rust or indentation style in Go because the tooling and community pretty much force one style.

I fully anticipate a Nim linter that bans style variation from the canonical one. If that doesn't exist already.

IMHO from a theory POV, it violates the/my principle of least surprise. Compilers are typically strict and I'm ok with that - my mental models of programing are built around that unforgivingness and I like it, because if I play by the rules, I know there'll be no surprises (ideally). When the rules are relaxed, I have to remember more stuff. It's easier for me to know that ABC is ABC, and never abc or a_b_c.

I think I remember reading early remarks from the Nim team that you can opt-in to the symbol sensitivity but it's a marker comment per-file, or some kind of DIY preprocessor which does the same. I'd be happy if it was a CLI switch.

All that said, and in practice, clearly a lot of people are fine with this and even like it. I'd much rather Nim exist with this (IMO) oddity than not at all.

> If I'm honest, I think this is a big problem for adoption of the language.

Can confirm, it single-handedly kept me away from the language.

Pretty much all Nim projects use a consistent naming style, so this is not a problem in practice.

> Nim should take advantage of the 2.0 release to do a compatibility break in this area, maybe with a compiler flag to enable the legacy behavior.

No thanks, I don't want inconsistent naming conventions in my code.

Your argument applies to style sensitivity as well to be fair - do you search for 'MyTestFunction' or 'my_TestFunction'... or was it 'My_TestFunction', maybe 'm_Y_tEsT_fUnCtION'?

Style insensitivity lets you automate your local code (and/or through CI) to consistency for easy searching, even when external libraries YOLO their own style.

> It's incompatible with a lot of search-engines

Google and search engines are case insensitive, and mostly ignore underscores too. Let's be honest, how often would you just search for 'testfunction libraryname' on the web and get the signature you need?

My experience from using the language in production for years is that case insensitive searches will find what I want in Nim code specifically because no one can use case/underscores to make things make unique. Instead, the language uses overloading through the type system to distinguish things. This is a far more succinct, safe, and expressive way of writing code from my perspective.

It's worth noting that the first letter of an identifier is case sensitive, with the convention for types to start with a capital letter. So, you can write 'type Test = object' and 'proc test(t: Test)', then use them with 'var test: Test; test(test)' without any ambiguity, and with code completion/jump to source in VSCode (and others).

If you then add 'proc test()' with no arguments, it's still unambiguous because the functions have different signatures, so you can then write 'test()' and your second function is called.

If something is ambiguous, it's a compile time error. If you want, you can prefix modules like Python, but there's never any need. If you have two libraries with the API, same types, and function signatures (such as using two async libraries in the same program), you can just slap a generic '[T]' so it's lazily instantiated at the call site and move on.

IMHO relying on casing/underscore to distinguish identifiers is objectively worse than using the type system to statically and unambiguously prove your intent, and normalising names removes a class of identifier confusion bugs to boot. Even style guides in case sensitive languages beg us not to use case and underscores to disambiguate symbols for the confusing code it creates, and to be honest, I've yet to see a compelling argument in favour of case sensitivity beyond simply being what people are used to.

In this thread there are people who say "a convention is enough", but then don't give enough credit to the Nim convention. Maybe you are imagining a Nim library abusing this ability, and the same developer writing all different versions allowed: write_file, writefile, writeFile, w_ri_tefil_e...

Nim developers are as smart as any other, and they like and write clean codebases adhering to the convention in NEP1. The ability to mix cases is used to fix libraries without having to disrupt their users.

I've seen this kind of complains over and over: a new language emerges (e.g. Python 20-30 years ago), and what people finds the absolute showstopper is the indents instead or braces, a minimal part of the language that should not bother a competent programmer at all. The same people that were writting old PHP or old Perl, go figure, complainig that Python whitespace is ugly.

You don’t need two functions, you just mark one as {.discardable.} and the discard happens automatically. Unless I’m misunderstanding you.

`discard` isn’t part of the type signature.

The functions in the blog post have void return type because between `)` and `=` there is no `: [type]`.

The Wasm target allows you to specify imports (basically "import component Foo { methods... }") and exports, so the resulting .wasm module has those declared imports/exports. There really isn't an FFI for other targets yet, but I get a lot of requests for that, so I am thinking of how to do this now. Probably, the native targets will support import/export and generate a .o that can be linked with C/C++ Rust using the normal linker.

I’d love a really good Nim web server option, too. Something lightweight but with enough to quickly build APIs, like FastAPI in Python or maybe Chi in Go.

Even if the speed wouldn’t do it for many people over, say, FastAPI, the static typing and less insane package and dependency management than Python, and lower friction/boilerplate than Go might.

> Web frameworks by and large don't need the perf/memory of C, they're always running on high powered servers

But if they had perf/memory of C they wouldn't need to run on high powered servers!

If a language allows you to be productive and can deliver high performance that can reduce your ops complexity and your hosting bill, what's not to like?

That's what Karax provides. Then choose one of the numerous web servers available to serve it. Write additional client-side code in Nim if you want to (nim js -> esbuild). It's all there.

c++20 provides quite a list of features on top of c++11 that I use daily these days, would like to know nim keeps up with those new syntax/features as well, seems not yet.

What does some random PR have to do with anything? That is not the Nim repo

I'm pretty sure there are a lot of projects using some language just because the developer likes it. Even in a company, personal preference could still affect a lot in choosing the language though they might concern more than that.

And after that, the language might become popular because some big companies use it/develop it, or someone makes a killer library. Most reasons are just not relevant to the language itself.

I wrote a comment about it a while go:

https://news.ycombinator.com/item?id=34669902

basically Nim has several features which on their own seem great, but don't compose with each other properly. also it's been many months since I used Nim so some of the details may be outdated or misremembered but the overall gist of what i'm saying is >90% true so i don't care if anyone nitpicks this:

Nim has UFCS (uniform function call syntax). so whenever you have f(a, b), you can write a.f(b), and it means literally the same thing (until you read the fine print for the parts where it's not). and you can also omit parentheses when it's unambiguous, so you can write stuff resembling method-chaining or unix pipelines in a totally natural way: foo.bar.baz(x, y).qaaz().quux is the same as quux(qaaz(baz(bar(foo()), x, y))) and way more readable bc less parens and the execution order is left-to-right. it's so, SO, tempting to write lots of code this way, because it's such a rare language feature, and it fits with the way I think.

but it's not just functions, there are a lot of function-like things, i.e. the stuff you can write as f(a, b): methods, ad-hoc overloaded functions, generic functions, templates, macros, iterators, etc. but things don't work consistently across all combinations of function-like objects, argument types, and function-call syntaxes. iterators is one part where the abstraction breaks, and iirc there are a few others (certain kinds of templates?).

there are two kinds of iterators: inline, and closure. inline iterators are meant to be a zero-cost abstraction, basically a for loop that gets inlined at the call site by the compiler, and they're not first-class objects. closure iterators otoh are first-class objects and can be passed around, but they have runtime overhead (idk how much). so lets say you want to make an API that consumes an iterator and does something useful with it, e.g. higher-order functions like python's itertools (Nim advertises itself as being similar to python in important respects like this so it's a valid comparison). great, so then you try to use it on the builtin "lines" iterator (the one that splits a file at newlines and yields each line as a string). oh no, you can't, because "lines" is an inline iterator so you can't pass it to a function.

fine, so the language has handed me this pile of dogshit that I can't do anything useful with directly. surely this would be a common enough problem that there must be a helper macro in the stdlib that lets you convert between inline and closure iterators? nope, there isn't. okay but writing one should be trivial, right, given the vaunted metaprogramming capabilities of Nim? well, I tried writing one in the most obvious way. and it behaved differently when I used UFCS vs not. and when I experimentally called it on a closure iterator (expecting it to be effectively a no-op), the compiler segfaulted. and when I asked about this in the discord, nobody could figure out why it didn't work. later I found an implementation of inline<->closure conversion macro and it was like hundreds of lines of gensym fuckery and god knows what. i don't know why it should be so complicated.

oh and btw, even with the supposedly "first-class" closure iterators, it is impossible to write a generic function like f: iterable[T] -> iterator[T]. you have to use a template. and the syntax for doing it is counterintuitive. and the "iterable" keyword in the function signature doesn't mean what you think anyway. when you ask in the chat "oh my god just please tell me how to do lazy iteration", they say "don't worry it's easy, just use [x]", where x is one of half a dozen mutually incompatible 3rd party libraries, each one expecting you to learn its own mad little DSL that you can't really extend or integrate with normal Nim code. and then you look at the implementation: enormous inscrutable macros, which are that way presumably to work around all the crap I described in the last paragraphs and even more I don't know about. I don't want that in my dependencies! the docs don't prepare you for all this complexity; templates/macros/iterators are documented like that "draw the rest of the fucking owl" meme.

the "sugar" module has a macro to let you write lambdas more compactly. but if you try to do something straightforward like pass one into sort() as a comparison function (ie the kind of stuff that comprises 95% of the legit uses of anonymous functions in grugbrain code), it doesn't fucking work reliably. like it will probably work on a simple case like sorting a bunch of strings by their length, but the minute you introduce some complication like generics it all falls apart and the compiler spams ten pages of indecipherable type errors at you. and then they'll say "just use sortIt" -- no, fuck you, i will never use sortIt, i hate anaphoric macros, just let me pass in an honest function.

what I'm getting at is, you know how frictionless it is to sling around iterators and generators and first-class functions and so on in Python, even with mypy --strict? and you read about Nim's UFCS and macros and generics and you think "great, best of both worlds", imagining yourself as a ninja doing "myfile.txt".lines.map(func1).filter(func2).max(key=blah).frobnicate, and it all Just Works[tm]? well the reality is as frictionless as dragging your face across raw asphalt.

is this production ready? last time I checked GC for c and c++ and I don't think c and c++ are really GC-friendly by design. After nim's transpiling, is c/c++ using those data structures and functions somehow to manage resources(similar to RAII) but not really acting as a GC in c/c++?