Ballerina Programing Language
ballerina.io
ballerina.io
For example, "Structural, Open-by-Default Typing". It sounds really interesting, but the image next to it just looks like what you'd get in Go (except for nullability checks), C#, Kotlin, and many other languages. Yes, static typing (especially with nullability checks) can make life difficult. You have to make create-request objects that don't have an id in them or you have to make the id nullable. Responses might include different fields like an updatedAt. How do you convert between those types without requiring lots of boilerplate conversion code that you're likely to mess up. But it doesn't really say what it's solving. The saying about being liberal in what you accept and strict in what you send is nice, but doesn't tell me anything. How does it achieve that without lots of code and checking? From the struct on the left, it looks like I'll have to constantly check if id is filled out...or have a CompleteResult type where id isn't optional. A link to an example of what this means and how other languages don't solve it would be wonderful.
Likewise, it says "The Network in the Language". Sounds like great marketing speak that doesn't mean anything. Ah yes, "the fallacies of distributed computing". How does it solve the fact that networks aren't reliable in a way that other languages don't?
I guess I always want to know the "how". Claims are easy, but for many of these problems there's a reason why someone else hasn't solved them. Maybe you have figured out a better way, but the site hasn't said what that better way is. The example image for "Structural, Open-by-Default Typing" doesn't look different from a Kotlin data class: it has statically typed fields, some are nullable. Can I assign a string to an int field and it won't crash? What about when I try to read it? What does "Structural, Open-by-Default Typing" mean? From what I see in the image, lots of other languages have it and I don't see how it enables the robustness principle.
Again, there might be great things in here, but the home page doesn't show anything and the quick tour shows error handling that's similar to Rust (or Go's with a short-cut to return the error like has been proposed for Go 2.
Instead of linking to a description of the problem on Wikipedia, it would be great to link to a page with your solution and how it's a pain point in other languages. Like, how do you abstract away the fact that the network is unreliable? The quick tour shows a client requesting from an API, but the only thing I see is a `check` keyword which is similar to the `?` operator in Rust which just returns the error if there is one and unwraps the result if it succeeded. It's a short-cut over Go's `if err != nil` and more explicit than runtime exceptions, but it hasn't shown me how it's different from other languages.
I guess I just need to know how someone solved a problem if they're saying they've solved it. Yea, we all know that networks are unreliable. We all know the pain of dealing with data that's slightly wrong over the wire. Link to how you're making that better and how other languages aren't handling it well.
Go types are structural. C# types are nominal.
https://en.wikipedia.org/wiki/Structural_type_system
"Open-by-Default" probably refers to the fact that structural types are more flexible to use.
Go's type system is also nominal. If it were structural, it would allow you to have two types `type foo struct { id string }` and `type bar struct { id string }`, and let you assign a value of type `foo` to a binding of type `bar`, which it does not.
https://ballerina.io/spec/lang/2019R3/
I also wrote a blog explaining what we are trying to achieve:
https://blog.jclark.com/2019/09/ballerina-programming-langua...
But the ability to define services as HTTP/Ingress endpoints, Docker containers, and Kubernetes/Openshift resources natively as part of the language is incredible. Add that to the fact that they have native support for things like tabular data and table queries as primitives, stream operations, distributed transactions baked in, multiple kinds of service-level auth natively, and a bunch of other goodies like observability/metrics primitives + support for Kafka/OpenAPI/etc etc and you have one hell of a language.
Interoperability with the existing Java and JVM ecosystem is huge.
I would be unpleasantly surprised if this does not take off, or at least similar concepts in other languages. Today, the closest thing you can get is Pulumi for defining infrastructure + deployments in code, and then your regular application codebase on the side.
If you want to see a featureset that a modern language built for web-services & cloud-native architecture should strive for, check out their learn-by-example list (in particular, the items past basic grammar & syntax):
This is specialized language suited for more or less one task that has nothing specialized for that task which cannot be rolled in Clojure in a day or two.
Challenge me, give one example that can't be done as easily with Clojure.
Static typing is a preference of the developer or development organization on whether they want speed or they need a bit of help to understand what they have before their eyes. It lets the compiler call you out on some of your transgressions at the cost of quirky type system and possibly having to need a bunch more code where a very simple solution would present itself when type system does not get in the way.
Static typing is neither bad or good. It "depends".
It doesn't yet have generics because they are hard to get right and the language is still at an early stage. Many languages that subsequently added generics did not have them in the earliest versions of the language (C++, Java, C#, TypeScript, Go).
Someone else mentioned this is based on JVM. There is no mention of JVM on the homepage. So, is it based on JVM? Or some interpreted language? Or compiled to native code?
"The Network in the Language" What does this mean?
"Sequence Diagrams for Programming" What does this mean?
"Structural, Open-by-Default Typing" Looks pretty standard?
"From Code to Cloud" What does this mean? Just some nice tooling?
"Batteries Included" Like most other languages.
"Developer First" What does this mean? What's different to other languages?
This sounds all like marketing fuzz, without telling actually any information. Really. I have no idea what this language is about.
Is this a competitor to other JVM languages? Or to system languages like C++/Rust/Nim/etc? Or to languages like Go/Erlang? Or to languages like Python/Ruby? And what's special about this language?
mdasen summarized my complaints in a nice way: https://news.ycombinator.com/item?id=22402053
Meaningless tagline.
> Static typing is the network application programmer’s development headache and dynamic typing is the reliability engineer’s nightmare. Ballerina’s statically-typed, structural type system that is designed to be network data schema friendly allows application programmers to write code that adheres to the Robustness Principle: Be conservative in what you send, be liberal in what you accept.
Nowadays we recognize that this is not necessarily a good idea. Se the very long ietf@ietf.org thread titled "deprecating Postel's principle - considered harmful".
So, this is a fascinating project. I don't know how I'd introduce it at a company though. Maybe in a skunkworks group or something. Possibly if I was working as some sort of middleware-integrator group.
The JVM bits don't bother me, but it does make things heavierweight than I'd like.
Curious if anyone is using it, it seems to have tons of potential.
Welcome to automation (PLC) programming where sequence programming has been around since 80s.
That's a debunked principle that causes unintended harm.
Programs should be conservative in accepting just their documented range of inputs, and loudly rejecting and diagnosing anything else.
Any behavior that looks "liberal" should actually be so by a specified design, within exact limits, operation outside of which is ideally flagged and rejected.
As you say, all behaviors should be fully specced, and inputs that violate that spec should rightly be rejected. It’s the spec itself that should be forgiving.
e.g. Don’t require fields for which sensible defaults can be assumed. Don’t be needlessly anal about case and white space variations. Maintain backwards-compatibility by continuing to accept older input formats alongside the latest and greatest. Accept ints where floats are expected. And so on.
HTTP is a good application. Whereas the eejits who invented HTML have a helluva lot to answer for.
Sensible defaults can't be assumed; they have to be specified. My sensible may be your silly.
If a spec defines certain parameters, and neglects to say anything about their defaults, and an implemention assumes defaults, that will cause issues.
Firstly, the user will break if they go to another implementation which rejects their data. It's not that implementation's fault; it's just catching the error of missing values with unspecified defaults.
Worse, the user's data can silently be interpreted with some different defaults.
You have to be exactly as anal about case and white space variations as the spec says.
A C compiler or linker can't treat PrintF as printf just because the meaning seems clear enough, and PrintF has not been declared or defined.
> Whereas the eejits who invented HTML have a helluva lot to answer for.
In my original version of the comment I used HTML as an example, but decided to omit that.
The problem wasn't the invention of it (though that doesn't escape criticism) but rather the fact that during early Web history and during the first Browser War era, browsers tried to accept non-conforming HTML and render it anyway. Thus people writing bad HTML had no feedback. The pages looked good with whatever browser they tested with. So browsers had to scramble to reverse engineer and imitate each other's handling of bad HTML as good. The effects of that situation persist; it's not fully resolved.
That will happen with any interchange or storage format, if treated with Postel's principle.
Postel's principle is from the point of view of keeping the internet working, in a situation where messages pass through multiple hosts, which are inaccessible to either the sender or the receiver. If something is rejected due to violating a rule, there is no diagnosis; the symptom looks the same like a severed cable at the bottom of the ocean. It's understandable where that came from.
Postel's principle somewhat applies to intermediary data handlers.
If you're just routing messages, and see a message that you don't understand, then just pass it along.
The principle should be "have as little effect as possible; look at only the parts of data needed to do your job, and don't interpret and act on payloads that don't belong to you; try hard to route rather than drop."
I can't believe we haven't all learnt the lesson of how much of a bad idea this principle is. Has this guy not heard of HTML and quirks mode?