Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lang Jam: create a programming language in a weekend

github.com

Post reply on HN
Print view View original

121–130 of 135 posts

Re: Lang Jam: create a programming language in a weekend

#121

Post by mbStavola »

verdagon wrote: post #35
codetrotter wrote: post #20

As someone that writes a lot in Rust, I have a longstanding dream to make a compiler for a subset of the language, since I don’t use all features of Rust and my hope is that this way I could have fast debug builds (in terms of compilation time) while I develop, with simplified borrow checker and so on. So then I can iterate faster. That’s one of my dreams. But I have not had time to even look at it yet, as the other…

Any ideas on how one can simplify the borrow checker?

Niko Matsakis, of Rust's lang and compiler teams, has a talk[1] on how the machinery behind borrow checker is being rethought. The idea is that in the future, the compiler won't really "check borrows" but will instead "track origins."

Reframing the system in this way will (hopefully) make things be flexible enough to Just Work™ without surprises, while providing the same guarantees as the current borrow checker. The video itself has a motivating example or two that shows where this stuff would be helpful.

[1]: https://youtu.be/_agDeiWek8w

Re: Lang Jam: create a programming language in a weekend

#122

Post by mbStavola »

mbStavola wrote: post #121
verdagon wrote: post #35

Earlier quoted context omitted.

Any ideas on how one can simplify the borrow checker?

Niko Matsakis, of Rust's lang and compiler teams, has a talk[1] on how the machinery behind borrow checker is being rethought. The idea is that in the future, the compiler won't really "check borrows" but will instead "track origins." Reframing the system in this way will (hopefully) make things be flexible enough to Just Work™ without surprises, while providing the same guarantees as the current borrow checker. The…

For those who don't want to sit through a video there is also the book[1].

[1]: https://rust-lang.github.io/polonius/

Re: Lang Jam: create a programming language in a weekend

#123

Post by rmetzler »

benibela wrote: post #119
rmetzler wrote: post #116

I could use something similar to jq, but for XML. Or something like a lovechild of sed, awk, seq, and cut, with regexp match groups and string interpolation.

> I could use something similar to jq, but for XML. That would be XPath/XQuery I have spent 15 years implementing that in Xidel >Or something like a lovechild of sed, awk, seq, and cut, with regexp match groups and string interpolation. Sounds like Perl

The argument that you can express something in an existing language doesn't mean you shouldn't try to create something more expressive.

Re: Lang Jam: create a programming language in a weekend

#124

Post by timClicks »

skohan wrote: post #69
timClicks wrote: post #40

Earlier quoted context omitted.

You could implement it as a runtime check

Why not just use GC at that point? I thought the whole USP is the zero runtime cost

It would be a garbage collector. I assumed that the person asking the question was primarily looking for a simpler implementation option, not to re-create rustc exactly.

Re: Lang Jam: create a programming language in a weekend

#125

Post by benibela »

rmetzler wrote: post #123
benibela wrote: post #119

Earlier quoted context omitted.

> I could use something similar to jq, but for XML. That would be XPath/XQuery I have spent 15 years implementing that in Xidel >Or something like a lovechild of sed, awk, seq, and cut, with regexp match groups and string interpolation. Sounds like Perl

The argument that you can express something in an existing language doesn't mean you shouldn't try to create something more expressive.

They are making new languages far too often

It started with XPath, then came XPath 2, then XQuery 1, then XPath 3.0 and XQuery 3.0, and then XPath 3.1 and XQuery 3.1.

Six new languages each more expressive than previous one. That is why it takes forever to implement them. And now people are working on XPath 4.0 and XQuery 4.0.

And Perl got Perl 6 and Perl 7 and Raku

Re: Lang Jam: create a programming language in a weekend

#127

Post by Doxin »

fouc wrote: post #23

What kind of language ideas do you folks have? What would your fizzbuzz look like? I'm not sure I've ever seen a more readable compact fizzbuzz than this version in coffeescript ['fizz' unless i%3] + ['buzz' unless i%5] or i for i in [1..100]

Python can do it with similar compactness:

    [(("fizz" if not i%3 else "")+("buzz" if not i%5 else "")) or i for i in range(1, 101)]
Gotta love list comprehensions.

Re: Lang Jam: create a programming language in a weekend

#128

Post by rmetzler »

benibela wrote: post #125
rmetzler wrote: post #123

Earlier quoted context omitted.

The argument that you can express something in an existing language doesn't mean you shouldn't try to create something more expressive.

They are making new languages far too often It started with XPath, then came XPath 2, then XQuery 1, then XPath 3.0 and XQuery 3.0, and then XPath 3.1 and XQuery 3.1. Six new languages each more expressive than previous one. That is why it takes forever to implement them. And now people are working on XPath 4.0 and XQuery 4.0. And Perl got Perl 6 and Perl 7 and Raku

Mayby they should work on a new language with a new name instead of stuffing features in existing languages? And let users decide what they like better?

And this is a post about creating lots of new languages. This doesn't have the goal of having languages that run in production, it has the goal of exploring the solution space.

Re: Lang Jam: create a programming language in a weekend

#129

Post by maattdd »

awestroke wrote: post #56
Zababa wrote: post #50

Earlier quoted context omitted.

You could try OCaml (it does have exception but they're usually "opt in"), it's a really nice language and probably one of the closest to GC'd Rust. There's also Swift that inspired some features.

OCaml is often dropped due to its unpredictable performance

I don't think I've ever heard that. Ocaml performance is surprisingly very predictable.
Post reply on HN