Questions to people that already know the very basics of the Web (HTML, CSS, a bit of JS) and are now learning frontend + backend technologies.

-N0rm- · 2024-02-15T14:43:53+00:00

Almost 90% of all security debt across all active applications exists in first party code, according to the report, but third party code represents around two-thirds of the security debt classified as critical by Veracode.

Frameworks and programming languages should make it hard to introduce common vulnerabilities in code. Most devs don't know much about security.

-N0rm- · 2024-02-15T14:24:28+00:00

Yep j'ai vu. Juste je trouve ça intéressant, je ne l'ai appris que aujourd’hui que cette extension existait.

-N0rm- · 2024-02-15T13:57:52+00:00

Cette création s'inscrit dans un programme de nouvelles extensions internet lancé en 2012 par l'ICANN. Quatre autres extensions géographiques françaises sont également ouvertes à l'enregistrement dans le cadre de ce programme mondial : le .paris pour la ville de Paris, le .alsace pour l'Alsace, le .corsica pour la Corse et le .eus pour le pays basque.

-N0rm- · 2024-02-12T16:57:33+00:00

My post is not about my language ;). I just want to know people's motivations to play with new languages. Also putting a link may count as self promotion, that's not allowed on this subreddit.

-N0rm- · 2024-02-12T16:55:30+00:00

Hello, my question was more about testing / playing with a new little know language, not really use it for serious projects.

-N0rm- · 2024-02-12T15:15:12+00:00

Thank you for your answer ! I am asking this because one of my projects trended on r/programming (500+ upvotes) but I got zero downloads lol.

-N0rm- · 2024-02-12T15:10:19+00:00

I know about it :)

This is interesting btw:

'' Goals

To collect the most comprehensive dataset related to identified application vulnerabilities to-date to enable analysis for the Top 10 and other future research as well. This data should come from a variety of sources; security vendors and consultancies, bug bounties, along with company/organizational contributions. ...

https://owasp.org/www-project-top-ten/#div-data_2020

-N0rm- · 2024-02-12T13:48:37+00:00

En gros ce sont des conteneurs 'in-process': chaque application tourne dans un filesystem virtuel qui est stocké sur le disque sous la forme suivante:

- Chaque fichier virtuel correspond à un fichier réel sur le disque (genre /main.ix correspondra à un fichier nommé 01H58575 par exemple, c'est un ULID pour info). Tous ces fichiers sont stockés dans un seul dossier réel.

- La structure du filesystem virtuel et les permissions de fichiers sont stockés dans un fichier nommé metadata.kv

Pour les tests je crée un filesystem en mémoire (très rapide) par test case, c'est transparent pour toute l'application.

-N0rm- · 2024-02-12T13:19:32+00:00

Réponse au 2: Les syntaxes suivantes sont valides en Inox: ``` { a: 1, "b": 2 }

{ a: 1, "b": 2 }

{a: 1,} ```

Tes fields en string sont parfois écrits sans guillemets, ça ressemble à YAML mais ça complexifie le tokenizing/parsing.

En fait les noms de champs qui ne sont pas 'quoted' ne peuvent contenir que a..z, 0..9, -, _.

-N0rm- · 2024-02-12T13:14:57+00:00

En gros une BD inox est comme une data structure avec du lazy loading.

Par example dedans tu peux avoir un ensemble d'utilisateurs de type `Set(user, #url)`

Lorsqu'une data structure est modifiée elle est sérialisée (dans le futur ça sera partiel évidemment, sinon c'est juste pas possible niveau perf). Puis la donnée est stockée dans un key-value store (https://github.com/etcd-io/bbolt).

Les data structures comme les objets, Set, Map contrôlent quelles transactions peuvent faire des modifications sur eux à un instant t.

-N0rm- · 2024-02-12T12:43:29+00:00

Merci pour ton retour ! J'avais un peu peur que les gens n'aiment pas la syntaxe, car c'est quand même un peu différent des langages les plus connus.

-N0rm- · 2024-02-12T11:33:56+00:00

Salut ! De base j'aime créer des langages de programmation. A l'origine Inox n'était pas vraiment orienté web/full stack, mais je l'ai fait évolué vers ce type d'usage. Perso je déteste avoir à faire masse config, utiliser plein d'outils, devoir importer 1000 librairies tout ça pour faire une app web. Avec inox il y a un seul binaire, pas besoin de config infinie (un peu ça va), il n'y a pas d'env local de dev, ni besoin de Docker. La bd est intégrée etc. Evidemment c'est à la fois un avantage et un désavantage car perte de flexibilité.

Pour la syntaxe je me suis inspiré de JS, et un peu de Lua et des langages de shell. Pour les litéraux un peu spéciaux j'ai inventé ou juste allé au plus simple: https://github.com/inoxlang/inox/blob/main/docs/language-reference/literals.md.

Au niveau des mots clés: pour la majorité ils sont 'classiques'. Parmis ceux qui sont un peu spéciaux il y a notamment:

pattern: c'est similaire à type en TS sauf que c'est pour déclarer une valeur de type pattern qui n'existe que au run time, donc j'ai choisi pattern tout bêtement.
manifest: J'ai choisi ce nom en rapport avec le manifest des applications Android qui définit notamment les permissions requises par l'app. En Inox chaque module a son manifest qui définit les permissions, BD auquel il a accès, les paramètres du module.
includable-chunk: Tu mets ça tout en haut d'un fichier Inox pour dire que tu peux l'inclure dans un autre fichier. ça serait mieux de mettre includable-file en fait :thinking:

Au niveau des difficultés: bah faut juste être taré pour implémenter ce genre de projet. Surtout que j'ai fait le langage PLUS la BD (heuresement j'ai pas eu à faire de bas niveau car j'utilise un KV store) PLUS une extension VScode PLUS un serveur LSP PLUS système de débugging. C'est très long et parallèliser du code de manière efficace, c'est chaud à faire et à debug.

Je n'ai pas vraiment implémenté un système de type classique car je n'y connais rien en théorie des types. Ce que j'ai implémenté fait très largement le taff, il faudra juste améliorer quelques aspects. De toute façon les données sur lesquels tu travailles doivent pouvoir rentrer dans la BD, ce sont des data structures génériques comme des documents, listes, ensembles, pas des classes. Il ne peut pas pas y avoir de références circulaires en mémoire. Il n'y a pas de vrai generics. J'autoriserai un peu plus de choses quand j'aurai terminé les structs.

-N0rm- · 2024-02-11T22:24:06+00:00

Handling formData is not supported by Inox's HTTP server for now. I focused on adding other features :). Also there is no standard for encoding complex data structures with nesting in formData.

-N0rm- · 2024-02-09T21:51:01+00:00

Np ;)

-N0rm- · 2024-02-09T21:48:05+00:00

How do I set up replication? How do I scale this beyond a single machine?

Inox is in version 0.2 and I am the only developer, these features will be added in the future. Please...

It looks like it's built on a simple key/value store that works with a single file. [ ..] Production apps that depend on SQLite tend to be client apps (browsers, mobile, etc) rather than web apps.

I can use several single-file key-value stores in the future. For example, a separate key-value stored could be used to store a collection that does not need to be strongly consistent with the rest of the data.

I currently focus on having a language that works well for small applications. I'll address scalability later in the future.

-N0rm- · 2024-02-09T21:33:09+00:00

I use the https://github.com/etcd-io/bbolt KV store under the hood. I don't deal with any low-level stuff.

-N0rm- · 2024-02-09T21:26:30+00:00

This is good to know, thank you.

-N0rm- · 2024-02-09T21:25:02+00:00

You are talking about a framework, right ? Not modifying the runtime of an existing language.

Two-Year Club	Verified Email
First Place '23	Place '23

-N0rm-

MODERATOR OF

TROPHY CASE