Viewing profile — arc776
arc776
HN member- Joined
- Thu, Jan 28, 2016, 7:39 PM UTC
- HN karma
- 256
- Public activity
- 101 items
- HN profile
- View on Hacker News ↗
About arc776
No profile information was provided.
Recent public activity
-
comment
Comment #34100022
> 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 …
-
comment
Comment #34099884
Oh yes, just like you can never find anything in Google because it's case insensitive.
-
comment
Comment #34099575
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…
-
comment
Comment #34098400
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,…
-
comment
Comment #33604506
> 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 …
-
comment
Comment #33604397
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 …
-
comment
Comment #33578787
> 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 …
-
comment
Comment #33568963
> 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% o…
-
comment
Comment #33568131
> 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 res…
-
comment
Comment #33566559
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 incre…
-
comment
Comment #33565556
> 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://githu…
-
comment
Comment #33565343
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 …
-
comment
Comment #31279324
> 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... …
-
comment
Comment #31276362
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 …
-
comment
Comment #31276291
> 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 …
-
comment
Comment #31276076
> 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 …
-
comment
Comment #31060602
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 c…
-
comment
Comment #30222215
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.
-
comment
Comment #30019762
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 …
-
comment
Comment #30017147
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:…
-
comment
Comment #30014072
> 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 co…
-
comment
Comment #30005606
> 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 be…
-
comment
Comment #30001821
> 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 interf…
-
comment
Comment #30001303
> 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 onl…
-
comment
Comment #30000629
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 :)