I really want to choose Phoenix, but I can't get over the fact that LiveView is front-and-center. The whole web-socket model just seems so brittle to me.
Oh ok. Is it still worth learning without LiveView? E.g. in my case I’m much more proficient in Python. Is it worth the jump, over something like Django?
In every language there are sharp edges or dirty corners that are just annoying once you hit them. JavaScript and Php are full of inconsistencies, Ruby and Python are nice and the surface but once you dive into meta programming, OOP and mutability complex code bases are just impossible to trust/reason about their correctness. Rust, C++, C#, F#, Java... I could go on.
In my opinion Elixir just hits the sweet spot of good design. After multiple years using it there comes nothing to my mind that I find ugly or annoying.
Sure there are other languages that are quiet nice on paper but often they lack the ecosystem to let you just build production ready stuff.
The Elixir ecosystem is also not that large, but large enough for quickly building a web app or composing useful automation pipelines.
Definitely, Phoenix is way more streamlined than Django/Rails. Even if you jump to other language/framework, it'll teach a lot how to built stuff due to good defaults and project structure. Also simpler too. I remember spending hours trying to figure out how to use specific method and where is it coming from in Rails. In Elixir/Phoenix there's very few "import"s in use (single file you can inspect and modify), non hidden state. You see Foo.bar("some argument") and you know you don't need anything else to understand what it does. Rails is very magical in this sense, Django as well, a bit
I liked this post, and I can totally understand where you’re coming from…
But couldn’t anything you say about Lua also be said about JS? You mentioned how Lua wasn’t batteries included, so you try to limit your libraries. Couldn’t you say the same for JS? JS itself doesn’t change much, it’s the ecosystem. Couldn’t you just pick out some small and stable libraries the same way you could with Lua?
For me, it isn't 100% language warts. It is the customer experience that matters the most for me. Can I compile and ship my products to my customers without having them to install a VMs, container runtime or a language runtime? That the question that is critical for me.
I agree, I think that you must really like golang and how easy it can make cross compilation and how fast it is to build.
Golang has one of the best developer experiences and there are only very very few minor nitpicks I might have of the language but the whole ecosystem on packaging software and what not is just so easy and I love golang.
I love JS, don't get me wrong, I absolutelly love Javascript. But I love the JS that the browser runs and understands. I hate the current ecosystem of bundlers, transpilers, typescript, npm modules and so on.
Yes, I could have picked a js runtime and done the same thing. The same thing could also have been done with literally any other language.
It is less of a "Only Lua Can Do This" situation and more of a "I Like Working with Lua" situation.
I'm working on a notes app that is as simple as Apple notes, but has native markdown support and uses semantic search.
Uses SwiftUI for the UI, and Zig does most of the heavy lifting on the backend. It's inspired by ghostty which uses a similar setup[1].
Right now it only works for Mac, but I'll be porting to iOS as soon as I get the markdown renderer polished. It's not available to the public yet, but I'm using it as my daily driver and hope to release it later this year. I've open sourced it so you can see the source code here[2].
Spent some time on this a few years back and have a half-finished project for it. The thing that proved to be a huge roadblock was importing existing archives since many don't provide a good interface to it.
The https://lore.kernel.org site is actually fairly decent, but limited to Linux kernel stuff and some adjacent projects. Gmane was quite nice too, but now defunct (the web UI anyway).
It hasn't been done, because it's impossible. You might get the first 80%, maybe even the first 90% if you had enough money to hire top designers for several years, but you'll never reach Slack level polish.
Switched to Helix about a year ago and haven't looked back since. Has almost everything I need in it(with a few exceptions). With Vim I would've had to have installed some janky plugins.
I really recommend it if you find Vim motions unintuitive and want some of the basic features of IDEs like VSCode.
My biggest gripes:
- No plugin system (yet).
- Configuration documentation is not the best.
- Hasn't reached enough popularity to where other apps have "Helix mode" like how a bunch of apps have "vim mode". I find myself wanting to do Helix motions in other apps.
Came here to say this. I was able to get an omz featureset from vanilla zsh with a handful of lines of config. It works for the features I was using from omz.
Followup question: what’s it like to write COBOL? It’s so ancient as this point you never hear anyone actually talking about what the developer experience is like. How performant is it? What features does it have (or not have)? How bad is it really?
Effect system allows programmers to annotate expressions that can have certain effects, just like the type system annotating type information on them, so compilers can enforce effect rules just like enforcing type rules.
For example for a type system,
let a: Int // this says 'a' has the type Int
a = 5 // compiler allows, as both 'a' and 5 are of Int.
a = 5.1 // disallowed, as 'a' and 5.1 are of different types.
Similarly for example for an effect system,
let a: Int
let b: Int!Div0 // 'b' is of type Int and the Div0 effect.
let c: Int
...
a = 1 / c // disallowed, as '/' causes the Div0 effect which 'a' not supported
b = 1 / c // allowed, as both '/' and 'b' support the Div0 effect.
The effect annotations can be applied to a function just like the type annotations. Callers of the function need to anticipate (or handle) the effect. E.g. let's say the above code is wrapped in a function 'compute1(..) Int!Div0', a caller calling it can do.
compute1(..) on effect(Div0) {
// handle the Div0 effect.
}
The book uses Scala & ZIO but intends to be more about the concepts of Effects than the actual implementation. I'd love to do a Flix version of the book at some point. But first we are working on the TypeScript Effect version.
It looks like "effect" as in impure functions in a functional language? I.e. a new way of dealing with effects (global/hidden state mutations) in a language that makes the pure-impure distinction. I'm not entirely sure.
I thought it was going to be something like contracts or dependent types or something.
No. It is essentially resumable exceptions. You throw an exception saying “I need a MyAlgebraicType” and the effect handler catches the exception, generates the value, and returns execution to the place the exception was called from.
But entirely definable in user code, so an effect is essentially a set of possibly impure operations you can perform (like I/O or exception throwing), and a function that exhibits that effect has access to those operations. Of course the call sites then also exhibit that effect, unless they provide implementations of the effect operations.
My thing is that most UIs use such poor use of the screen real estate. I get it, pretty is the priority. But when I want to do work, the padding on everything gets to be excessive. Additionally, it’s really nice to be able to host my dotfiles in GitHub and I can be in a 100% familiar environment within a couple minutes. I have a variety of machines I work on. Same thing goes for mouse usage. I’m much faster operating the keyboard, whereas I switch between mice and trackpads and sensitivities when I switch devices. Keyboards are mostly the same. Maybe it’s a skill issue on my part but oh well ;)
My issue with the terminal is the exact opposite, everything is monospaced, hard to read, and space-inefficient due to that. Keyboard use is not a terminal-only thing either, it's a problem with some modern UIs that are hostile to power users. I feel it's at least partly because power users that create their own tools removed themselves from serious GUI development and are too busy with fancy TUI doodads and dark themes instead.
I feel like the point of monospace is to be easier to read in text dense environments. I find it much easier to read a monospaced font in the terminal and it makes editing commands much nicer to work with.
The point of monospace is easy vertical alignment in code, tables, logs, and many other types of text. But you definitely lose fast visual shape acquisition and potential density of proportional fonts. CLI is fine conceptually, I'm talking about TUI which is different.
reply