Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 2.0 thoughts

forum.nim-lang.org

Post reply on HN
Print view View original

121–130 of 150 posts

Re: Nim 2.0 thoughts

#121

Post by mrweasel »

planetis wrote: post #116
mrweasel wrote: post #112

Earlier quoted context omitted.

I think I tried most of those templating options, but some seems to have been abandoned, many try to abstract the html away and most are incomplete. Nwt seemed like the most promising, but it don’t even allow loops in your template.

I really don't understand what your requirements are. Again karax is well known and better alternative than all these (i.e loops and other control flow work as expected).

Understandably, I don't think I explained it all that well.

If I look at the Karax example, it seems more like a way of building the HTML in Nim, but I want to write HTML. If you look at Jinja2, then it's HTML, but with a bit of embedded syntax to do loops, conditionals and string replacement, plus a few handy functions.

The built in templates in Go is a bit simplistic, but it's enough for my needs. So something like it would be nice.

As you pointed out the Karax it has type safety, which my suggestions doesn't have. It's also not required, because HTML/text templates doesn't need type safety, it's all just text.

Basically I want nwt, with loops and control statements implemented.

Re: Nim 2.0 thoughts

#122

Post by planetis »

mrweasel wrote: post #121
planetis wrote: post #116

Earlier quoted context omitted.

I really don't understand what your requirements are. Again karax is well known and better alternative than all these (i.e loops and other control flow work as expected).

Understandably, I don't think I explained it all that well. If I look at the Karax example, it seems more like a way of building the HTML in Nim, but I want to write HTML. If you look at Jinja2, then it's HTML, but with a bit of embedded syntax to do loops, conditionals and string replacement, plus a few handy functions. The built in templates in Go is a bit simplistic, but it's enough for my needs. So something like…

This might do it https://nim-lang.github.io/Nim/filters.html

Re: Nim 2.0 thoughts

#123

Post by nimmer »

m_mueller wrote: post #108
davidkunz wrote: post #38

Earlier quoted context omitted.

I think one reason is that there's no big corporation behind it, for Rust it was Mozilla and now the members of the Rust Foundation, for Go it is Google. But I totally agree, Nim is an awesome language and definitely deserves more attention!

Didn't python start this way 25ish years ago? It then has slowly and steadily gained developers. Nim might also be there in another 15 years.

At the time no companies were heavily marketing FOSS projects. Also, today large companies have a fanbase.

Re: Nim 2.0 thoughts

#124

Post by nimmer »

iamcreasy wrote: post #100
nimmer wrote: post #63

Earlier quoted context omitted.

Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.

Is transpiled C readable?

It is. It's just not very pleasant to read due to the autogenerated variable names.

Re: Nim 2.0 thoughts

#125

Post by nimmer »

isubasinghe wrote: post #97
nimmer wrote: post #63

Earlier quoted context omitted.

Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.

I get that Nim can be faster than Go but I don't see how it can be faster than Rust, could you please elaborate as to why?

I was referring to compilation time... given the question.

Re: Nim 2.0 thoughts

#126

Post by nimmer »

lenkite wrote: post #103
0-_-0 wrote: post #61

Earlier quoted context omitted.

Actually, in Nim "functionName", "function_name" and "functionname" are equivalent and interchangeable

So one needs to grep 3 times instead of once in a code-base. Why did the authors chose this abominable convention ? It makes maintenance a nightmare.

I never had this issue: do not mix different stiles across the same project.

Instead, you can import and use libraries that use a different stile without breaking your convention.

Re: Nim 2.0 thoughts

#127

Post by nerdponx »

memco wrote: post #53
xigoi wrote: post #20

Earlier quoted context omitted.

The equivalent in Python would be: T = TypeVar("T") def odd_numbers(a: list[T]) -> Iterator[T]: # implementation I don't really find that less verbose, in terms of brackets and symbols…

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python: T = TypeVar("T") def odd_numbers(a: Iterable[T]) -> Iterator[T]: yield from (n for n in a if n % 2 == 1)

I think the "full" version is easier to read:

    T = TypeVar("T")
    def odd_numbers(nums: Iterable[T]) -> Iterator[T]:
        for n in nums:
            if n % 2 == 1:
                yield n
Although yet another option is to just return the generator instead of immediately yielding from it:

    T = TypeVar("T")
    def odd_numbers(nums: Iterable[T]) -> Iterator[T]:
        return (n for n in a if n % 2 == 1)

Re: Nim 2.0 thoughts

#128

Post by nerdponx »

planetis wrote: post #119
memco wrote: post #53

Earlier quoted context omitted.

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python: T = TypeVar("T") def odd_numbers(a: Iterable[T]) -> Iterator[T]: yield from (n for n in a if n % 2 == 1)

That's an obscure/not optimal way to write this code though. I mean why would you use LIST comprehension if you are going to yield each element.

It's not list comprehension, it's generator comprehension, which is lazily computed. However it's still an unnecessary layer of iteration, when you could just return the comprehension instead.

Re: Nim 2.0 thoughts

#129

Post by krupan »

BracketMaster wrote: post #84
Siira wrote: post #80

Earlier quoted context omitted.

Isn’t the bottleneck there the core software being proprietary? I think even verilog (which is quite old) doesn’t have a mature FOSS compiler+IDE. There are also probably not that many hardware designers in the world?

Yosys is a very capable FOSS synthesizer and Verilator is a FOSS simulator actually used in production at ARM.

Yosys and Verilator are pretty capable if you are ok with their limitations. There is nothing akin to gcc or clang in the verilog world.

Re: Nim 2.0 thoughts

#130

Post by kaushalmodi »

BracketMaster wrote: post #22

One thing people don't often bring up is how great nim is for writing DSLs. DSLs really matter in the hardware and digital design space - a space that seems to be completely devoid of innovation when it comes to tooling. A couple languages that try to bring RTL into the 21st century are nMigen-Python and Chisel-Scala. I'm currently writing an RTL in Nim. Nim's macro system allows you to do really cool things like ins…

It's great to see reference to hardware design in this thread.

Not hardware, but I have been using Nim for DPI-C interface with SystemVerilog for quite some time. Few weeks back, I started tinkering with Nim macros, and started working on a project to make the VPI interface more approachable.

This language is kind of a hidden gem that not many people are aware of in the HDL/HVL space.

Post reply on HN