Originally posted by programmerjake
View Post
Announcement
Collapse
No announcement yet.
Libre-SOC Test ASIC Going To Fabrication, Using TSMC 180nm Process
Collapse
X
-
Originally posted by programmerjake View Post
Though imho we're over-using inheritance since python doesn't really have other good abstraction tools such as Rust's traits.
Source code: Lib/abc.py This module provides the infrastructure for defining abstract base classes(ABCs) in Python, as outlined in PEP 3119; see the PEP for why this was added to Python. (See also ...
lkcl, you *really* should learn Rust.- the linux kernel is in c. we need to develop linux kernel drivers.
- u-boot is in c. we need to port u-boot to Libre-SOC.
- unit tests are written in pure assembler.
- binutils, which we need, is written in c
- both gcc and llvm are both written in c++.
- ffmpeg is written in c++
- gem5 is in mixed c++ and python
- cavatools is in mixed c with python-based generator/compiler scripts
each of those dependencies above are multi-DECADE projects and above. any time spent replacing any of those by rewriting them in rust, unnecessarily, become themselves massive multi-DECADE projects, representing a massive distraction and diversion away from the goal that's been set (and funded by NLnet). look at how long GNU/Hurd, one of my favourite alternative kernels, took: they simply couldn't keep up.
therefore, given the time pressure and the responsibility that we have to honour our obligations to NLnet, any time that i spend learning rust is actually a pretty irresponsible use of my time.
bottom line is, we have to be really tough and realistic, and leverage what's *avalable*, rather than do what we *like* to do because it's a personal preferred interest.
- Likes 1
Comment
-
Originally posted by programmerjake View Post
That Rust HDL could have all the parts that made BlueSpec so great -- guaranteed synthesizability, strong typing, good type checking, expressive types, etc. Too bad BlueSpec was not an option due to its proprietary nature.
it actually got embarrassing: the person i was working with had so many other people needing his time that i had to sometimes waste an entire day not doing anything at all, because his time spent searching through the documentation for a way round the problem that strong typing created was distracting him from being able to help the rest of the team.
whilst you might think initially that strong types are "great", and they "save" you from making "mistakes", in reality they're just a damn nuisance.
consequently, i would expect any rust-based HDL, rather than being useful and productive, to similarly so intensely annoy its users that they give up on it. not only that, but remember we went through this, spending several weeks evaluating existing HDLs. with no pre-existing community, and no base libraries, we'd literally be creating everything from scratch (and then have to maintain it ourselves). that represents - again - an irresponsible use of time, and would place the project in an extremely risky position of having to train developers first in rust, then in rust HDL, and finally in the Libre-SOC HDL.
Comment
-
Originally posted by lkcl View Postit does: you use ABC decorators, inheriting from metaclass ABCMeta, and mark the function that needs to be "traited" with @abstractmethod. any class that then inherits from the base then is *required* to override (have) that method.
Code:trait MyTrait<T, U> { type Output; fn my_method(self, t: T, u: U) -> Self::Output; } // impl #1 -- abstracting over built-in and standard library types -- not our types impl MyTrait<i32, f64> for String { type Output = Vec<bool>; fn my_method(self, t: i32, u: f64) -> Vec<bool> { todo!("my_method for String, i32, and f64") } } // impl #2 abstracting over all types U that implement addition impl<U> MyTrait<bool, U> for U where U: Add<Output = U> { type Output = String; fn my_method(self, t: bool, u: U) -> String { let v = self + u; // we can add, v's type is U due to the Output = U todo!("my_method for U, bool, and U, for any type U") } } fn f() -> Vec<bool> { let s = 1.0_f32.my_method(false, 3.5); // call impl #2 with U = f32 // s is a String s.my_method(1, 4.5 + 5.5) // call impl #1 }
Originally posted by lkcl View Postwhat is the justification? i am not going to learn a language that has no use-case and no purpose, particularly one whose underlying syntax is unreadable as plain english.
Originally posted by lkcl View Post- the linux kernel is in c. we need to develop linux kernel drivers.
- u-boot is in c. we need to port u-boot to Libre-SOC.
- unit tests are written in pure assembler.
- binutils, which we need, is written in c
- both gcc and llvm are both written in c++.
- ffmpeg is written in c++
- gem5 is in mixed c++ and python
- cavatools is in mixed c with python-based generator/compiler scripts
Originally posted by lkcl View Posteach of those dependencies above are multi-DECADE projects and above. any time spent replacing any of those by rewriting them in rust, unnecessarily, become themselves massive multi-DECADE projects, representing a massive distraction and diversion away from the goal that's been set (and funded by NLnet). look at how long GNU/Hurd, one of my favourite alternative kernels, took: they simply couldn't keep up.
Originally posted by lkcl View Posttherefore, given the time pressure and the responsibility that we have to honour our obligations to NLnet, any time that i spend learning rust is actually a pretty irresponsible use of my time.
bottom line is, we have to be really tough and realistic, and leverage what's *avalable*, rather than do what we *like* to do because it's a personal preferred interest.
Comment
-
Originally posted by lkcl View Postwhat is the justification? i am not going to learn a language that has no use-case and no purpose, particularly one whose underlying syntax is unreadable as plain english.
Amazon thinks Rust is awesome:
One of the most exciting things about the Rust programming language is that it makes infrastructure incredibly boring. That’s not a bad thing, in this case. No one wants their electrical wiring to be exciting; most of us prefer the safety that comes with being able to flip a switch and have light to see […]
According to Stackoverflow's yearly surveys, Rust programmers love Rust and want to keep using it, it's topped the most loved languages ranking for 5 years (!) in a row:
All the Rust programmers that I'm aware of in Libre-SOC (Cole and me) think Rust is very useful.
All of those collectively very smart people think Rust is far from useless.
- Likes 1
Comment
-
Originally posted by programmerjake View PostAll of those collectively very smart people think Rust is far from useless.
- Likes 3
Comment
Comment