Colons separating key and value pairs enhance readability in my book, so KDL goes too far for me. Other options are JSON5 (https://json5.org/) and CUE (https://cuelang.org/docs/introduction/). The latter is maximalist rather than minimalist, but very well thought out and worth checking out.
Really it's quite logical that the next iteration of these configuration languages be this style, remove superfluous and annoying quotes, handle comments and maybe allow trailing commas.
It seems to me that the point of the article is that "all the demand" is not just for C++, C, Java, Typescript, Python, etc. There is increasing demand from larger companies for Rust.
No one is forcing you to learn Rust. You don't have to bring yourself spend time learning it. You can keep writing those other languages.
Those languages have been around for a while and they'll continue to be around for a while more. Rust is just getting some time on that stage as well now.
I think some dyed in the wool programmers are not afraid to learn something new but from experience see some nightmarish patterns in rust (e.g. c++ style templates for generics, phantom) and also watch less experienced programmers/architecture astronauts successfully argue to move things to rust without considering the future pain and are legitimately worried about being eventually forced to use it. Doesn't help that e.g. government is now saying "don't use memory unsafe languages".
I learned C++ first and Rust only within the past couple years, and I'd never willingly choose write a project in C++ again with the option to use Rust instead. Generics can get messy and the phantom data is indeed awkward, the difference to me is that in Rust if you go wrong the compiler most often can highlight the exact issue and suggest accurately how to fix it. My experience with C++ is that the compiler errors tend towards being so incomprehensible they sometimes felt intentionally misleading. The Rust compiler enforces correctness to a degree that gives me significantly more confidence in the programs I write; C++ is a major improvement on C here but still gives you so many ways to shoot yourself in the foot that would just not compile in a Rust project.
I haven't actually, glad to hear it! I still see big advantages to the extra compile time safety provided by Rust, and despite the mentioned similarities I find its syntax significantly clearer to read and write. C++ templates took me forever to really wrap my head around where a similar declaration in Rust feels immediately intuitive even where I don't fully understand all the nuances.
Almost ten years ago I was really excited about rust, but the sort of thing you describe has really put me off. It's become 'C++ but with better guarantees', whereas I liked it for being 'python ergonomics with stricter correctness' or something.
I really think there's room for a language more focussed on (sacrificing a bit for) usability/readability/DX - rust has great features like doc tests, in-module tests, structural pattern matching, macros, traits, .. but<some<of<the<container<crap, 'that>, ends<up, necessary>>>>> really ruins it for me. And on the one hand yes it is trivial, it is just syntax. But I do think it matters?
(It's late, I'm tired, not a very well formed thought, but coincidentally I was daydreaming about designing a language earlier today, so here we are.)
A compositional type is just a consequence of having a good type system. It means that you can slice your requirements into multiple independent types because they are individually describable in the type system. The converse is not true, which is why C++ also seems to have a compositional type. (C++ doesn't really have a true compositional type; C++ templates have no such guarantees, and thus even harder to use than true compositional types.)
Non-Apple development keeps getting better. It’s a very easy to read language with lots of safety, strong types,good standard library, await, and tons of users (thanks to Apple). Integrates easily with C/C++/Obj-C/Obj-C++, or anything else that can do C interop. Just gained neat macros and tests.
It’s probably my current “if I could pick anything” language.
On top of all the rest, it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
Ladybird browser decided to use Swift of all things. I am just confused on how can one use a ARC based language for extreme performance software like a browser . Don't you need manual memory control or custom memory paradigms like arenas ?
Nice, but like the extinct Dodo, these are all affectionate memorials to dead software. The web browser is still alive and kicking after 30 years. And is the world's most popular software application. And all the mainstream browsers are mostly written in C++. Even the massively hyped Servo never got adopted into Firefox.
Swift has always been designed with the potential for more manual memory control. Recently, non-copyable types were introduced, and non-escapable types are currently being proposed. Additionally, more ownership control features are being added. While there is still much work to be done, progress is steady.
> it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
I mean, maybe at a surface level. But under the covers with stuff like existential containers, opaque types, boxed types, ARC, etc it's a lot more complicated
Maybe the syntax "looks" modern like python but writing in it feels like smart pointer C++ with more safety features built in
Personally I'd rather just use C++ with a strict style guide, fewer new semantics to relearn
It's also funny that apple presents it as a "beginner friendly" language. Maybe it's possible for people to write in it without getting too far in the weeds, but like C++ it feels like a kitchen sink
Maybe all languages are like this to some degree, where there's a big gap between being proficient enough to write something and knowing it well enough to write something properly. It feels like Swift has a low barrier of entry but doing things properly has a much higher learning curve
Do you expect people to become expert rust programmers over night? I have 15 years of c++ under my belt and only recently got the chance to do some rust. Of course some of my rust code is going to look like c++ until I get some practice, some code review criticism, and personal study in. I’m here for the journey, and I am enjoying rust’s perks and mostly less mental overhead.
Rust superficially looks like C++ to avoid looking weird to existing C/C++ programmers, but semantically it's quite far from C++. Rust's generics are not like C++ templates: they're only type based, and don't use syntax-based matching, don't have tricks like SFINAE. ODR is guaranteed by construction. Trait lookup is simpler: there's no overloading, no inheritance, no implicit conversions, and interaction with namespaces is simple (ambiguity is an error).
Phantom type looks alien if you haven't used it, but for what it does, it's actually a pretty simple. It's there to explain in Rust's terms what an opaque type or a foreign C/C++ type does. You just need to give Rust an example of an equivalent type, and you get a correct as-if behavior, and you don't need to even know that you've just configured type's variance and destruction order checking.
Fair enough. I have personally experienced pain with phantoms.
But then what would you advice to do ? There are nightmare patterns in rust and c++. Looks to me as pick your poison just that one is new and other has been around for fair bit.
I am sorry. I really don't see your point. Typescript is in a completely different league of languages than rust/c/c++ with vastly different use cases.
Also, the world still mostly speaks C99 when iterative improvements are constantly being made up to C23.
The point is that Typescript was able to replace JavaScript by adding to it. Converting a codebase from js to ts was simple. Going from C++ to Rust is not.
I think C23 is going in the right direction, but it needs to go further.
There's always demand, but at what cost? Mixing languages sucks. Rewriting stuff is not always an option. New projects could use Rust, but will you be able to get the head count? There are whole armies of skilled C++ devs, but only a small group of competent Rust devs. This is the exact same problem Kotlin ran in to.
It is great that the ecosystem is growing, but there is still time for things to trickle down.
As college student I have invested time into rust because I see value in the language but there are absolutely zero entry level jobs or internships. To get my foot in, my only real options are C/C++.
a few years ago there was a big thrust here for haskell. and now it has all but gone. i do get a feeling that the same will happen with rust - but we will see.
I always had the impression that Haskell was primarily an academic language. Not that you can't use it for practical things, but a bit different in purpose compared to Rust.
That's the most constructive takeaway you have when looking at all their work? That's an unnecessarily limited view and doesn't add to the conversation.
From my vantage point their work fits the definition nicely.
"A collective body" [1]
...
"Collectivized or characterized by collectivism" [1]
...
"A political or economic theory advocating collective control especially over production and distribution" [2]
I wouldn't say it's a completely throwaway dis. As much as I like Orca it easily could be that calling themselves "a collective" is putting on airs or pretending to be a bigger movement than they are. But it could also be tongue-in-cheek, self-parody, or theater of the absurd (which seems more likely).
In truth, that's exactly what it is. My point in writing this wasn't to say "Ooh, look at Rust being so much better". The original PHP is wonderful and there is definitely something lost in a Rust translation. Other things gained as well. ¯\_(ツ)_/¯
This blog post is just a personal journey winding through the thought process it took to replicate that PHP in Rust, something I did because I thought I might learn something.
I think Gary Bernhardt's corresponding Boundaries conference talk [1] is quite good, particularly because of how pragmatic he is in introducing the topic.
I have been thinking about and trying to work with this paradigm for a few years now. To be honest, it's been a struggle. Partly because it requires unlearning some habits and partly because there's limited opportunity to practice in my $DAYJOB where I'm working in codebases heavily invested in other paradigms.
I've seen and read many, many videos, blog posts, etc. on this topic. Everyone loves to introduce the concept with a contrived example and then stop there. What I would love to see more of are complete examples for everything from simple to complex applications.
I think there's potentially a lot of value in thinking this way (or at least taking as much from it as you can), but it's hard to learn and then to teach others without more examples to draw on.
I've used this for many real applications that I would characterise as small (biggest being ~10KLOC excluding tests, types, etc.). I've applied the pattern across entire codebases and to specific components within much larger codebases which follow other patterns. I tend to combine it with some of the ideas in Mitchell Hashimoto's talk Advanced Testing with Go[0] - particularly small interfaces and defining test stubs alongside real implementations.
In practice my imperative shell tends to have two layers. The inner layer is responsible for executing the imperative logic, while the outer layer is responsible for initialising configuration and dependencies, invoking the inner layer, and adhering to any sort of external interface that it may need to satisfy. Everything from the inner layer down through the functional core can be comprehensively tested using stub objects only -- no need to patch anything.
Unfortunately everything I've applied this pattern to is proprietary, so I can't share any code examples.
I also did it for a Go app recently exactly like that.
It was mostly about putting the "imperative" part closer to main.go and putting business rules and things like that in the other files: Routing, serialization, validation, business rules, data transformation, command line argument parsing, configuration parsing, they all go in the "functional" part. Instantiating the HTTP server, reading argv, files and reading/writing to the database goes in the "imperative" part.
The major hurdle for me is frameworks and libraries that often want to be used in an imperative way. Some routers, for, instance could be purely functional, but they often want to instantiate the HTTP server themselves. Not a big issue in practice in Golang, though.
Also: the database. To keep purity in a simple way, you gotta wrap the imperative parts and use callback-ish structures. This part is often where I cheat. But with a proper abstraction it's great. I hate to say the forbidden word here, but a "monadic" abstraction you can have your cake and eat it. I never did it in Golang and I have no idea whether it would work, but, I did it in C# and it was a breeze.
I agree with your assessment about testing. In the end it was incredibly easy for me to get 100% coverage on the functional part.
If you're familiar with Node.js promises, you already know how it works. I just pass a hollow "DB" object to my controllers that can perform queries and commands, but instead of returning data imperatively, I use JS-like "promises" to chain the next steps. On the "success" callback you have the result of queries. At the end I will just return this "chain of statements" that wasn't executed yet. I only really run everything at the "imperative" layer, within a database transaction.
That's also similar to how Haskell IO works. If you desugar the "do" syntax, you get something like this. Of course I said "monadic" between quotes above because it doesn't follow the functor/monad laws, it's just a Fluent interface promise-thing tailor-made for that very small app.
A big issue is that this was in very small project. Promises are not exactly pretty, and the code is not the easiest to maintain if you don't know how they work, which is why I "cheated" on the Golang app. I think someone else smarter might be able to figure this problem out too, though :)
