I believe there are domains that are very well encoded. The model very often can know that a shift can't be longer than 11h and if you ask an agent for scheduling software it can surprise the developer by encoding that rule.

Both domain knowledge and coding skills became cheaper.

It might depend on the domain. Highly regulated domains like finance have entire books around how they should work.

However, I agree that verification skills became more important in both areas. A domain expert needs to catch 12h work shifts and experienced programmer needs to catch when the LLM accidentally put a route in a section that doesn't require authentication.

Both require some kind of harness and automatic verifications methods.

Yes, it can consistently generate code that works and seems to be on top of it all due to a lot of training data. But wouldn't that use up more tokens and computational resources to produce than e.g. the same program in python?

If using more complex languages requires more resources from LLM, the same principles apply. One-off scripts are better in high level languages. Hot paths executed millions of times a second are better in lower level languages with high optimisation potential.

LLMs might slightly shift the correct choice towards lower languages. E.g. a small one-off script in C is much more viable with LLM's help. But the moment one needs to reuse it, it grows, and needs to be modified, one might regret not using higher level language.

Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late...

With:

- per process garbage collection

- one BEAM process per request

- short lived HTTP processes

you might never trigger garbage collection, the whole memory is deallocated at the end of requests.

It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language.

This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P)

And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time.

And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.

1. English is not my first language, and Grammarly helps a lot. Small things like correct punctuation and articles make the text much easier to read for native speakers.

2. I try to make communication "modular". There is tension between over-communicating (giving full context) and under-communicating (leaving out details). The first sentence of each paragraph summarizes the point. If you know that stuff already, you can skip. If you are re-reading, you can quickly get up to speed by skimming first sentences. If you are surprised by the first sentence, read the paragraph.

3. I often use numbers so that my recipient can answer or discuss just one point from my text. That usually starts with "Ad2". You can then "split" the discussion by numbering annotations "Ad2.1". If the conversation gets too long and convoluted, we need to add a summary of what we've written. Both Slack and email have flat conversation structure (Slack threads can go one level deep). That flat structure is usually a good thing for someone following the discussion.

It is very natural, and most people reply in the same way instinctively.

Computers usually start from flat pictures, and that trips the learning process.

I have zero data to back it up. Just my hunch :D

For really good companies asking if they test code seems insulting :P

I had a talk where I showed how Elixir and Elm programming languages complement each other and someone in the audience asked what are we using Elixir for in our company. When I said that for payment systems he looked surprised, because he heard about "let it crash" in Elixir and he thought it is unusable for anything critical. That inspired me to talk about how we use Elixir for handling money.

I also answered questions on Stak Overflow for some time. Of course there are many typos or library quirks that are simply missed, but often you see a person that just entirely misunderstood the concept. This is also a target for talks. There might more people struggling with the same thing (especially if your question gets more views).

Pay attention to what surprises people when you are talking with them. If someone didn't know what you find obvious, there is a good chance more people don't know it. We have some kind of bias where we think that what WE know is common knowledge and automatically EVERYONE ELSE is smarter than us (because they know everything we know and some more that we don't). That is obviously not true :)

If you find a topic that surprised couple of people it means you have and idea worth sharing. It doesn't have to be novel! I often put quotes and references from blog posts that I read about given topic to show that this idea is not new at all! Old ideas are often not widely known or forgotten. They are perfect for conferences, because they might be crystalized over years, so it is easy to research them.

Comparing to Ruby: Phoenix promises to be as productive as Rails, but more performant and it keeps the promise if all the libraries you need are already ported to Elixir. Even if not, people consider writing them from scratch.

Comparing to Erlang: Elixir fixes a lot of problems like encoding or inconsistencies in standard library. It introduces many new concepts borrowed from Ruby so it might be a little overwhelming for Erlang developers (Erlang is really small and simple language - the hard part is OTP).

Learning Elixir is like learning to touch type. Initially it slows you down, because you have your habits. You need to learn new abstractions, because old solutions just don't work. After short period you are as productive as before. After a month you can deliver hight quality code quicker which is the ultimate goal of every programmer :) And it magically scales on more machines or at least utilizes all of the cores.

Comments URL: https://news.ycombinator.com/item?id=11566398

Points: 2

# Comments: 0

The internet changed drastically the process of writing books. I saw people making profit from books available online for free. I saw books written chapter by chapter with errors found quickly by first readers. I saw systems that allow commenting parts that are not clear enough with comments how to clarify them.

If you promise to deliver a textbook that teaches skills relevant to engineers, they will fund the time it takes to write the book. I would spare couple of dollars even if you said that it will take 5 years. I believe, there will be even companies that will give you funds upfront. If you reach out for help there will be people who will help you collect example problems from different fields to replace couple of "salt tank problems".

I am not a mathematician, so I don't know how mathematics textbooks are written and how much effort goes into them, so feel free to point out that this idea is stupid.

Comments URL: https://news.ycombinator.com/item?id=10924506

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=10896874

Points: 2

# Comments: 0

That being said. I wouldn't recommend using Go outside of Google, Facebook or Microsoft. It solves problems, that companies and developers usually don't have. If you need always running and quickly evolving software - there is Erlang and Elixir. If you need guarantees on correctness, use static typing from Haskell. If you can resign from some guarantees to have grater control on memory, there is Rust. If you are writing in browser, there is Elm. If you want to easily transition from OO to functional programming - try Scala. If you need to prototype app for your startup quickly - there is Ruby.

Every popular language has its purpose and its trade-offs. Rust isn't strictly better than Go, but with high probability, it is better than Go for your problem.