arc776

6 ms·

1.
by arc776 4y ago
> There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it. I'm really curious, do you have any examples? I can't think of any that wouldn't be better s
2.
by arc776 4y ago
Oh yes, just like you can never find anything in Google because it's case insensitive.
3.
by arc776 4y ago
Case sensitivity is worse in every way IMO. Look at Nim's implementation of UFCS, which means `foo(bar) == bar.foo`. This means only one possible `foo` that takes type of `bar` can be invoked. There's no ambiguity if `foo` is a me
4.
by arc776 4y ago
I'm a full time Nim developer and have been for over half a decade. It's completely spoiled me for other languages, it is just ridiculously productive. Rather than an ah-ha moment, it was more a gradual transition from "where
5.
by arc776 4y ago
> It's less that "Reddit uses NIM" but rather one guy at Reddit uses NIM to do work. They are the same thing. No one is saying Reddit bases their entire infrastructure on Nim. The point is just that the language is being s
6.
by arc776 4y ago
Yeah definitely. Unlike Python though it's fast and light on memory, so once you have a prototype it's often already performant enough to be developed into a final product. Things like that save a lot of time and money in the long
7.
by arc776 4y ago
> TypeScript is specifically a good choice because it has been built with the browser and the backend in mind. Sure, if your only use case is web front/back end uniformity. My use case covers web front and back end, but also custom
8.
by arc776 4y ago
> In the general case I think you underestimate how performant JavaScript JITs are these days. No, I'm well aware of JS and WASM performance, internals, and pitfalls. > For 99.9% of use cases the performance is enough. Again, it
9.
by arc776 4y ago
> you can build the backend and frontend in one language (TypeScript) Sure, from the uniformity side, but what about performance? It's not just latency performance either, it's resource performance and overheads, such as with e
10.
by arc776 4y ago
Only if you consider the web side. Backend and frontend in the same language is a massive feature for many reasons, not least performance and uniformity. Adding TypeScript is increasing interface friction and complexity, instead of simplify
11.
by arc776 4y ago
> the real killer feature to me is the javascript target Agree, this is amazing because you can share code and data structures between front and backend (for example: https://github.com/karaxnim/karax ). Also, it&#x2
12.
by arc776 4y ago
100% my experience too. GC in Nim is a rounding error at worst and is often statically elided, anyway. Performance is almost entirely about memory access patterns and you have the same access to this as C. In other words, performance in Nim
13.
by arc776 4y ago
> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Like this: type FooManager = object var foo_manager: FooManager > Now... are these colliding?
14.
by arc776 4y ago
Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as an anecdote thou
15.
by arc776 4y ago
> other people's code can, refer to the same thing by different names They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to clash th
16.
by arc776 4y ago
> the automatic conversion from camel-case to snake-case... very much so. If an identifier clashes, you get a compile time ambiguity error. It means `is_OK` and `isOk` will report ambiguous identifiers and force you to qualify it or rena
17.
by arc776 4y ago
Nim's super power is being ridiculously productive (at least for me). Hack stuff out like a Python script, yet it runs really fast and is a tiny self contained executable, so you can just use it as is and move on to the next task. If y
18.
by arc776 5y ago
Nim - https://nim-lang.org/ Lets you mix and match other libraries with their native ABI as it compiles to C, C++, ObjC and JS + has excellent FFI.
19.
by arc776 5y ago
We don't want to automatically convert between `int` and `float` because there's a loss of information, since floats aren't able to represent integers precisely. However, we don't need to specify types until the point of
20.
by arc776 5y ago
Oh, just to add that let b: uint = uint(a) # can be written as: let b = uint(a) The type is inferred from the right hand side during assignment. The only reason I wrote this let b: uint = a is because in my exampl
21.
by arc776 5y ago
> So why can't Nim infer from `let b: uint = a` It "can", but it's a design decision not to by default because mixing `uint` and `int` is usually a bad idea. This is telling the compiler you want to add an `int` that
22.
by arc776 5y ago
> not slowing one's work Put back into context, your reply makes sense as these popular libraries are pretty battle tested. Having said that, it is a valid point that type hints being voluntary means they can only be relied upon wit
23.
by arc776 5y ago
> Compare with dynamic languages (or structural typing, Go etc) that only care that things "quack like a duck". Go is a statically typed language. Unless you're referring to interfaces at run time? > I'm saying the
24.
by arc776 5y ago
> just doesn't slow one's work down very frequently in daily practice. Well, maybe you don't feel it slows you down, but it is manual work you must do to get a reliable product only because of dynamic typing. Not only that
25.
by arc776 5y ago
In Nim you can even convert JSON to static types! https://nim-lang.org/docs/json.html#to%2CJsonNode%2Ctypedesc... Now you get type checking on JSON at compile time :)
26.
by arc776 5y ago
> I think the message is more nuanced I thought it was more nuanced too as they were explaining how integer types can be derived, until I finished the article, and they really did just seem to be complaining that there's a mismatch
27.
by arc776 5y ago
Thanks for your reply. It's interesting to know what the perceived weaknesses and strengths are. Nim does have pattern matching but it's rarely used, whereas it seems to be used a lot in Rust (probably because of the prominence of
28.
by arc776 5y ago
The syntax is what attracts me to Nim too. Why use Rust over Nim in this case? Is it Rust's static lifetime constraints? Is there some feature you would miss if you used Nim instead? Or would you prefer to use Rust because more organis
29.
by arc776 5y ago
> I'm also not a fan of canonicalizing variables so you can write them any way you want to, since it harms grepping and the consistency of code. Perhaps surprisingly, the opposite is true. You can enforce a style and a library that
30.
by arc776 5y ago
Thanks for making these, I actually had no idea these existed! I don't "need" them now but seeing these gives me ideas for projects and makes future things easier. I wish discovery of community libraries was higher, I'm

More ›