Rustlang vs Vlang #30

Closed
opened 2020-01-27 01:11:23 +01:00 by Kreyren · 5 comments
Kreyren commented 2020-01-27 01:11:23 +01:00 (Migrated from github.com)

Research for programming language selection

Declaration

Superior lang == Programming language that can manage available system resources in relation to time better then the alternative without sacrificing the security with methods to make development easier being preffered.

Variables

Verona

Verona (https://github.com/microsoft/verona) might influence the development of both languages

RUSTLANG

+ Cargo
+ Crates
+ free book with references which allows contribution
+ Rustbridge - program that is focused on teaching new devs
+ Potential to be the most efficient language

VLANG

? More efficient then rustlang?
- libraries are not as evolved as rustlang crates (2701200147)
+ Contributable free documentation for usage of the lang
- Still in development (2701200147)
- Runtime is comparable to C lang or slower/same (?)
- Doesn't have sufficient profiling (?)
- Leaks memory(?)

Research for programming language selection ## Declaration Superior lang == Programming language that can manage available system resources in relation to time better then the alternative without sacrificing the security with methods to make development easier being preffered. ## Variables ### Verona Verona (https://github.com/microsoft/verona) might influence the development of both languages ## RUSTLANG **+** Cargo **+** Crates **+** free book with references which allows contribution **+** Rustbridge - program that is focused on teaching new devs **+** Potential to be the most efficient language ## VLANG **?** More efficient then rustlang? **-** libraries are not as evolved as rustlang crates (2701200147) **+** Contributable free documentation for usage of the lang **-** Still in development (2701200147) **-** Runtime is comparable to C lang or slower/same (?) **-** Doesn't have sufficient profiling (?) **-** Leaks memory(?)
Kreyren commented 2020-02-03 05:19:57 +01:00 (Migrated from github.com)

Current decision

Vlang is still in development and may be unreliable to rely on compared to rustlang, but project has been adapted to allow multi-language where the language performance will be monitored through project alike https://github.com/Kreyren/benchmarks based on which the code will be adapted and project will have an option to choose alternative code base.

## Current decision Vlang is still in development and may be unreliable to rely on compared to rustlang, but project has been adapted to allow multi-language where the language performance will be monitored through project alike https://github.com/Kreyren/benchmarks based on which the code will be adapted and project will have an option to choose alternative code base.
JesterOrNot commented 2020-02-03 05:21:32 +01:00 (Migrated from github.com)

Why not go with a polyglot approach and use both?

Why not go with a polyglot approach and use both?
Kreyren commented 2020-02-03 06:58:55 +01:00 (Migrated from github.com)

.. and use both? @JesterOrNot

That's what i meant by alternative code base in case someone wants to use C lang, python, etc.. instead of rustlang on this project, but my main focus is currently on rustlang assuming that i can adapt the project for this workflow to be maintainable.

Currently i've separated the subcommands in file hierarchy that i'm experimenting with:
image

hoping that the code can be adapted with multiple files in different languages and managed through fixmes since this is going to be a rolling-release with option for version control.

For example files for crowd-sourcing translate can be in conf/toml/yaml syntax and adapt the code to read from it instead of using language-specific variable declaration.

And we can use language translators like C2Rust (https://c2rust.com/) as stub and option in configuration.


I'm open for discussion if you can provide any relevant info to this implementation as said currently experimenting with it to see what may be possible to do where i want to avoid separating these in invidual language-specific branches.

> .. and use both? @JesterOrNot That's what i meant by `alternative code base` in case someone wants to use C lang, python, etc.. instead of rustlang on this project, but my main focus is currently on rustlang assuming that i can adapt the project for this workflow to be maintainable. Currently i've separated the subcommands in file hierarchy that i'm experimenting with: ![image](https://user-images.githubusercontent.com/11302521/73628808-9091f000-4651-11ea-8538-430007ffae89.png) hoping that the code can be adapted with multiple files in different languages and managed through `fixmes` since this is going to be a rolling-release with option for version control. For example files for crowd-sourcing translate can be in conf/toml/yaml syntax and adapt the code to read from it instead of using language-specific variable declaration. And we can use language translators like C2Rust (https://c2rust.com/) as stub and option in configuration. --- I'm open for discussion if you can provide any relevant info to this implementation as said currently experimenting with it to see what may be possible to do where i want to avoid separating these in invidual language-specific branches.
Kreyren commented 2020-02-03 07:18:57 +01:00 (Migrated from github.com)

Also i'm not quite sure how to handle language specific functions.. to provide simplifies example arrays in bash compared to arrays in POSIX shell that are mostly variables with space separation and then string manipulated:

# Abstract: Get 'nothing' from an array of values 'something' and 'nothing' in this order

# dynamic linking in bash

## Arrays
example_array=(
    "something"
    "nothing"
)

printf '%s\n' "${example_array[2]}"

# Static linking in POSIX shell

## Arrays
example_array="something nothing"

[ "${example_array##something}" != "nothing" ] && exit 1

printf '%s\n' "${example_array##something}" 

Generally i write POSIX shell in bash for backwards compatibility which is sometimes limiting and uncomfortable to code.

Also i'm not quite sure how to handle language specific functions.. to provide simplifies example arrays in bash compared to arrays in POSIX shell that are mostly variables with space separation and then string manipulated: ```sh # Abstract: Get 'nothing' from an array of values 'something' and 'nothing' in this order # dynamic linking in bash ## Arrays example_array=( "something" "nothing" ) printf '%s\n' "${example_array[2]}" # Static linking in POSIX shell ## Arrays example_array="something nothing" [ "${example_array##something}" != "nothing" ] && exit 1 printf '%s\n' "${example_array##something}" ``` Generally i write POSIX shell in bash for backwards compatibility which is sometimes limiting and uncomfortable to code.
Kreyren commented 2020-03-18 09:36:04 +01:00 (Migrated from github.com)

It was decided to use rustlang as a primary language for now, but project has been adapted to support all programming languages, see https://github.com/RXT0112/Zernit/issues/70 for implementation and adapted file hierarchy of the project

It was decided to use rustlang as a primary language for now, but project has been adapted to support all programming languages, see https://github.com/RXT0112/Zernit/issues/70 for implementation and adapted file hierarchy of the project
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kreyren/Zernit#30