I wouldn't call myself a person with a mathematical background, but there are those people who believe it's just fine. [0] I don't have enough knowledge to debate that, but it would seem to disprove "basically nobody". Zero is a convention, like NaN or Inf are conventions.
A problem that Gleam has here is that the Erlang runtime does not have NaN or Inf in its float type (or integer type for that matter). It could be represented with an atom, but that would require an atom and a float having the same type in Gleam, which is not something the type system can do (by design). The operator could, in theory, return a Result(Float, DivisionByZeroError), but that would make using it very inconvenient. Thus zero was chosen, and there is an equivalent function in the stdlib that returns a result instead, if you wish to check for division by zero.
> but there are those people who believe it's just fine. [0]
Just fine mathematically, but Hillel does specify that he's not comfortable with the concept from a safety perspective. The whole piece is a defence against a particular type of criticism, but he leaves wide open the question of whether it's a good idea from a PL perspective.
Which part do you feel like would be an issue? When you run `gleam compile`, it will automatically call the Erlang compiler to finish the job.
I find it very handy that the intermediate Erlang (or JS) files are available in the build directory. It lets you easily see what form your code will take when compiled.
I don't think it's the transpile part that would the issue, it's the runtime aspect. If Gleam transpiles to Erlang/Javascript that's great but once you run the program, you have to potentially deal with runtime issues specific to those environments which you might not be familiar with.
It seems that Gleam is really useful for those who are already in either the Erlang/Javascript ecosystem.
On the contrary, it's a great first BEAM language to learn because of it's simplicity - both in terms of the grammar as well as it's tooling/compiler.
For me personally, the Javascript target is the least interesting bit - the BEAM/Erlang target is where it's at for backend work. The BEAM is fascinating and full of ideas that were once ahead-of-their-time but now are really coming into their own with compute performance having caught up.
Gleam is a strongly typed language, and is unapologetically very functional. Error handling in general is quite different than it would be on a normal stack-based language/vm. In my experience, the Erlang target doesn't make debugging any harder or more difficult than you would expect for an exception-less language.
The JS target is also very interesting to me. I like erlang fine and elixir's nascent type system is promising. But the frontend (and js fullstack for that matter) currently does not have a good alternative to typescript, and the ML type system is an especially good fit for it. Elm has too much reputational baggage and rescript/reason/bucklescript/whatever squandered its momentum and is floundering.
But, you need a runtime. If Gleam had its own runtime, that would be another layer in a similar vein. Here Gleam is using Erlang (or a JS runtime) which is bound to be more supported and have a longer lifetime than something they cooked up themselves.
Besides, Gleam's original aim was basically "Erlang but static types", so the choice of Erlang as runtime was always there.
I've always felt that this was a misguided principle, to be avoided when possible. When designing APIs, I think about this principle a lot.
My philosophy is more along the lines of "I will begrudgingly give you enough rope to hang yourself, but I won't give you enough to hang everybody else."
HTML parsing is the modern-ish layer-uplifted example of liberal acceptance.
I won't argue that this hasn't been a disaster for technologists, but there are many arguments that this was core to the success of HTML and consequently the web.
Which, yes, could be considered its own separate disaster, but here we are!
It makes sense in a "costumer obsessed" way. The user agent tries to show content, tries to send requests and receive the response on behalf of the client (costumer), and ceteris paribus it's better for the client if the system works even if there's some small error that can be worked around, right?
but of course this leads to the tragedy of anticommons, too many people have an effective "veto" (every shitty middlebox, every "so easy to use" 30 line library that got waaay to popular now contributes to ossification of the stack.
what's the solution? similarly careless adoption of new protocols? and hoping for the best? maybe putting an emphasis on provable correctness, and if something is not conformant to the relevant standard then not considering it "broken" for the "if it ain't broken don't touch it" principle?
When it comes to writing APIs I feel strongly that you should be incredibly strict.
1 != ‘1’
true != 1
true != ‘true’
undefined != false
undefined != null
etc
“Flexibility” in your API just means you are signing up for a maintenance burden for the lifetime of your API. You will also run into problems because you have to draw the line somewhere and people will be frustrated/confused since your API is “flexible” but not as flexible as they want. Better to draw the line at complete strictness IMHO. I dislike even optional fields and prefer null to be passed instead except special cases (like when null has a meaning, example: search endpoint where you pass the fields you want to search on and a field can have a null value).
I want people to be explicit about what they are doing/fetching when using an API I have written/maintained. It also encourages less sloppy clients
> Postel's Law is also known as the Robustness principle.
Really? It seems like it's obviously just a description of how natural language works.† But in that case, there's an enforcement mechanism (not well understood) that causes everyone to be conservative in what they send.
We can observe, by the natural language 'analogy', that the consequence of following this principle is that you never have backwards compatibility. Otherwise things generally work.
† Notably, it has nothing to do with how math works, making it a strange choice for programming.
You may have strong opinions on anti-cheat software and they may be correct, but it is required for playing certain online multi-player games, and people want to play those games on Linux too (especially the Steam Deck, I would presume). Ergo, people want anti-cheat software on Linux.
Speaking from a purely customer perspective (I'm not a business person or startup founder), the big things that are missing from the landing page and/or signup flow are:
- Pricing. I don't know what this is going to cost me. It does not say if I'm entering a trial period or if it's free.
- Privacy policy. Who are you and what will you do with my data?
Also, I suppose this is a target market thing, but I've never heard of LINE so having it mentioned does not make me more interested. I guess it will work where that app is popular, though.
Thanks a lot! Your feedbacks are so on point and helpful. we will definitely work on the pricing, privacy and TA part.If it's not too much trouble, your signup will be a huge encouragement for us!It’s completely free now!
As a Finn, the most annoying aspect here is the unequal treatment by the government. A PHEV is treated very favourably tax wise, and the emissions calculations are very optimistic about the usage of electric power.
My car is a compressed natural gas car that I drive with 100 % biogas, which is domestic made from waste and other side products of industry, and has an estimated CO2 equivalent emission of ~0 g/km. The tax law and emissions calculations assume that I drive it on natural gas all of the time, never a single kilometer using biogas. Additionally I need to pay an extra fixed tax (not based on kilometers driven) just because it's a CNG car. This tax is 6 times higher than for PHEVs.
Thus, a big SUV like Mitsubishi Outlander, which eats a lot of petrol as soon as you get outside the short EV range and runs its engine anyway when it's cold in the winter, gets to pay less tax (which is specifically based on CO2 emissions) than my biogas car.
PHEVs in my eyes are nothing but greenwashing for most people.
Natural gas and biogas, are they both CH4? I heard they could be way worse than CO2 and leak might be inevitable to distribute them around the country and pumped into cars from time to time? Are there scientific evaluation on the impact?
It's the same stuff. I'm not sure how much of it leaks, but you have to either flare it or use it for something or it leaks anyway. Using it for cars and trucks is basically flaring it but using that energy for propulsion.
The taxes are not based on that, though. They're strictly interested in tailpipe emissions (not even lifecycle emissions), and don't recognise biogas at all.
I'm planning on switching to a BEV eventually, but right now it's not financially possible. Most of the time I commute on my bicycle anyway.
I've run Gleam compiled for the Erlang target using the elixir-desktop project as a "native" Android app. Meaning that the Erlang runtime is packaged with Elixir and the Phoenix framework into an APK. The app runs your code in Phoenix and opens a LiveView frontend that serves as the app's UI.
Right now I'm working on a streaming music client in Gleam that runs as a progressive web app in browsers, desktops, and mobile. It looks just as native as the elixir-desktop app and has integration to the OS media notifications. This is using the JavaScript target.
If you are able to make mobile apps with JavaScript in other ways (Cordova?), then you can take Gleam's JS output and use that in such a system.
If everyone thought like this, I suppose the author wouldn't have felt the need to write the article.
I've been using light themes for some time now, after years of dark mode-ing everything. It actually works better for my eyes, at least where I'm able to set the background to be just a bit off-white. And like the author, when I've pasted screenshots into discussions, I've received jokes about my choice. You know, the gifs about people in dark rooms being blasted with light from their monitor. And ironically jokes about eyes burning, when this is friendlier to my eyes than dark mode was.
My comment was aimed both at the author and the "dark mode lobby" they are complaining about.
Seriously, it's your computer, just use whatever setup you prefer. If someone comments, make fun of them for caring about what you use on your machine.
It's almost as annoying as the fact that nearly every application and website uses light theme by default and often don't even provide a dark theme (Hacker News included).
While I don't discount the possibility of their existence, I've yet to personally encounter an application or web site that only has a dark theme, so the "dark mode only" complaint rings like the perennial "War on Christmas" rant.
The point of the article, which I hope you did in fact read, is that some sites force dark mode on the user, so "just use whatever setup you prefer" doesn't work.
This is particularly hard now when many sites use images of program code in order to get syntactic highlighting, because your page rewriting extensions do nothing.
> The point of the article, which I hope you did in fact read, is that some sites force dark mode on the user
No, it isn't. The article is complaining about people who complain about the author's choice of light mode. Nowhere does it mention any site or application that only supports dark mode.
> The point of the article, which I hope you did in fact read, is that some sites force dark mode on the user
You mean like just about literally every website (except a few that got shit for being 90s-era design) that forced bright backgrounds on users for the better part of 15 years or so before "dark mode" became a thing?
You're not getting it. People don't make fun, they complain about images using light theme, supposedly because it's hard on their eyes, dark mode now considered by many the neutral/inclusive choice. Which is bullshit, especially for people with astigmatism.
Dark mode produces the halation effect in many people that have astigmatism. This varies between individuals, much like the severity scale for astigmatism.
I said that dark mode is not a neutral/inclusive choice, especially for people with astigmatism. If dark mode doesn't affect you, good for you, but the statement is factually correct.
The default post size limit on Mastodon is 500 characters, there is no line limitation. I suppose the message split here is mostly influenced by the user's desire or familiarity carried over from Twitter.
A problem that Gleam has here is that the Erlang runtime does not have NaN or Inf in its float type (or integer type for that matter). It could be represented with an atom, but that would require an atom and a float having the same type in Gleam, which is not something the type system can do (by design). The operator could, in theory, return a Result(Float, DivisionByZeroError), but that would make using it very inconvenient. Thus zero was chosen, and there is an equivalent function in the stdlib that returns a result instead, if you wish to check for division by zero.
[0] https://www.hillelwayne.com/post/divide-by-zero/
reply