Re: Advent of Code 2018 megathread
I know atleast three people who rage quit advent of code this year because of day 15. Day 16 was a lot of fun and I'm currently finding time to work on day 17 but I still have nightmares about goblins and elves :(
Re: Future of Nim ?
Talking about killer app or general pattern, I think this recent article is interesting: [https://chameth.com/2018/12/09/over-the-top-optimisations-in-nim](https://chameth.com/2018/12/09/over-the-top-optimisations-in-nim)/ * Prototype quickly in a clean high level language - already faster than most interpreted languages * Optimize and get even faster but needs deeper understanding * Bypass gc and get even more efficient * Optimize to the nth degree like you would with C All this without having to switch to another language. This is the typical use case of any app that succeeds and needs to scale and you can do it all in Nim. And we haven't gotten into macros yet.
Re: Future of Nim ?
> Do you think that Nim will have a future ? Definitely. It is open source and liked by thousands of programmers (most of whom are waiting for it to stabilize and mature). No matter what happens, there will be some people interested in developing Nim. As I recently posted, [Nim's package ecosystem count](https://www.reddit.com/r/nim/comments/9rf1ob/happy_800_modules_nimbles_ytd_growth_beats_d_c/) shows faster yearly percentage growth than almost all other languages. If things go well, Nim will continue to grow - like Python took over 25 years to gradually grow from obscurity to dominance. If things go badly, this growth will fall below other languages so Nim will never leapfrog them, but it will definitely have a future. > How to make this beautiful language more recognized so that they take more > importance ? Nim needs a "[killer app](https://en.wikipedia.org/wiki/Killer_application)". This doesn't necessarily mean a specific app, like Rails was for Ruby - it can be a general pattern, some clear specific thing that Nim does better than its competitors. My position is that Nim should embrace the niche of being [the most libertarian programming language](https://voat.co/v/programming/2853775): no [restrictive licenses](http://copyfree.org) / patents, no mega-corp sugar-daddies, no "dumb it down to reduce programmer replacement costs", no CoCs, highest portability, etc. But I remain alone in advocating this... So hopefully someone else will come up with a better unique advocacy argument for Nim...
Re: constness of refs & ptrs
It's not about Nim and Rust but about expectation for keywords like let and var which are used in plenty of other languages (C#, Ocaml, Javascript, Swift, Julia, ...)
Re: constness of refs & ptrs
This is the common sense in design I've come to expect. This may come off as blunt, but if someone wants nim to be rust, they should just go use rust. Use what works for you.
Re: Unexpected behaviour
This works
type
SNodeAny = ref object of RootObj
SNode[T] = ref object of SNodeAny
DNode[T] = ref object
method newDNode(s: SNodeAny) {.base.} =
echo "newDNode base"
method newDNode[T](s: SNode[T]) =
echo "newDNode generic"
method getStr(s: SNode[float]): string {.base.} = "blahblah"
let s = SNodeAny(SNode[float]())
newDnode(s)
Run
why? The instantiation `SNode[float]` is cached and by that time there are no
methods attached to `SNode` yet. Then the cache is consulted and the
instantation of `method newDNode[T](s: SNode[T])` is skipped. Multi methods and
generics are broken beyond repair IMO.
Re: Unexpected behaviour
Thanks for explaining. I'll leave this thread and continue discussion in the github issue.
Re: Unexpected behaviour
@zevv please report this issue on github.
Re: Unexpected behaviour
https://github.com/nim-lang/Nim/issues/10038
Re: constness of refs & ptrs
> ...may I push this idea again ? :) You may and I'm hearing you but in the longer run `ref` usage should be discouraged and then the problem disappears too. And solving problems by avoiding some language features is much more elegant than yet-another-feature IMHO. Pointers are like `goto`, too powerful and need to be tamed and hidden within "structured data types" much like goto was tamed with "structured programming constructs" (if, while etc). What are "structured data types"? Essentially everything that is tree-like.
Re: Unexpected behaviour
> let s = SNodeAny(SNode[float]()) > > newDNode(s) s is SNodeAny, is it given? ;/ @mratsim's post should be helpful in this case [https://forum.nim-lang.org/t/4415#27607](https://forum.nim-lang.org/t/4415#27607) I think it's because generic is compile-time while what you wanted is in runtime. Since you have defined another method for SNode[float] , it becomes concrete-type, cmiiw Indeed, changing the cast to `let s = SNodeAny(SNode[int]())` yield what you wanted.
Re: constness of refs & ptrs
1 year later, I'm still worried about that missed opportunity of stronger immutability guarantees in Nim. The whole distinction between var and let feels useless without this. When looking at a proc signature, I have no way to know if its parameters will be modified, unless they are value-types and let parameters. I like the new "func" keyword, but we could make it even closer to what a pure-function should be by implementing this, and forbidding var params for funcs. I'm not aware of the implementation issues, but Araq said it should be possible thanks to his write-tracking pass. It also feels like something that should be introduced before 1.0, since it will break things, so... ...may I push this idea again ? :)
Unexpected behaviour
I've been hunting strange behaviour in my code base which I have reduced to the
following snippet.
type
SNodeAny = ref object of RootObj
SNode[T] = ref object of SNodeAny
DNode[T] = ref object
method getStr(s: SNode[float]): string {.base.} = "blahblah"
method newDNode(s: SNodeAny) {.base.} =
echo "newDNode base"
method newDNode[T](s: SNode[T]) =
echo "newDNode generic"
let s = SNodeAny(SNode[float]())
newDnode(s)
Run
What I expect to happen: variable `s` is a `SNode[float]` disguised as a
`SNodeAny`. Calling `newDnode(s)` should dispatch the `newDnode[T](s:
SNode[T])` and the string `newDNode generic` should be printed.
Instead what happens is that the "super" method `newDnode(s: SNodeAny)` gets
called, printing the string `newDnode base`
Now the strangest part: when the `getStr()` method is removed from the code,
the behaviour changes to the expected behaviour, and all is well.
Alternatively, removing the `SNodeAny()` cast from the second last line also
restores the expected behaviour.
How does the existence of the `getStr()` method affect the behaviour of the
`newDNode()` dispatch?
Re: Nim video lists
I am sure theres more on Twitch.
Re: How to parse JSON at compile time?
This would be nice as a Nimble module.
Re: How to parse JSON at compile time?
Thanks! Indeed, that's tricky a lot
Re: Future of Nim ?
I'd really like to ask this question: what does popularity have to do with success and future? Nim has been around for 13 years and is actively developed. It is useful and productive and the community is helpful. Stability releases are being actively worked (v0.19.2) and point releases have been available for a long time. Reminds me of this article I read yesterday. [https://m.signalvnoise.com/reconsider-41adf356857f](https://m.signalvnoise.com/reconsider-41adf356857f)
Re: Future of Nim ?
As long the language and the idea is persisting, it will eventually become (almost) everyone favorite. Look Python for example, or Smalltalk and/or Lisp-families that always be "smart guys" secret weapon.
Re: Nim video lists
Nice lists! Maybe there could be a videos section on the Nim website with links to videos? Could be a page linked from here: [https://nim-lang.org/documentation.html](https://nim-lang.org/documentation.html)
Get proc arg type with templates
Is it possible without using custom macros, to get the type of a proc argument? proc inc(a: int): int = a + 1 template typeArg(p): type = ??? # typeArg(inc) = int Run
Re: Future of Nim ?
Hello Ar, I like the pseudo lol Indeed, I am slow to stability and see later but I really cross the fingers for this language is successful.
Re: Future of Nim ?
It needs a bit of luck. It cannot compete against the great ones, do not ever expect nim to become as popular as C#, javascript or python. But once some important project using nim is announced, nim will receive more visibility. This is right now hard as it is not common for important projects to be developed under the umbrella of a programming language that hasn't reached stability yet.
SslError: ssl3_write_pending:bad write retry
Hello, In an app I am writing I am getting the following error. This is occurring inside code which when encountering an exception will sleep(100) and retry. After 10 retries (1 second) it will close the client and create a newHttpClient. Rather than catching this exception the app just stops, goes silent for 10+ minutes and then quits with the below. I am not sure how to handle this. Any help greatly appreciated. Current Exception: SslError Current Exception Msg: error:1409F07F:SSL routines:ssl3_write_pending:bad write retry Current Exception: SslError Current Exception Msg: error:1409F07F:SSL routines:ssl3_write_pending:bad write retry Current Exception: SslError Current Exception Msg: error:1409F07F:SSL routines:ssl3_write_pending:bad write retry ... Traceback (most recent call last) mycode... httpclient.nim(1235) get httpclient.nim(1227) request httpclient.nim(1204) request httpclient.nim(1183) requestAux net.nim(1379)send net.nim(1367)send SIGPIPE: Pipe closed. Run
Future of Nim ?
Hello the Nims ^^ A friend told me about the language to which he also bought the book and convinced me of the language, however I remain skeptical on certain points. 1. Do you think that Nim will have a future ? 2. How to make this beautiful language more recognized so that they take more importance ? For my part I think that a known company should use it so that the language is stable over time.
My code has too many casts to overcome "int" type
Hi, I came accross a real problem that always forces me to cast my values. I coded my raw socket library with epoll, using available nim libraries (pure and posix). Coding in assembly as well, I tend to use uint32 for performance reasons (uint16_t and uint64_t tend to be slower than uint32_t on x86_64 either because of memory pressure or longer instruction) My issue is that I am struggling against the system when it defines the basic "int" type. I always end up casting again and again, there and there. I don't want a 8byte integer where a 4 bytes is faster and does the job. I had to rewrite almost all the declarations slowly changing a large part of the original code base. Don't get me wrong, nim is superb when working inside nim. But once you go low level and interact with c low level code, you are going against the wind, or have to rewrite large parts of code. Just a note. Thanks
Re: How to parse JSON at compile time?
Hi!
It's a little bit tricky :)
macro parseSwagger*(iApi: untyped, fn: string): untyped {.gensym.} =
var
inputJsonStr = slurp($fn).multiReplace([($'\n', ""), ($'\r', ""),
($'\c', ""), ($'\t', "")])
parseJsnMcr = ident(nskMacro.genSym("parseJsn").repr)
parseJsn = parseStmt("macro " & $parseJsnMcr & "(iApi: untyped):
untyped {.gensym.} =\n var jsnData = %*(%tmp%)".replace("%tmp%", inputJsonStr))
result = quote do:
`parseJsn`
`parseJsnMcr`(`iApi`)
Run
Re: nim-result - Result-Either style return values lib
It would be nice to have either in the standard library, and also to make more use of options instead of returning -1 or exceptions, even sometimes using [cheap replacements](https://nim-lang.org/docs/channels.html#tryRecv%2CChannel%5BTMsg%5D).
