[HN Gopher] Show HN: Lady Deirdre 2 - Rust Framework for Compile...
___________________________________________________________________
Show HN: Lady Deirdre 2 - Rust Framework for Compilers and LSP
Servers
Greetings! I would like to share with you my project, Lady
Deirdre. Lady Deirdre is a framework that helps you create new
programming languages in Rust. It is specifically designed to
develop compilers and interpreters with support for code editor
extensions (LSP servers) from day one. The framework includes
essential components to design parsers and semantic analyzers
capable of incrementally reparsing dynamically evolving source
code. Lady Deirdre can be seen as a replacement for preexisting
projects with similar goals, such as Tree-Sitter, Rowan, or Salsa.
However, Lady Deirdre aims to offer a unified framework API that
guides you through the steps of programming language development,
providing even more components necessary to develop a full-featured
language ecosystem. For example, components to develop a source
code formatter. I will be happy to answer any questions. Ilya
Author : Eliah_Lakhin
Score : 83 points
Date : 2024-06-21 09:40 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| solarpunk wrote:
| I like the Alpha Centauri reference here lol.
| mdaniel wrote:
| The way the headline was written it seemed like this was the
| second _iteration_ of Lady and not just a 2.0 release
| announcement
|
| It would have also gone a long way if you had mentioned the
| licensing, which I am always interested in:
| https://github.com/Eliah-Lakhin/lady-deirdre#copyright
|
| As for a question: why the seemingly needless location of
| everything down in a "work" folder? Is there something else that
| you envision one day living at the top-level which you just
| planned for by putting everything someone would care about one
| further click away?
| Eliah_Lakhin wrote:
| You are right, this is indeed the second iteration of the
| project. Since the first iteration (released about a year ago),
| many things have changed and been reworked. The most notable
| change is the introduction of the semantic-analysis framework.
| Lady Deirdre 1 was merely an incremental parser library.
|
| > why the seemingly needless location of everything down in a
| "work" folder?
|
| It's just easier for me to organize the filesystem this way on
| my local machine. Everything that is unrelated to the
| development is outside of the work directory. Also, the license
| agreement refers to the "work". Perhaps it would be clearer for
| users if the work directory is clearly dedicated.
|
| > Is there something else that you envision one day living at
| the top-level which you just planned for by putting everything
| someone would care about one further click away?
|
| Everything that I planned to publish that is related to Lady
| Deirdre is already in the repository. I use this project for my
| other programming language project that I plan to release soon,
| but it will be in a separate GitHub repo. Actually, Lady
| Deirdre initially was separated from the language project
| codebase as I thought it may be useful for other programming
| language authors.
| armchairhacker wrote:
| First, I really like language frameworks like this. I think it
| could become very useful and popular.
|
| That being said, I really doubt anyone will buy a commercial
| license. People don't sell compilers and IDEs, and the ones who
| do are large corporations who make everything themselves. Look at
| state of language tooling today: nearly every compiler is open-
| source, every language server is free, every IDE is free except
| JetBrains (a well-known company with a large reputation) and
| Sublime Text (being heavily replaced by VS Code), and anything
| not open-source has an active open-source alternative. Nobody's
| going to buy a license from you to sell their compiler, because
| nobody's planning to sell their compiler.
|
| For this reason I'd recommend changing the license. I don't think
| it's overly-restrictive or dishonest, I think it's fair to expect
| being paid if someone makes >$200,000 off your work. But
| nonetheless it hurts adoption, a lot of people will see
| "proprietary" and not even read the license text. You're more
| likely to make money distributing it as MIT / Apache, letting it
| get popular, and setting up donations/sponsorships to fund
| development. But honestly, if you're looking to make money this
| isn't the space to do so: you could be hired by someone to work
| on PL, or you could sell something like a game, but you're not
| going to sell your own PL.
| Eliah_Lakhin wrote:
| Thank you for your feedback!
|
| I agree with your point about the licensing. I would also add
| that tools for the development of compiler front-ends are quite
| a niche market. So, honestly speaking, I don't plan to earn
| much from my project regardless of the license terms. This work
| is part of a higher-level in-progress toolset, which is closer
| to the end users. I have dedicated it as a separate project
| primarily for public preview, with some restrictions on
| distribution and use, as I haven't decided on the overall
| toolset distribution model yet. But it is possible that I will
| change the licensing terms of Lady Deirdre in the future to
| something less restrictive (maybe even MIT) to make it more
| popular, this is just not my current goal. I apologize for any
| inconvenience my current licensing terms may cause.
| Onavo wrote:
| You could however offer a cloud based static analysis API for
| security companies, which could be a viable source of revenue
| to fund the development.
| zackbrown wrote:
| > I apologize for any inconvenience my current licensing
| terms may cause.
|
| Friendly advice from a stranger, worth what it costs: I
| believe the greatest inconvenience of a commercial license
| will be to _you_, as opposed to end-users.
|
| The market is so saturated with open source, developers
| expect it, and commercial licenses cause huge usage friction
| and doubt.
|
| The "dual license" died as a viable business model around the
| time Meta (nee Facebook) and Microsoft starting investing
| billions into free-as-in-beer OSS, 10-15 years ago.
|
| Today, this model will only sabotage usage. People using your
| OSS is good. Even if your goal isn't to become popular, usage
| & feedback are learning, and while it's fine for popularity
| not to be a goal, I would encourage you not to proactively
| target the opposite of popularity.
|
| If you have some other IP (the other tech you're describing)
| that can remain proprietary or wrapped behind a service, then
| people using other pieces of your stack for free is a _really
| good thing._ At least, they're aware of your brand and have
| started to trust it. At best, they're ready to use your
| commercial offering out of the gate.
| zamalek wrote:
| IANAL/IANYL. Make it dual-licensed, AGPL with MIT by request.
| Indicate that you are presently declining MIT license
| requests. The chances of your agreement being adhered to are
| near zero, regardless of the legality. On the other hand, any
| mention of GPL will send lawyers running for the hills - AGPL
| more-so (and legally so, it makes your code basically useless
| to a corp). The MIT carveout is merely there so that
| contributors don't throw a fit if you choose a more
| permissive license down the line.
| giancarlostoro wrote:
| It's 5 thousand after you've made 200 thousand though? I think
| that's the only restriction? Unless he updated it before I got
| to look.
| Eliah_Lakhin wrote:
| > It's 5 thousand after you've made 200 thousand though?
|
| That's correct. The license agreement requires purchasing a
| commercial license per product if it reaches a certain
| revenue threshold. I believe this price should be feasible
| for a business, and this restriction is not unfair for
| regular programmers either. To clarify, the license needs to
| be renewed annually to continue receiving new versions from
| me. Additionally, I reserve the right to change the price in
| the future. However, license renewal is not a strict
| obligation. You can continue using the previous versions if
| you buy the license at least once.
|
| The idea is to replace the donation model widespread in
| typical OSS projects with a formal obligation to purchase a
| license. I believe this approach more accurately expresses
| what the authors really want in exchange for their labor.
| Vegenoid wrote:
| I think your approach is good. There are several ways to
| make money by independently making software:
|
| 1. Charge money for the software
|
| 2. Charge money to help people implement/use the software
|
| 3. Leverage the experience and credibility gained to get a
| company to hire you or sell consulting services
|
| 4. Hope that people give you money for the software out of
| the goodness of their heart
|
| Opting for an MIT license pretty much ensures that the
| software will only make money for you indirectly via option
| 3, and maybe you'll get a trickle via option 4. There are
| numerous examples of people making popular OSS that become
| frustrated with companies that are using their software to
| make money, and they aren't getting anything for it. They
| have to work for other people for money despite having made
| software that generates lots of value. If you want to
| ensure that if your software creates substantial value, you
| get some of it, you need a license like yours.
|
| I think there is a strong argument that if you want to get
| paid for your software, you simply shouldn't make it any
| flavor of source-available. A company may actually be more
| willing to buy software that is closed source than open
| source, because the closed-source software is simply
| _perceived_ as being more valuable. Of course, as an
| engineer, I love that the source code is available.
| weinzierl wrote:
| _" replacement for preexisting projects with similar goals, such
| as Tree-Sitter, Rowan, or Salsa."_
|
| To be a true replacement, there is at least one crucial feature
| missing: A LICENSE file that starts with _" The MIT License
| (MIT)"_.
|
| Nothing against "source available" but thinking to have a chance
| to stand in for more permissively licensed projects is very much
| unrealistic.
| vlovich123 wrote:
| It's amusing to me that we as a community both complain that
| OSS maintainers aren't paid and then expect someone who's
| making the source available to pick OSS. Let people try
| alternate funding models and honestly as a hacker community we
| should be a bit more supportive of the work required to
| bootstrap something.
| vendiddy wrote:
| Yeah I would like to see more ideas like this.
|
| I really hope there's a model out there for OSS at least
| where folks can get paid.
|
| I always wondered what if engineers had a $100/month budget
| to donate to OSS founders. It wouldn't cost an employer much
| and would be a good way to give back.
| mtndew4brkfst wrote:
| Thank you to the commenters who highlighted the licensing. I
| would ordinarily be _very_ interested in this premise but I don
| 't want to risk unconsciously adapting ideas from what I read
| that could put me in tension with the terms or the author, and I
| can't use it directly.
| gsuuon wrote:
| This is cool, I think an integrated compiler and LSP is a great
| standard for new languages. I'd go one further though and say
| that syntax highlighting should also be part of that language
| core. This way you have a single source of truth wrt to that
| language: how it should look, what it means and how it runs.
|
| Tree-sitter is widely supported (both in editors and on web) for
| syntax highlighting as well as making semantic nodes available
| for external tools to interact with. Is there any chance you'd
| add a tree-sitter integration to this project? Or conversely,
| build out a compatible API that can be used with editors/tools
| that use tree-sitter's library?
|
| The licensing is a bit confusing - for example, what happens with
| open-source projects that use this that are then used in
| commercial projects?
| Eliah_Lakhin wrote:
| > build out a compatible API that can be used with
| editors/tools that use tree-sitter's library?
|
| That's an interesting idea. Tree-Sitter and Lady Deirdre are
| quite different in their approaches to parsing. Tree-Sitter is
| a GLR parser, while Lady Deirdre is a recursive-descent parser.
| In the Lady Deirdre API, there are customizable traits that let
| you define new types of files with parsers ("documents" in
| terms of Lady Deirdre). Perhaps it would be possible to create
| an adapter, but I would implement it as a separate crate.
|
| > what happens with open-source projects that use this that are
| then used in commercial projects?
|
| Good question. The idea is that if you link to Lady Deirdre in
| the Cargo.toml dependencies, it is up to the commercial project
| authors. They will compile the actual executable intended for
| selling by downloading both your crate and my crate. However,
| I'm not a lawyer, and this is not legal advice. Just my
| thoughts.
| ilrwbwrkhv wrote:
| The good thing about the Rust ecosystem is that because it is
| hard, it keeps the Js script kiddies out of it, which means most
| of the popular packages and software is really high quality and
| well thought out.
___________________________________________________________________
(page generated 2024-06-21 23:00 UTC)