Comment by dom96 | Hacker News Reader

Comment by dom96 | Hacker News Reader

Parent Full thread

Nice list, thank you for compiling it. I'm one of the Nim core devs so I naturally disagree. A lot on the list is painted as a negative, whereas I see it as a positive, in particular:

> * A return variable within procedures that works in the same fashion as an assembly routine with a registry

Not sure I see the parallels between assembly and I don't understand why you think this feature is negative, can you elaborate?

> * Mutable strings

I love these! No need for messing around with `StringBuilder` and the like.

> * Mutable everything

That's simply false. You can choose between mutability and immutability, in fact you can even have an immutable `string` if you really want one: `let x = "asd"`.

Now let me discuss some of your other points:

> * Hate speech against functional concepts in the community (with all the related biases that this brings)

Communities are large. A lot of us love functional programming and are bringing more and more of it into Nim.

> * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project.

Can you elaborate on who this was and how/where they were tolerated?

> * no clear consistent design direction

> * too many pragmas

> * too many pascal syntax mixed with other language syntaxes

These are mostly subjective so there isn't much I can say. Perhaps Nim just isn't for you due to its syntax, but many out there love it.

> * no module namespacing

> * modules worked not much better than C libraries... (I am generalizing)

This is false too. Every imported module is in its own namespace.

> * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text.

Did you compile with -d:release? :)

Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer all of these things since I got this impression about two years ago, and things might have changed or perhaps I got them wrong (as you say some of them are subjective).

For example, I cannot tell what compilation option I used but I remember I went for the max speed I could and that I used default Nim language constructs and default python constructs (no libs), the compilation was one of the most sold features so I believe I used the release mode and that there was a marginal difference in favouring of python (subsecond). Think However that python has also many optimizations for string manipulation and that under the cover all runtime objects are references whereas in compiled languages developers are naked in front of the CPU.

Knowing that you are core-dev I must say that building a language is very hard, and that by not bringing much to the state of the art and overselling too early it is easy to get compared and valued by subjective aspects or mere impressions. Heads up, keep it with the great work and do not take it personally, make the language shine in some unique aspect.

Also do not forget that my comment was just an unfavourable opinion based on some observations I made years ago; I could change my opinion on the language anytime and give it again a chance if it brings me any benefit for my development, or it is fun, or it has some solutions for the problems I need to solve.

Thanks for answering.

Lol, “naked in front of the CPU”

I've just been learning Nim lately, and, for the most part I like a lot of how Nim handles these things. Getting to choose between mutability and immutability, together with procs having to explictly say when they intend to mutate one of their arguments, is fantastic.

That said, I do agree with GP's first point, and can at least elaborate on it from my own perspective: At first I liked the implicit `result` variable, mostly just because it saved some typing. I quickly found it to be a source of confusing bugs, though, because accidental mismanagement of the feature would result in default values being implicitly returned rather than compiler errors. I think I ultimately agree with the Zen of Python here: Explicit is better than implicit.

Also, Nim has, by my count, three different ways of returning a value from a proc: The implicit `result` var, returning the value of the last expression, and explicit `return` statements. It has four if you count modifying ref arguments. That's pretty TMTOWTDI for my tastes.

I think what op meant about importing is one of the things I don't like about Nim. If you have

  import os

then both

  existsFile("test.txt")

and

  os.existsFile("test.txt")

will work whereas I prefer Python's forcing you to use the later. Nim is definitely a language for small teams where you can expect everybody to agree on sensible best practices and not get too clever.

Just use `from os import nil` and you'll be only able to use that module with "os" prefix.

You can follow that convention and it works but you could also just have the convention of always using os.existsFile. Again, if you follow sensible rules when using Nim you're fine and the compiler will protect from mistakes better than most compiled languages. It's just laziness and cleverness that are dangers :)

> > * Mutable strings

> I love these! No need for messing around with `StringBuilder` and the like.

D has immutable strings and no StringBuilder. Same with Python. Concatenating isn't exactly hard.

In my experience code that needs to generate strings in Python would usually use a list of strings and then use `join` at the end. What's the problem with just making strings mutable?

>What's the problem with just making strings mutable?

They are not arrays of characters until you use ASCII/KOI8 or similar encodings. So there is no point in mutating them, you need unicode normalization facilities, formatters and stuff to deal with them properly. And a proper mutable unicode string would give you a terrible performance penalty.

It also applies to things such as using strings as dictionary keys. Immutable strings allows you to use them as keys without worrying about them being modified and breaking things. It's why Ruby encourages symbols as hash keys. I don't know Nim yet so I don't know what their solution is.

It's also what allows Python to do interning of strings, since they can't change.

Nim gives you the choice of whether something is immutable or not. A `Table[T, Y]` (Nim's dictionary type) simply doesn't allow the key to be modified, no matter what the key type is.

I think this is really what it comes down to in Nim. I personally prefer immutable strings, but I don't think it would be wise to force them to always be immutable in Nim, because then you'd have this weird language wart where

    let foo = someValue
    var bar = someOtherValue

yields an immutable foo and a mutable bar for all types except strings.

I'm guessing that's a detail that's lost on folks who haven't spent much time with Nim, because the way mutability and immutability work in Nim is different from how it works in any mainstream language.

I don't know a lot about Nim, but I do know D, and there `string` is just an alias to `immutable(char)[]`. String literals are of this type. But one can manipulate mutable arrays of char all day long if needed.

How does Nim prevent modifying an object after it has been added to a Table? (Or is it always copied?)

A string will be copied if stored in a Table.

The usual problems with making things mutable: that mutable state is the root of all evil.

you are underestimating python; it has many ways of concatenating strings, such as operators, buffers, templates, streams, the join method etc also.

By having mutable strings you lose the chance of relying on them as hashable objects and constant cost for comparison and several memory optimizations for duplicates and other optimizations when you have a runtime. There is a lot to win in the big game (or perhaps not that much if someone is thinking too much into a constrained system).

mutable string: a buffer made of chars which can be modified on demand with little memory

immutable string: some abstract data which ensures some properties that can be leveraged for many purposes

can't use a mutable string as a map key and remain sane at the same time.

The last language I would take as an example for string is python.

The disastrous handling of the transition python2 to python3 with UTF-8 string and the idiosyncratic nonsense like " ''.join([str1, str2]) to concat anything speaks for themselves.

In python you can concatenarme strings using the operator plus, using templates, the method join, putting them in buffers or streams and many other ways just using the main python builtin functions just to name a few (no std library yet!)... the support for slicing is also very good and compare strings has a cost O(1) due comparing IDs instead of their content every time (optimize thanks to immutably as property).

Python 2 had several shortcomings, but not with strings I think. The transition to python 3 is more more a matter about a migration execution rather than a technical aspect related to strings (which I don’t find that terrible, especially given all facilities provided to make the migration easier to the new incompatible runtime).

> The transition to python 3 is more more a matter about a migration execution rather than a technical aspect related to strings (which I don’t find that terrible, especially given all facilities provided to make the migration easier to the new incompatible runtime).

That's political talk. In practice I never have seen a python library that do not blow up when migrated in Python 3 with a Unicode related error, because one of the dev was using python2 string as binary vector.

Regarding just the last point, I also came across a case where Python (and Node) were outperforming my Nim code (just counting lines in a file). But I just happened to be using a slow line reading thing [1].

You should definitely give Nim another shot. It has been very pleasant to use.

[1] https://github.com/nim-lang/Nim/issues/9026

>> * Mutable strings

> I love these! No need for messing around with `StringBuilder` and the like.

But if I get a string passed to me and want to hold on to it for later use, I can't be sure that someone else holding a reference to it won't modify it after I got it, right? So I will have to make a copy to be safe. Or does Nim solve this somehow?

Reply on news.ycombinator.com