Comment by freedomben | Hacker News Reader

Comment by freedomben | Hacker News Reader

> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses: you've created an environment that's optimized for your founding engineers to build something quickly in the first 7 months, but the price is a set of recurring obstacles which your engineers will pay down over the next 7 years.

I've been saying this for years, so it feels really good to the confirmation bias to see it said by someone else!

Though, the language and frameworks definitely matter, but you can easily write short-term-over-long-term code in any language/framework. Founding engineers tend to be the worst as well, because they love and sometimes only ever experienced greenfield development, and they are trying to move fast. That's not a bad thing as without that the startup may die on the vine, but it is something that I wish more founding engineers would be cognisant of, because little things (json schemas, and unit/integration tests for example!) can make a big difference.

Elixir (and Phoenix) really do get the best of both worlds. It's highly productive like Rails, but the built-in way of doing things will give you validations on your data in and there are plenty of tools like Ecto schemas that can be used anywhere and everywhere the data matters. Tests are also first-class citizens and have to be actively ignored to avoid them.

The one area where IMHO the jury is still out is LiveView. It takes a lot of battle-hardened approaches of React, and my initial feelings on it are very good. However I've not yet had a natural organization structure emerge with it, so I'm not sure how maintainable it will be in the future for people that didn't write it. Anybody have experience with that?

> The one area where IMHO the jury is still out is LiveView.

Agree 100%. Unfortunately LiveView is quickly becoming the way of doing things, which I think is ill-advised. It makes the language larger, and is still too much in flux (it's not even v1 yet).

LiveView is great, but it's not perfect and has real drawbacks.

I've been using LiveView since it came out and it has gotten a lot better since then. I ran into some drawbacks early on with authentication, but later versions fixed those issues.

Out of curiosity, what do you see as LiveView's drawbacks with its latest release?

I feel the same way about OO tbh. When everything is just functions + data types it's all much more easy to reason about and maintain.

I have no clue have LV scales. But I have yet to see a React application that doesn't drive me crazy with the amount of indirection and complexity!

Totally agree, when is everything is functions and data, it makes life a lot easier. I especially find it useful when refactoring code while trying to keep an existing function signature.

>> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses

If you know exactly what you are building, down to the datatypes, sure, use static typing. But 99% of startups aren't like that. Business development is a highly dynamic process.

Once you hit $1M revenue, rewrite it in Rust or whatever.

This is unironically my plan/playbook with ideas I have for startups. Start with Python, node, or whatever. Then go to Rust once product-market fit has been established.

Rust really hits that sweet spot with memory-management, programming paradigm flexibility, and speed. It’s precisely great for what I need because it’s essentially an ML with good imperative constructs.

> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses...

I don't know. Every startup I've ever worked at has used a dynamic language and most of them have been successful.

I know many disagree with me, but I've used a lot of typed languages (Swift, Typescript, C#, Java, etc.) and a lot of dynamic languages (Python, Ruby, Elixir, etc.) in my 30+ year career and I'm still not convinced that typed vs. dynamic is as big a deal as some make it out to be.

does elixir have type checking like typescript does ?( you can add types ?)

The hottest news in the Elixir community is that it is currently experimenting with set theoretic type / gradual typing. Some french PHD is working on it.

It is past the RND phase and in development at the moment.

It is highly experimental and not guaranteed to ship with the next version of Elixir. Right now the idea is to see if it offers any value in the first place. There are a lot of statements about what types offer. What the Elixir team wants to do is actually experiment to see if there's a benefit. Which is a really neat thing for a lang to do...to actually experiment like that is incredible.

As for right now, in a sense yes. It has this thing called Dialyzer - https://www.erlang.org/doc/apps/dialyzer/dialyzer_chapter.ht... which is a static analysis tool. This offers some non runtime type guarantees. But it is still a dynamically typed language. And the community is split on it IME. The errors are cryptic and there are some other issues. There's also Norm.

There are some things you can do to guarantee types during runtime, like match a function to a type. So when called with a string the implementation is different than with a boolean. So there are some run time type guarantees.

example of matching (return a diff string if bool or if nil):

def do_thing(n) when is_bool(n): "some boolean"

def do_thing(n) when is_nil(n): "nil"

There's also the concept of a struct which is like a typed object / map / key value pair thing.

To show the struct example:

    def do_thing(%Foo{} = foo), do: foo

Here `foo` has to be type of struct `%Foo{}`.

    def do_thing(%Foo{bar: "baz"} = foo), do: foo

Here `foo` has to be struct `%Foo{}` with field `:bar` with the value of `"baz"`.

Another one I like to point out is how operators aren't rampantly overloaded.

    def add(a, b), do: a + b

This will _only_ work with floats or integers because `+` only works on those types. String concatenation, adding lists, date math, etc have their own operators/functions.

While Elixir does offer mechanisms to overload operators, you have to be very explicit about it. There is no way to globally redefine `+`, for example. It would be on a per-module or even per-function basis (and not something that is done too often, though there are some good uses of it out there).

Dynamic typing in Elixir really isn't that big a hinderance if you stick to its idioms. That said, I'm fairly excited about the prospect of the type system.

> The hottest news in the Elixir community is that it is currently experimenting with set theoretic type / gradual typing. Some french PHD is working on it

To expand on it: you can read the proposal[0] or watch the video presentation by the author[1].

It is a very similar system to Typescript, with (at the first glance) only minor differences: "any" becomes "term", primitive constants are not singleton types (so you cannot write programs with type system alone... yet), and I expect some edge cases around generics will be handled differently (especially since you cannot specify types yourself in function calls, i.e there is no myFunction<MyType1, MyType2>()).

On the other side, there are some things that the proposal seems to be doing better than Typescript. It handles type assertions without the need for "function isX(maybeX): asserts maybeX is X { ... }" and since pattern matching plays important role in Elixir, I expect it will have a lot of polish around that.

[0] https://arxiv.org/pdf/2306.06391.pdf

[1] https://youtu.be/gJJH7a2J9O8

No and sort of. While Elixir doesn't currently have types (though I understand that is coming), you can use Dialyzer to type things. It kind of sucks, though, so every project I've worked on except one has eventually turned Dialyzer off.

Pattern matching and guard clauses go a long way to ensure your types are correct, so most of the projects I've worked on have relied instead on those.

Reply on news.ycombinator.com