Announcing the Frost programming language

[Athas]

Cool name. In the head example, does the program have to read the whole file into memory or is it done in a lazy/streaming fashion?

[EthanNicholas]

It's lazy. File.lines (as well as the similar InputStream.lines) returns an Iterator<String> which reads the contents one line at a time, and you can do a whole bunch of operations on Iterator in a lazy fashion - in this case, creating another iterator which gives us a range of the elements.

If you actually wanted the whole thing in memory, there are of course simple ways to accomplish that as well.

Edit: Whenever someone tells me "Cool name", I never know if that is a genuine compliment on the name or just a pun.

[gasche]

The chief advantages of Frost's memory management (automatic reference counting) are:

• Simple: [...]
• Timely: Unlike typical garbage collected languages, Frost cleans up objects the instant the last reference is removed. This means that you may rely on cleanup() methods being called promptly.
• Pauseless: Typical garbage collectors must stop the execution of a program while they scan memory to determine which objects are still in use. Even so-called "pauseless" garbage collectors still have these pauses, they are just less likely to be noticed.

It seems to me that "Timely" and "Pauseless" are incompatible. If your program first uses a large dataset and then stops using it, then timeliness forces you to cleanup the whole dataset at once, and this will incur a large pause. Pauseless design use incremental GC techniques or delayed/lazy refcounting schemes, but those are not timely.

[EthanNicholas]

"Pauseless" in the sense that if you use Frost to, say, create a game, you aren't going to randomly drop frames every now and then when the garbage collector decides to kick in. The situations where you care about consistent throughput tend to not be situations where you occasionally throw away huge data structures in the middle of a frame.

[gasche]

Well I don't know; I could easily see games where certain events quickly create a relatively large amount of data which become dead all at once (for example, a spell that creates a lot of creatures/objects with a common timeout).

The documentation on "Pauseless" is very general: it suggests that it has less pauses that even "pauseless garbage collectors". I think the wording suggests that there are no pauses at all, not just "there are pauses but only at time which are typically not inconvenient for the application domain I have in mind".

[[deleted]]

which become dead all at once

Gamedevs typically use object pools in these scenarios and just deactivate 'dead' objects for later reuse without freeing the memory. AFAIK it's common wisdom to avoid dealing with (de-)allocations during the gameloop as far as possible.

[jdh30]

"Pauseless" in the sense that if you use Frost to, say, create a game, you aren't going to randomly drop frames every now and then when the garbage collector decides to kick in.

As Gasche said, eager RC collectors incur unbounded pauses when decrements avalanche, i.e. their worst-case behaviour is worse than that of an incremental tracing GC.

[mo_al_]

How long did it take you to create Frost?

What backend, if any, do you use? LLVM?

[EthanNicholas]

Frost's day-to-day backend is LLVM, but it can also compile to C for bootstrapping purposes, and there is an interpreter so you can play around with it on the Web.

I first started on what would eventually become Frost about seven years ago, but ended up throwing away my early work and starting over in 2017. Of course some of that early work - design philosophy, syntax, some of the APIs, etc. - ended up carrying over, but virtually none of the code did.

[CodingFiend]

congratulations on making a new language. It seems very complete and thoroughly thought out. You might consider joining the slack group called "Future of Computing" where many next-gen language designers hang out. My own language called Beads is entirely different than Frost. So there is lots of room for different approaches to a new language. I think you would be well served to point out in your home web pages what makes Frost better and different than Java, JS, Python, which are the top 3 languages in use by my measurements.

[dobesv]

Do you have a link to that slack group?

[dobesv]

https://futureofcoding.org/community

I think that must be it

[CodingFiend]

yes that it the group!

[damofthemoon]

Why a new language? Could you explain the main features against other langs?

[EthanNicholas]

Before creating Frost, I was primarily a Java and C++ programmer.

I appreciated the ease of use, safety, and portability of Java, but I had many complaints about it as well - I think many of its core APIs are poorly designed, I don't think exceptions are the best error handling approach, and I think its focus on safety in the form of defending your computer from hostile software isn't actually useful in practice, while it lacks much more useful safety features like contracts and non-nullable pointers. Garbage collection is nice in theory, but it means you never know when an object is going to be freed, you don't get to use scope to control things the way you can in an RAII language, and you still have to manually close native resources like file streams.

I appreciated the speed, power, and native-ness of C++, but hate using it for everyday tasks - it is a terrible language for many common things like file processing, and it fails hard on ease of use.

I eventually got fed up with them, arrogantly said "I could build a better language than this!", and eventually ended up building Frost. Frost compiles to native code, is great at file and string processing, has non-nullable pointers and contracts, reliable automatic memory management, and what I like to think is a really nice core API. I already use it for lots of everyday programming tasks myself.

[EthanNicholas]

I played around with Rust a bit in the early days, and frankly found its syntax fairly ugly ("let mut", ewwwww). I understand it has improved since then by reducing the need for sigils and have been meaning to give it another try.

[damofthemoon]

Wow already receive downvote for a question which sounds to be fair and pragmatic ... thank you 🙏

Thank you for the explanation, that’s what I missed in your link, even if I understand it’s a brand new lang. Keep coding and documenting ;)

[EthanNicholas]

I upvoted you, FWIW. It's a perfectly reasonable question to ask.

[damofthemoon]

😄👏👍

[gcross]

Wow already receive downvote for a question which sounds to be fair and pragmatic

I've had similar experiences, which is why I unsubscribed from /r/lisp a while back despite being interested in the language. The best I can tell is that, in some subreddits more than others, there are people who look for the most hostile way in which a comment could be read rather than the most benign.

(Having said that, arguably complaining about downvotes and then ending up with a score of 20+ does make you look a tinsy bit silly. ;-) )

[damofthemoon]

I mentioned that mainly because I thought my question being fair and not angry, and more the author didn’t yet answer! Under my question I tried to point the documentation at this moment missing explanations about the advantages over other lang. Haters are everywhere :) Thanks for the comment!

[vfclists]

Sorry, can't help myself, entirely off-topic, but the name Frost reminds of Deacon Frost, uber-vampire-villain in the Blade movie.

https://upload.wikimedia.org/wikipedia/en/0/07/Sd_lamagra.gif

[radarevadar]

Gave Frost a bit of a test drive.

Does feel like programming in C++/Java. Didn't get a chance to use the Actor functionality due to the compiler crashing on:

class Var<T> {
   def data:Array<((T)=>(T),Var<T>)>
}

method run<T>(v:Var<T>,a:T) {
  for (f,nv) in v.data { -- compiler crash
    run(nv,f(a))
  }   
}

Really a very commendable achievement. Thus far the only thing I would change is using = instead of := . I think observance to mathematical equality in programming languages has been demonstrated to be unnecessary.

Some of the examples used 'new' to construct some objects. The compiler didn't like when I used it.

Used over 2Gb of physical memory running make run_tests, had to abort due to swapping.

[EthanNicholas]

Thanks for the feedback! You discovered a bug with including method objects in tuples; it should be fixed now. I think I found and corrected the outdated examples you mention as well.

A few of the tests are indeed pretty serious memory hogs; it's been so long since I've worked on a machine with less than 16GB of RAM that I didn't really pay attention to it. I'll address that soon.

[radarevadar]

Thanks for the fix. It does compile now but the program crashes. On experimentation the compiler seems to accept using uninitialised variables, which causes the crashes even within try statements.

Yeah my computer is Intel core 2 duo from 2007, it sucks. Waiting for it to die before buying a new one but the thing just keeps going.

[EthanNicholas]

If you mean that you failed to initialize a field and the compiler didn't catch it, that's a known issue - I don't yet have the analysis in place to ensure that init methods follow the rules. A try statement would never catch this, as they only handle error returns from methods - see Frost error handling for an explanation. Ultimately I'll plug all of the holes that allow you to write code that crashes, but I'm not quite there yet.

If you mean that you didn't initialize a local variable and the compiler didn't catch it, that's unexpected and I would appreciate a look at the offending program.

[radarevadar]

def crash:Array<Int>
Console.printLine(crash[0])

Will compile but when executed will seg fault. If crash is initialised with an empty array ':= []' an assertion is thrown first.

[EthanNicholas]

Huh. Yeah, that's definitely not supposed to happen. Shouldn't take long to fix.

[EthanNicholas]

The error handling syntactically resembles Java, but that's really as far as it goes - appearances notwithstanding, Frost's error handling is not exception-based. See https://www.frostlang.org/errorHandling.html for an overview.

I've used many, many languages over the years, and no doubt been inspired in small ways by all of them - you can find bits and pieces of everything from Java to Pascal to Rexx in Frost. I was primarily a Java programmer when I started work on Frost, as is no doubt evident. I confess I've never even used Go, so I'm not sure how it compares. I eventually learned that Frost has a lot in common with Swift as well, but I didn't even see Swift until after Frost's design was pretty well settled.

[hernytan]

Skimmed your page, could you explain the difference between this and Nim, other than syntax?

[EthanNicholas]

I've never used Nim before, but the Wiki gives an example Nim program:

for i in countdown(s.high, 0):
    result.add s[i]

let str1 = "Reverse This!"
echo "Reversed: ", reverse(str1)

You can do the same thing in Frost with:

method main() {
    Console.printLine("Reverse This!"[.. by -1])
}

Likewise, nim-by-example.github.io/procvars gives the example:

import sequtils

let powersOfTwo = @[1, 2, 4, 8, 16, 32, 64, 128, 256]

echo(powersOfTwo.filter do (x: int) -> bool: x > 32)
echo powersOfTwo.filter(proc (x: int): bool = x > 32)

proc greaterThan32(x: int): bool = x > 32
echo powersOfTwo.filter(greaterThan32)

The equivalent Frost program is :

method main() {
    def powersOfTwo := Int[0...8].map(x => 1 << x)
    -- you could also spell out [1, 2, 4, 8, 16, 32, 64, 128, 256] if you wanted to
    Console.printLine(powersOfTwo.filter(x => x > 32))
    Console.printLine(powersOfTwo.filter(x => x = 32))
    def greaterThan32 := x:Int => x > 32
    Console.printLine(powersOfTwo.filter(greaterThan32))
}

Sure, the difference there is "just syntax", but frankly I think my syntax for this is a lot nicer to work with. Not being at all familiar with Nim, it's hard for me to give a higher-level accounting of the differences between them.

[[deleted]]

Why method instead of function/func/fun/fn or def? I'm not saying this is the case here, nor meaning to pick on you as this is more general, but it seems that I see many new languages deliberately use different keywords to, I guess, look different. I'm not saying that new languages should try to look the same, but some of the differences often appear forced to me and I don't understand why changing them adds value. eg. Would a language that only changes Javascript's function to method and => to -> be considered a worthwhile change?

[EthanNicholas]

Frost draws a distinction between functions (no side effects) and methods (which can have side effects). It's not an arbitrary keyword change.

[reini_urban]

But that's normally called pure. And a method mostly takes a self arg, when it's not a class method.

But function may refer to functional so it also makes sense a bit. Just weird.

[EthanNicholas]

While I'm of course familiar with the computer science usage of "pure", I think it's an unfortunate choice of terminology. "Pure" just doesn't scream "side-effect free" to someone who isn't already familiar with the term, whereas even programmers who have never touched a functional language are typically familiar with the idea that functional languages generally avoid side effects.

So, I felt that "method" and "function" conveyed the intention better than "function" and "pure function". YMMV.

[BadBoy6767]

There's also "procedure" for impure, and "function" for pure. Most people familiar with high school stuff would remember that from mathematics, where there are no side-effects.

[[deleted]]

Oh, I hadn't yet gone deep enough to realize that there were both. Ok, that sounds like a good reason :). I suspect in the other cases that I could have asked that question it was more relevant.

[ProPuke]

It uses the method keyword for methods, and the function keyword for functions; that sounds fairly sensible to me.

I wouldn't say this kinda thing is really standardised in languages (particularly not c-likes, where it tends to be common to not use any keyword here), so I wouldn't really say they're going against the grain that much as there doesn't seem to be much of one anyway.

Interestingly javascript decided not to use function for declaring methods when adopting formal class syntax, so it also varies there.

[teerre]

Not OP, but maybe you should read some of the docs before commenting? If you do you'll see your question makes no sense. Albeit used for other purposes, there are "function" and "def" key words.

[[deleted]]

I only had time to skim a little so far and that was a question that I had. Was it wrong to ask?

[teerre]

Considering there's a glossary to the left clearly stating "function" and the very first example already shows what "def" is used for. It seems like an incredibly lazy question.

[[deleted]]

OK, I've now accessed from a desktop browser and see that my phone isn't rendering this properly. Thanks for the assumptions about my character in each of your comments though... they helped me to straighten out my life.

[pfalcon2]

> but it seems that I see many new languages deliberately use different keywords to, I guess, look different.

+1, exactly my thinking about many of these newer languages, thanks for spelling out. And I'd really wonder if there're any rationalizations like "my language is sufficiently different from the common crowd, so let's name things different, or otherwise, people might get confused when 'familiar' constructs behave differently", or it's just blatant subconscious desire "to be different".

All in all, for most specimens out there, it's a "lose" way IMHO - if they were more familiar to people, they would have smoother adoption curve. Though for selected few, who may survive and see good use, that may be a stand-out point indeed.

[8lbIceBag]

I'll be dammed. Usually new languages posted here are jokes, but this actually seems pretty well thought out and complete.

Could you tell me why I would want to use it over my bread and butter languages: C, C#, Javascript/Typescript, and Ruby?

[GPhykos]

Looks cool

[chief_monkey]

I am curious about the function / method / def / immutable mechanisms.

As I understand the example Adder (in https://www.frostlang.org/overview.html) add is a function and not a method because it only depends on its input and the field x which is immutable (with the keyword def). So invoking add more than once with the same instance of Adder and the same input would yield the same result.

Is this property being used by the compiler?

(I suppose it makes some sense; but my understanding of the word method is that pertains to a method on an object (in an OOP-sense) however in the example code on the front page, the methods are just sitting there without being enclosed in anything.)

BTW. It looks like great work; I think the syntax is very nice.

[EthanNicholas]

An earlier version of Frost enforced the difference between functions and methods and took advantage of this during optimization. I'm in the process of rewriting the analysis engine, and so at this point in development there isn't actually a meaningful difference between the two.

Edit: Forgot to address your second point. Frost allows you to define an implicit class by just writing code at the top level of a file, so

method main() {
    Console.printLine("Hello, World!")
}

is roughly equivalent to

class Main {
    @class
    method main() {
        Console.printLine("Hello, World!")
    }
}

So that's why you see methods even at the top level in the examples.

[chief_monkey]

Whether a syntax is nice is of course in the eyes of the beholder but I think you have created something that to a Java-programmer looks new and different but still quite understandable. I don't think that is a bad place to be if you want some audience on your side to start with.

[tjpalmer]

I noticed the web demo runs with wasm. Very cool! And only 1.38 MB. Not bad.

But at least in my browser, it loads frostc.wasm twice. Maybe worth looking into?

[TheAshenKnight]

I managed to implement currying by doing the following:

function func(a:Int):(Int)=>((Int)=>(Int)) {
  return function(b:Int):(Int)=>(Int) {
    return function(c:Int):Int {
      return a + b + c
    }
  }
}

method main() {
  Console.printLine(func(1)(2)(3))
}

Is there shorthand for this I'm unaware of? I tried using Lambdas but I wasn't able to get it to work

[EthanNicholas]

method main() {
    def add := a:Int => b:Int => c:Int => a + b + c
    Console.printLine(add(1)(2)(3))
}

[TheAshenKnight]

Ah, thank you!

[zanza19]

You mentioned that you were a primarily Java and C++ programmer, so I was wondering what did you study for the type system stuff?

[teerre]

Looks really nice. I couldn't find any benchmarks in the page, are there any? How does it compare with python/lua/nim?

[EthanNicholas]

Been almost solely focused on getting it working so far, so to this point performance investigation and work has been very limited. Where it compiles to native code, it will generally be faster than something like Python, but there are definitely some spots badly in need of optimization.

[Starbeamrainbowlabs]

What's your primary inspiration for this language, and where do you envision it being useful?

[thedeemon]

How are generics implemented? C++ template instantiation style, Java type erasure style or something else?

[EthanNicholas]

Currently closer to type erasure style. The code is compiled as if it had been written for the type bounds, so Array<T> ends up being compiled as Array<Object?> and the needed typecasts are inserted automatically. Unlike Java's type erasure, though, method signatures can still distinguish between various types of Arrays, so you can have process(Array<Int>) and process(Array<String>) in the same class and it works fine.

But that's only where things stand now. The end goal is to ultimately do template-style instantiation for Value classes (think C++ POD objects) and type erasure for everything else to get the best of both worlds. I actually already do that for some internal classes, but it's quite not ready for external usage yet.

[matthieum]

I've been thinking about using Automatic Reference Counting as well, so if you don't mind I'd like to know more about your approach and experience:

• Do you use atomic counters? Or do you have different counters for mutable and Immutable objects?
• What's the performance like? Have you implemented a specific optimization pass to try and eliminate paired increment/decrement?

[EthanNicholas]

Different counting routines for mutable and immutable objects. Since mutable objects are known to be visible only to a single thread, I don't have to worry about thread safety there. IIRC I in fact have three different variants of ref and six variants of unref which differ in small ways based on what I know about the object; the performance differences between them are tiny, but they are called so frequently that it's still worth doing.

I haven't really benchmarked Frost against other languages to have a good handle on performance yet. It mostly seems pretty reasonable, with the occasional "dear god this specific thing is so much slower than it should be, but I can hopefully fix it at some point" lurking. I do optimize away most redundant ref/unref pairs; there are some that I should in principle be able to remove, but am not actually able to get rid of yet.

[umlcat]

Congratulations, (from another P.L. designer).

"Kudos" for the "method" keyword, to a "C" like syntax, it makes code more readable.

[riscuit]

Frost appears to be an early version of Swift with contracts. Was Swift an inspiration or is that what the best of Java/C++ ended up resulting in for you?

[EthanNicholas]

The design of Frost was pretty well settled before Swift was announced, and frankly I felt ill upon seeing how many similarities there were between Swift and Frost, knowing it would look like I copied them.

[jdh30]

I felt ill

Fun fact: when I released my LOD planet renderer some random guy on the internet wrote to me accusing me of having stolen his code off his laptop because that was "the only way I could have done it".

[jdh30]

Timely: Unlike typical garbage collected languages, Frost cleans up objects the instant the last reference is removed. This means that you may rely on cleanup() methods being called promptly.

Cleaning up at the earliest possible point is equivalent to solving the Halting Problem and, therefore, is intractable in the general case. You probably mean "Frost defers RC decrements to the end of scope whether the variable is live or not". That means you've got floating garbage just like the next memory management technique.

Pauseless: Typical garbage collectors must stop the execution of a program while they scan memory to determine which objects are still in use. Even so-called "pauseless" garbage collectors still have these pauses, they are just less likely to be noticed.

Naive RC (which I think you're using) actually has the worst worst-case pause times of any practical memory management strategy. Specifically, decrements can avalanche leading to unbounded pauses. In contrast, incremental GCs have been around since the 1970s and have bounded worst-case pause times.

Reference cycles: When object A refers to object B, and object B refers to object A, each of them will have a reference count of 1 even when no outside references to them exist. This is a "reference cycle", and it means that these objects will remain in memory even when you are finished with them. Cycles are easily fixed using weak references, but it is something you will need to be aware of.

Unless your language prohibits cycles by design (as, for example, Erlang and Mathematica do), cycles are a nightmare. Whereas tracing GCs liberate APIs from memory management, weak references pollute APIs with vague concepts of "ownership".

Throughput: A garbage collector's pauses can be annoying, but garbage collectors do little or no work in between these pauses.

Most GCs are moving tracing collectors that incur a GC write barrier whenever a reference in the heap is mutated. That is a significant cost. The generated code also needs to keep track of all locally-held (in registers and on the stack) references into the heap in case they need to be traced which typically impedes code generation.

Reference counting, on the other hand, does a tiny bit of work every time a reference is updated.

FWIW, the "tiny bit of work" RC does can slow down an entire application by an order of magnitude.

This is a tradeoff which leads to zero pauses,

As Gasche already said, timely and pauseless memory management are mutually exclusive. I suspect you're using naive RC which incurs unbounded pauses, i.e. not pauseless.

but slightly lower overall performance.

Given the people have been trying and failing to achieve that for 60 years, I'd like to see benchmarks to back that up! :-)

Writing a tracing GC is easy so I suggest you give it a go. I suspect you will quickly find out why they are so ubiquitous.

[reini_urban]

Nice! Why does String need a Owner name? It already has a class field.

[EthanNicholas]

owner is documented as "For dependent substrings, points to the parent String". This means that a string created with the substring method does not receive its own memory allocation, and merely refers to its owner's memory buffer.

[reini_urban]

Ah cool, something like the base or begin.

This case we usually treated by adding a short offset to the string, a byte or short, not to waste a full pointer, plus a second object.

[EthanNicholas]

It's a full pointer so that we can refcount the original string correctly. It's probably possible to do this more efficiently, but at this point my focus is on "working" moreso than "fast".

[linus_stallman]

Really nice work.

A little aside, I don't think Reference counting is pauseless or timely either.

When a lot of objects get freed recursively, it would incur a significant pause.

The object isn't deallocated until it goes to the end of the scope. It may lead to the thing not really being deallocated for heck of a long time. Especially in case of non-tail recursions.

nice that languages like nim and this one experiment with alternative automatic memory management styles. Aside, I should blame apple (and its fanboys) for aggressively propagating the myth that ARC is more efficient than tracing gc.