Why they call pipes filter? And if... endif? Not for me

This is a Rust port of the Ruby implementation which was popularized by Jekyll, so it just does whatever was done in the Ruby implementation.

For an overview of liquid itself, see https://shopify.github.io/liquid/

Mass of learning material doesn't equal quality though. The amount of poor react code out there is not to underestimate. I feel like llm generated gleam code was way cleaner (after some agentic loops due to syntactic misunderstanding) than ts/react where it's so biased to produce overly verbose slob.

Grepping "extends" over a new codebase is a quick way to see how fucked you are when joining a new project/team.

I literally couldn't care less. You can call it '1th of April' for all that i care if the actual functionality you offer is clean and fast I'll gladly accept!

I get where the author is coming from, but having grown up in the 80's, I always thought "1 item(s)" looked slightly _more_ professional since it followed the way printed documents were usually produced.

> You can choose to use it (macros) or not.

Yet both examples use macros.

I might still got ptsd from a job where literally all of the rust codebase was written as macros. Since then I avoid them at all costs.

I find the route, that gleam took, way more elegant with squirrel (sqlx-ish) and lustre (elm-like) being examples of what we could have instead. Avoiding language mixing is so important for proper/clean lsp-support - yet macros are a different language as i see it.

As for the rest of this: i also don't see how it's any different from iced, egui etc. but maybe I didn't take the time to check the details...

Uh, what? The second DSL example is just pure Rust.

> btn.finish().with_child(pipe!($read(cnt).to_string()))

That second macro isn’t for constructing UI, which is the point of the two examples.

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored it a while back. I'd like to give it another chance some time, but I'm worried that it's like typescript - looks typed on the outside but for many libs and packages the types are just a dynamic/any. Is my fear justified? Beam is amazing btw

I would not entirely compare it to TypeScript. Due to pattern matching, legacy elixir will probably come out roughly 50% typed (extrapolating from my own usage, I'm not sure the accuracy of this number). Then since vanilla elixir is getting types (not a separate TypeElixir) I would venture anything actively maintained will get typed relatively quickly.

I personally do not like type systems, and still code in JS, not TS. Any JS artifacts I produce are untyped. Yet even my Elixir-code is nearly type ready.

So while TS is fighting an uphill battle, I think Elixir is working downhill.

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam

They both ultimately produce BEAM bytecode, but Gleam compiles to Erlang source first (then through the Erlang compiler), while Elixir compiles to Erlang's abstract format. Gleam doesn't prevent OTP use - it has type-safe OTP bindings, but they're less mature/feature-complete than Elixir's, plus Elixir has better BEAM runtime integration (stack traces, profiling tools, etc).

Profiling tools are something that I miss a bit in gleam - yes, but otherwise I had no problems with OTP bindings. The maturity of the ecosystem is a bit lower of course. But I actually enjoy finding libraries or repos with a few hundred lines. You gotta handroll some things but that's what I am here for. ffi to erlang and js for fullstack apps is as straight forward as it gets, but erlang syntax is indeed a bit crazy. For those interested in gleam but don't want to miss some necessities: https://github.com/gleam-lang/awesome-gleam (the gleam community is super nice btw).

For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either.

I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.

When talking about Elixir (or Erlang) you are actually talking about two things that give you the value:

- A language (Elixir/Erlang) and runtime (BEAM) - The concurrency standard library (OTP)

The language and runtime give you the low level concurrency primitives - spawn a process, send a message etc. But to build actual applications, you rarely use those primitives directly - instead you use GenServers and supervisors. That gives yo a way to manage state, turns message passing into function calls, restarts things when they crash etc.

Gleam compiles to the same runtime, but doesn't provide OTP in the same way - static types aren't easy to make work with the freely message passing world of OTP. They are implementing a lot of the same concepts, but that's work that Gleam has to do.

(Elixir provides some thin API wrappers over the Erlang OTP APIs, and then also provides some additional capabilities like Tasks).

No REPL for example.

I mean, it’s not impossible. F# is a compiled, strongly and static typed functional language that also provides a great REPL

Elixir has had types since forever, both primitive and things like structs and shape based destructuring. Then there's Dialyzer and libraries like TypedStruct.

It's never been a wat-language in the style of JavaScript.

gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".

I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.

luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam.

in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.

You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

Then you don't have to worry about mixing up the two :)

no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares.

to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam.

what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it.

what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.

Ah, I see my mistake. Yeah that's definitely the kind of thing that could happen in Gleam.

Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.

Elixir can also compile to JS via Hologram!

Granted, it's alpha software and it's currently embedded in the Hologram framework, but still.

https://hologram.page/

What? Gleam can compile to js. I don't see the similarity to kotlin being oo and all. Gleams compile time is lightyears ahead of anything on the jvm. I appreciate kotlins nullability constraints but to me it seems the jvm ecosystem is too grown to give kotlin the space it needs. Also heared that java's pattern matching and exhaustive checks have surpassed kotlins? In that case it's just easier to role with java, no?

Dunno. Wrote a lot of both. Happy with Kotlin. Grateful Java is being maintained well...

My last team wanted to port all remaining Java code to Kotlin, because they just enjoyed working with it so much more.

While porting I've regularly replaced 5-8 lines of Java with a single line of Kotlin.

Kotlin needs Java like Ruby needs C or Elixir needs Erlang.

Do you have any examples. I don't think I would classify more than a handful posts as political myself

I've noticed a lot of politics creeping into discussions on a bunch of topics. Perhaps it's the fact that I'm not american that makes it a bit more obvious? But every now and then the comments devolve into red v. blue on topics about space, AI, and what not. It's a bit off-putting for those outside the us, but it is what it is. At the end of the day, people will talk about what makes them angry more than about what makes them happy, I guess.

It's really a joyful language. Kind off rusty minus the borrow-checker and the mutability. In it's core it's just pattern-matching and functions/closures as first class citizens. The ecosystem is young and you have to search a bit to find the right tools for the job or the gleam way to do things. I tried it because you can use the same language for Front- and Backend it's biggest Frontend lib called "Lustre" is hyped to be the Elm successor. Anyways gleaming away for 2-3 weeks now and it's the best DX that I ever had - no Beam experience upfront btw.

Dumb question but how is a language rusty without a Borrow Checker? For me it feels like that would be the primary point of being "Rusty".

I guess it's the typing and syntax that feels like writing simple Rust, even though the semantics aren't that similar when you look closer.