Live data from Hacker News

Lang Jam: create a programming language in a weekend

github.com

91–100 of 135 posts

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

#91
post #65
post #30

Earlier quoted context omitted.

Another "crazy" idea: I'd like the compiler to reformat code to match strict style conventions. Why? Sometimes there's no "right" style. Sometimes novices need training wheels. In the long run, style doesn't matter, but in big projects code is easier to read when style is consistent. It's also easier to onboard when code follows industry-standard styles. Would it be better when a language gently pushes everyone to th…

> code is easier to read when... This is almost always a subjective opinion. I've worked on many projects where people reformat large portions of the codebase to make it "easier to read", and in the end they waste a bunch of time, make using `git blame` a pain, and subjectively either make no difference in code readability or make the code harder for half the team to read. > I'd like the compiler to reformat code...…

> Most people aren't reading code after it's been compiled

Ever start a new job with a bulk of code you didn't write? Worse, ever take over code written by novices who ignore common conventions?

The whole point is to see if having a standard style is easier in the long run.

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

#92
post #48

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…

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)

We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping.

When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit

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

#93
post #39

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…

I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.

The D compiler has Walters last compilers backend. It is very useful to have a really fast debug build. It's also potentially remarkable how slow LLVM is given that the D compilers backend is actually pretty inefficient in places yet still munches LLVM on debug builds.

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

#94

Earlier quoted context omitted.

My favourite FizzBuzz is in Haskell, I found it in this talk by Kevlin Henney[0], and looks like this: fizzes = cycle ["", "", "Fizz"] buzzes = cycle ["", "", "", "", "Buzzes"] words = zipWith (++) fizzes buzzes numbers = map show [1..] fizzbuzz = zipWith max words numbers Henney explains in detail in the video, but it makes use of lazy evaluation to create an infinite list of FizzBuzzes, and also uses no if statemen…

"max" seems like an odd choice. Wouldn't that start to fail at large numbers? Edit: Nevermind, max is lexicographic, not based on string length. Brain fart.

Yes, that part is hacky. It's easy to write a short function to do the same thing explicitly but then you lose the concise charm

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

#95
post #90
post #68

Earlier quoted context omitted.

You just essentially described Swift

Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.

Whether or not Swift succeeds at being memory-safe, in theory, it's supposed to be.

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

#96

Maybe I'm not reading correctly, but it seems the project is about making a language compiler and not a language itself?

What’s the difference?

When you think "language", try not to let your mind jump straight to "compiler" or "interpreter". Think more, "specification". If I asked you to write me a C compiler and you delivered on that, I'm not left with a new language. You didn't design a new language, only the compiler for an already specified language.

Designing a language is more about defining a specification. Then 10 different compiler engineers may pick that spec up and implement 10 different implementations of the same language, for example.

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

#97
post #90
post #68

Earlier quoted context omitted.

You just essentially described Swift

Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.

Absolutely not. Both Swift and Rust are actively taking inspiration from each other.

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

#98
post #39

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…

I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.

That is definitely not the case. Compiling C with LLVM is very fast.

In Swift, type inference is one thing that can be extremely slow.

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

#99
post #90
post #68

Earlier quoted context omitted.

You just essentially described Swift

Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.

I just totally disagree. Swift might look a bit more like C#, but in terms of features it's way more similar to Rust for all the ADT-related features mentioned in the grandparent comment.

Also, regarding memory safety, it's not as safe as Rust - it's basically only memory-safe in the single-threaded context, but it's still relatively safe compared to other languages.

I don't really find it easier to crash than Rust - thanks to optionals you get the same guarantees against NPE's. You can choose not to take advantage of it, but you can also force-unwrap in Rust if you want.

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

#100
post #90

Earlier quoted context omitted.

Swift is more like C# or Java than Rust. It's more like adapting C# to the objective C runtime than Rust. It's also not memory safe. It's very easy to crash the process.

Whether or not Swift succeeds at being memory-safe, in theory, it's supposed to be.

It's memory-safe in a single-threaded context. The actor model would theoretically bring multi-threaded memory safety (with a different set of tradeoffs than Rust).
Post reply on HN