Earlier quoted context omitted.
It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great. So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it. Then, I intend to add an optio…
Any chance you could you share some references on this kind of type inference? It sounds very interesting!
The Lobster Programming Language
111–120 of 171 posts
Re: The Lobster Programming Language
#112Earlier quoted context omitted.
Yep oops, sorry. Anyway, psyched to see more people experimenting with this kind of thing!
Yes, I frankly feel this design space is the future of memory management. GC, begone!
http://concurrency.ch/Content/publications/Blaeser_Component...
This seems to scale out very well - it's kind of static GC analysis with RAII and erlang-style messaging.
Re: The Lobster Programming Language
#113This looks really fun: https://github.com/aardappel/lobster/blob/master/lobster/sam...
Are the generators implemented entirely in user space using continuation passing style? And the coroutine function turns it into something pausable?
Edit: I can't wrap my head around how return returns out of all the generators
Re: The Lobster Programming Language
#114Earlier quoted context omitted.
> Because it is a sufficiently divisive decision that it limits the audience. Considering Python is the 2nd or 3rd top popular language in indexes like TIOBE and job entries, and within the top-5 for over a decade, that's empirically false. It might put off some insignificant minority (that's superficial like that), but not enough people not to be hugely successful.
Some things can be popular despite their shortcomings.
Which is neither here nor there, as the accusation I was responding to was that "it limits the audience".
Other languages can only dream to have such "limited audience" as to be ton the top-3 TIOBE...
Re: The Lobster Programming Language
#115Earlier quoted context omitted.
Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?
It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great. So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it. Then, I intend to add an optio…
> I don't think its the right default though.
I think Rust should allow this kind of relaxed ownership, with ARC behind the scenes, as lots of user level code should not require fussing over ownership details. A "get shit done" mode.
Re: The Lobster Programming Language
#116Earlier quoted context omitted.
It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great. So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it. Then, I intend to add an optio…
> I don't think its the right default though. I think Rust should allow this kind of relaxed ownership, with ARC behind the scenes, as lots of user level code should not require fussing over ownership details. A "get shit done" mode.
Rust supports proc macros, you know-- you can do literally anything with your code. So what you describe is already possible! Make a good proof of concept and submit a proper RFC for it, and it might even be adopted as part of Stable Rust!
Re: The Lobster Programming Language
#117Hi, author of the language here. Not a great time for HN exposure, as I just added a lot of new functionality, but none of that is documented yet :) But hey, all publicity is good publicity? For those interested, some recent things that have been happening: - Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump t…
There's a lot of great technical info on the homepage, but it's tough for me to see the forest for the trees here. Could you make a short (probably oversimplified; that's ok) case for what Lobster is especially good at and why it's worth using rather than other programming languages? Or direct me to where one is already written?
Re: The Lobster Programming Language
#118000000128039 000000128034 000000128039 000000128034 000000128034 000000128034 000000128039 000000128008 000000128039 000000128008 000000128013 000000128039 000000128013 000000128034 000000128039 000000128034
Re: The Lobster Programming Language
#119Earlier quoted context omitted.
It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great. So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it. Then, I intend to add an optio…
This at first glance actually looks similar to http://liu.diva-portal.org/smash/get/diva2:20899/FULLTEXT01.... And this style of static analysis has been taken even further by Luc Blaeser: http://concurrency.ch/Content/publications/Blaeser_Component... The cycle checker I'll have to have a look at - I'd like to crib parts of it for an OS I'm trying to cobble together. Your project looks very interesting, thanks!
Thanks for those, I hadn't seen them. The Ritzau paper indeed appears to be doing something very similar, where in 5.2 he describes "inner references" whose lifetime is bounded by the outer one, I call that "borrowing", where the outer definition (the owner) gets locked from mutation during the borrow.
What I do is a bit more involved though, as for every language construct I indicate if it wants to own or borrow its children (and wether it wants the parent to own or borrow), to remove maximum refcounts, also for cases which are not simply variables. Again, I will describe this in detail.
The second paper I don't see how it relates to what I am doing.
Re: The Lobster Programming Language
#120Earlier quoted context omitted.
It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great. So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it. Then, I intend to add an optio…
> I don't think its the right default though. I think Rust should allow this kind of relaxed ownership, with ARC behind the scenes, as lots of user level code should not require fussing over ownership details. A "get shit done" mode.
Yes, that is exactly my intention, for the majority of code this compile time reference counting is good enough.
You can of course use Rc types in Rust, but that is verbose, and throws all ownership out the window, unlike Lobster.