[libre-riscv-dev] nmigen frustrations make me want Rust

[Luke Kenneth Casson Leighton]

On Sunday, March 17, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Sun, Mar 17, 2019, 02:46 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > So let's see how to adapt, and keep it open. I appreciate you weren't
> aware
> > of these things when we made the decisions
> >
> > Still, do bear in mind that in 42 years of programming I have never, not
> > once, used autocompletion, and have never felt the need to do so.
> Perhaps
> > it is a case of not feeling frustration because at a lack I have never
> > experienced.
> >
> I recognise that autocompletion is not very high up in your personal list
> of criteria of what's important in a programming language; I do have other
> reasons that I think nmigen's current design is not the best, but it's
> mostly a whole lot of individually insignificant things that pile up and I
> can't remember most of them at the moment.
>
>
If you can keep a list when you can, perhaps some of them can be solves.


> I highly recommend trying out a autocompletion plugin for vim, such as
> youcompleteme. It works for python, rust, c/c++, and many other languages.
> It can suggest completions from the standard libraries, from
> import/use/#include statements, class members and many other things. They
> usually work better on statically typed languages since it's easier to know
> the types then. You could think of it like tab-based completion on the bash
> command line but much more powerful.
>
> I started programming using Quick Basic and Turbo C++ on DOS so I have a
> lot of experience using ides that were just slightly more advanced than
> nodepad (which is slightly better than cat as an editor -- aka don't use it
> if you have any slightly viable alternatives (though I hear it's been
> getting better -- LF-only line endings support was recently added)) with a
> built-in command to compile code.
>
>
:)


> >
> > I know for sure though that when I am prevented from using a bash
> > commandline and am forced to use a GUI for eg file management it is hell.
> > So I do grok the frustration thing.
> >
> I use the command line most of the time for file management as well.
>
> >
> > There is an IDE out there I have heard which can walk a python codebase,
> > and as long as it is asingle inheritance class structure it can provide
> > autocompletion.
> >
> Currently it's at least any ide that supports the Language Server Protocol.
> Python has a language server that can do much better than that: pyls.
>
> >
> > So it is not a dead loss.
> >
> I'll be just fine with nmigen, just will need a bit more time to get used
> to it.
>
> I have kinda wanted to write a decent (records + generics/templates +
> turing complete compile/generate-time code generation + static typing) HDL
> for a while anyway. I had started writing one from scratch last year (
> https://github.com/programmerjake/cpp-hdl), but got bogged down in writing
> compile-time code generation and a template system like C++'s. If I have
> the HDL be an embedded language in rust (like nmigen in python), rustc
> would take care of the hard parts for me.
>
> I'm planning on eventually writing the Rust HDL, but not as part of our
> project (though would be happy to work on it as part of our project).
>
>
I worked with the Shakti Group (hello rishabh) last year, and we used BSV
which is Haskell.

It has a formal mathematical guarantee, through strong typing, that if it
compiles it WILL synthesise. It also contains a language compiler to c++
which gets a 20x performance boost on simulation.

The number of complaints however at the strong typing, and the hoops that
had to be gone through, and how many times we had to check the Reference
Manual, were extremely high.

Despite that , yes, strong typing would be an extremely good idea. Just...
it would add about 3 man years to the project as it stands.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68