-
Speaking as somebody who bought in to the Elixir hype early on and who has now been using it in anger, at scale, for over a year…
…releases solve problems that people don’t actually have. Real issues I think the Elixir core team is unaware of or actually ignoring:
- Reproducible builds aren’t actually that important for most web apps beyond what mixfiles already support
- Hot-upgrading of code doesn’t always work anyways, and just kicking over the server is the time-honored way of solving that in the web dev world. You’ve got multiple servers and do cutover deploys anyways, right? Right?
- The “blessed” way of using distillery/exrm involves an intermediate build step, where you pack up and maybe copy around your build between systems. This is slow, and moving around a 100MB tarball is not a great look.
- Running
git checkout production && mix deps.get && MIX_ENV=prod mix phx.serveractually works, and is relatively fast. - The tooling for the remote console is possible without their elaborate build setup, I believe.
I enjoy the language, but the community seems to be really fond of overengineering.
EDIT:
Just to be clear: Erlang and all are great systems, especially for embedded or slow-change stuff. For web work, though, where you have a lot of change happening, you want to be able to do things quickly, and sitting on your hands while a deploy chugs is not a good use of developer time.
Also, the compile time for a moderately-sized Phoenix project is garbage. >:(
EDIT2:
Also Phoenix picking brunch over webpack is slow and not good for real apps. >:(
-
It isn’t over-engineering when the engineering (OTP releases) is already done :)
What is the intermediate step of copying around a 100MB tarball you are referring to? You get a much smaller install with a release because it doesn’t include all of Erlang and Elixir, only the libraries necessary for running. Docker images for 2 different Erlang projects i have are 16MB and 30MB.
Outside of a docker image those tarballs provide the same ease of deployment and size as a Go binary.
-
I don’t need a bulldozer to dig a sandcastle, even if we already know how to make bulldozers. :)
It’s possible our release pipeline is a bit goofed up (it’s inherited, and other folks on the team are v. committed to the “Elixir Way” of doing things, regardless of how much more annoying it is), but if you keep the server version of Erlang/Elixir in sync you don’t even have to ship a release–much less deal with the clowncar of docker.
Then again, I think most devs just don’t want to think about ops and don’t want to spend time properly caring for and feeding servers!
EDIT: And to be clear–I’m not saying you’re doing anything wrong…if it works for you, it works. It just doesn’t work for us, and it’s a constant thorn in my side.
-
Oh, meant to say you are right about hot-upgrading. It is mostly a waste of time. Few use it and even fewer need it. It is great if you need it. With environments like kubernetes catching on it will likely be misused less.
And you don’t have to include erts in the release, it just makes deployment simpler.
It is true some will always prefer source checkout, build, run. And that will be fine for a hell of a lot of projects. But I still think releases provide an (ultimately) easier and more consistent deployment artifact.
The issue is the tooling needs to make getting to that artifact simpler. I hope this effort makes that the case :). It was my goal with rebar3 and it integrating relx instead of relying on reltool, and with this new push from bitwalker and the core Elixir team may be we’ll end up with some improvements to OTP as well.
-
-
-
Ill add you had more details about perceived failings in this comment which I found interesting.
-
tristan
6 months ago
|
link
| on:
Partisan is a flexible, TCP-based membership system for Erlang/Elixir
The relevant paper https://arxiv.org/abs/1802.02652
-
chadski
12 months ago
|
link
| on:
Efficient, cross-actor distributed transactions in Microsoft Orleans
I was curious how this differs from Erlang, and it looks as though they wrote a blog post addressing that very question! Project Orleans: Different Than Erlang, Designed for a Broad Group of Developers
-
Yup, it has a lot of unique features that are not available in Erlang. We are working on a framework inspired by Orleans for Erlang https://github.com/spacetime-iot/erleans
-
-
jimdigriz
1 year ago
|
link
| on:
Install and Monitor Erlang Releases in Kubernetes with Helm + Prometheus
…this is not about erlang. :-(
-
-
Purely for awareness, I’d like to highlight that this undated blog post is quite old; I believe I first saw this at least two years ago.
With that in mind, some of the advice and practises presented may be out of date.
The proposed recommended installation through brew (on OSX of course) isn’t the best in my experience since it tends to lag behind the downloadable packages from golang.org, for example, and GOPATH now has a default for a new install.
To get started with an installation, I recommend the official docs: https://golang.org/doc/install
Followed by : https://golang.org/doc/code.html#Workspaces
-
The proposed recommended installation through brew (on OSX of course) isn’t the best in my experience since it tends to lag behind the downloadable packages from golang.org, for example, and GOPATH now has a default for a new install.
Using Brew since Go 1.3, never had any issue. In fact it’s the smoothest and easiest way to install and update the Go.
-
It’s true that it’s no longer necessary to set a GOPATH, but I don’t know where this FUD about Go via Homebrew got started. It remains the easiest way to install Go on Mac, is reliably updated within an hour or two of official releases, and has no substantial differences from installing from source.
-
“is reliably updated within an hour or two of official releases”
This simply is not true.
-
Correcting myself on this point. based on the latest release:
https://blog.golang.org/go1.8 - Feb 16th
-
This has reliably been true for the last 2 or 3 releases. Prior to that, I don’t recall.
-
Thank you. For what it’s worth, your article was very helpful to me when I first read it and was a new Gopher. :-)
-
-
-
-
Please feel free to send a PR with minor changes on https://github.com/howistart/howistart-hakyll/blob/master/posts/go/1/index.md. As long as @peterbourgon (or the respective author of the original post) signs off on them I merge them.
I really do need to get he date into the actual page… I’ll try to remember to do that today finally.
-
-
You don’t need to make a call to a process to read a from an ETS table like this. The
getshould just read directly from the ETS table. You’ll also want to setread_concurrencyto true when creating the table.You can also write to the ets table concurrently, but here the important one is to not send all reads from the cache through the same process.
-
I hope one day Haskell community will realize that while better than the previous solution it is still a bad solution. This is the usual set of bad examples that make Haskell IO looks sensible until someone starts working on a real program (with user output, configuration files, http requests, database requests, logging) and discover now they are dealing with transforms and lifting and want to tear their hair out.
-
-
Hmm, do you go over that in your book? I’ll have to finally purchase and dig in :)
I continually end up on haskell for writing certain types of apps (like cli tools or simple websites) because of the available libraries and stack – Ocaml just doesn’t have the quality of libraries for stuff like AWS or as good a build tool as stack and Erlang isn’t a fit for a lot of that work. But become frustrated with transforms and start dreaming of a haskell like language that isn’t pure :)
-
Hmm, do you go over that in your book? I’ll have to finally purchase and dig in :)
The book isn’t modular, you’d need to do at least half the book to be able to digest the monad transformers chapter. We only cover part of the point I made here, but it shouldn’t be hard to infer how to avoid making this mistake.
Lose purity and you lose almost everything that made it distinctly worthwhile. Even laziness (which is important) is optional compared to that.
-
Lose purity and you lose almost everything that made it distinctly worthwhile. Even laziness (which is important) is optional compared to that.
For some, sure. I just want a staticly typed functional language that compiles to a native binary and has good development tooling :). Haskell and ocaml each fit in there but each have their own distinct issues that can frustrate me. And then Rust, would like a function language with GC that can interop with Rust as an option.
-
-
-
-
-
-
Oh boy. “Phoenix on Elixir”. As much as I love Elixir/Erlang/BEAM, it seems inevitable for the language and ecosystem to get stampeded by hyped-up Rails/web developers who think of both as the same thing. Oh well, more users means more chances of getting an Elixir job.
The article never defined what a “modern app” is and how Phoenix makes it easier compared to Rails (which has web sockets). That said, Phoenix has the BEAM behind it and is not a majestic monolith—with umbrella applications, it can just act as your web server and have little to no business logic, so it can make large web applications easier to manage.
-
This is valid criticism. My main focus was trying to find the parts in Rails that can be easily “translated” into Phoenix and explain those parts. I didn’t write much about BEAM and umbrella applications because there really isn’t an equivalent in Rails.
-
-
No worries. I enjoy honest criticism, it helps me improve. This is my first blog post of this size, so I have plenty to learn still.
-
-
Not really at all. I’m trying to think of any similarities but I’m currently failing; they’re closer to a package of packages. I’ll go through some reasoning:
A Django app is a framework construct, Elixir Umbrella’s are more core to the language itself. Every build of Elixir ships with Mix, a build tool which is capable of creating new Elixir projects. An Umbrella project is simply a root level Elixir project that contains one or more Elixir projects “under its wings”. Each Elixir project keeps it’s own dependencies, version, docs, start-up list, build, test suite, etc. Basically it lets you have a de-coupled per-app isolated layout while keeping the advantages that a single repo can give. Each app within the umbrella is individually deployable.
In Django, it’s quite awkward to create a 3rd-party package that runs alongside your actual project while you’re developing it. Sure it’s possible, but with Python Path and module importing issues - it tends not to happen and you end up syncing with some git remote. This problem is solved with Umbrella projects because you simply create a new Elixir project within your umbrella and list the new project as an “in umbrella” dependency to your existing project; this means that when you’re finished with development and ready to open source on Hex - all you have to do is publish it and change the dependency of your original application to point to Hex instead. And if you never finish it? It can just stay there running as it’s own self-contained app. It reduces the friction completely.
A Django app tends to be tightly related to a set of models and specific Django patterns. An Umbrella project is not really constrained by anything other than the standard layout of an Elixir project - which is defined by the Mix tool in every project anyway. There is no linking it with a set of data and it doesn’t take on any special extras when used with say Phoenix - it’s just a Mix project at the end of day, and any Elixir project can be one.
To end with an example: a common pattern I take when using Phoenix is to start with an Elixir Umbrella app, and then immediately create 2 sub apps: one that contains my business logic and data stores, and the other that deals with interfacing with the web with Phoenix as a dependency. Having the separate apps helps me enforce the separation by providing a clear isolation line, and also means that I’m not glued to Phoenix. Also, while they do have separate things, if I run commands from the root Umbrella, they tend to get run on both - the integration is very nice there.
Edit: I deliberately stayed away from OTP because I think the acronym can be off putting to newcomers but for simplicities sake, 1 Elixir project == 1 OTP app.
-
-
-
-
-
I haven’t used Rails Engines in a while so I completely forgot about them. I know they can be used for similar purposes but if I recall correctly they almost become a part of the Rails monolith instead of being treated as a separate application as in Elixir. I could be wrong though.
-
-
-
I just noticed that the title kind of suggests that the name of the framework is “Phoenix on Elixir”, which was not the intention. Sorry about that.
-
-
Say what you will about ESR, but the guy generally isn’t regarded as ignorant when it comes to programming.
My key take aways from this are the following:
- A language with a library to handle basic things you get with C from Unix, such as
select(2)or epoll support is much more superior to a language which outsources it to, even if well done, an external repository. The reasons for this being the lack of clear support into the future (10 year plan), and lack of clear choice amongst a swath of similar libraries. - Rust is still hard to learn because the documentation isn’t clear, or focuses on the wrong thing.
I must say, I have experienced frustration with 1 in languages other than Rust. OCaml and Lua both suffer from this, for sure. And, even with Rust, a couple of months ago, there wasn’t a clear HTTP client I should be using. I didn’t pursue a project because of (my perceived) friction – I used Go instead.
I haven’t, however, found 2 to be true. Now, I won’t claim that Rust is trivial to pick up, at least not in comparison to someone with a C background picking up Go. But, I certainly didn’t have trouble building a few small >100 line toys after a little bit of reading, admittedly some hands on frustration, and compiler error searches. Luckily, all of the compiler error searches I encountered were extremely easy to search for, and it cleared everything up quite quickly.
All this being said, I want to adopt Rust over Go, because I prefer the philosophy, but between work, which is a large Go code base, and home projects (a mix of Python, Racket, C, Go), I simply haven’t found the motivation to dive into it. Maybe there is actually something to
2…-
Wait, why do you say he’s not generally regarded as ignorant in programming? His primary technological reputation comes from text files he took over updates for, and essays on culture. His code is not good.
-
-
Now, I grant I haven’t looked at the code
Well wait, then why do you have a strong opinion on the subject? Why in fact would you have any opinion at all?
The existence of the fact that programmer maturity is possible in three decades does not mean it happened. I’ve looked at the code. He attempted to reimplement the 64 bit integer data type by hand in ntpsec and failed. I have junior devs working for me who, if 64 bit integer types weren’t already a standard on every platform for the last 17 years, would create bug-free (re-)implementations every time. In fact, I can’t remember having a dev working for me in the past 26 years that would struggle with it. Of course, every dev in the last 17 years would look at me like I was an idiot – which is the other part of the problem.
-
-
-
fetchmail (which was initially developed by Carl Harris) is not an example of good coding or good design - in fact, it’s quite the opposite. It can quite easily lose mail in cases where it shouldn’t.
See, for example some of the comments on the getmail FAQ. Yes, I know that getmail is a “competitor”, but those are fairly damning. And don’t forget this - “As to fetchmail: it is an abomination before God”.
Matthew Garrett (who I know has his own axe to grind with ESR), has posted some negative comments about the quality of his software. See this tweet for example.
-
-
-
-
-
-
I have some philosophical issues with some of his edicts (particularly ‘silence is golden’ which I think is the biggest train wreck EVER in just about every way I can think of) but you can’t deny that he’s produced several bodies of code used by a heck of a lot of people.
Can’t honestly say I’m his biggest fan, but credit where credit is due.
-
-
The Rust community looks to be settling on https://crates.io/crates/tokio for the select/epoll use case. His other argument is a little more understandable. And there is no denying that for the task of writing a simple IRC server Go is going to get you up and running faster than Rust. However for something like NTPSec I’d argue that the extra safety Rust gives you is worth the tradeoff on ramp up speed.
-
The Rust community…
See, I’m inherently untrusting of anything that follows that statement, categorically.
I remember getting the first edition of the Programming Elixir book by Dave Thomas, where he confidently asserted “the community this” and “the community that” on patterns that were pretty obviously not set in stone or were personal style choices.
It’s waaay too easy for a few bozos who troll message boards to pretend to speak for the entire community (and no, the irony is not lost on me while making that statement). Especially having been burned by the JS ecosystem where “The Community” was 300% behind Backbone as the way to^W^W^W^WKnockout as the^W^W^WAnguler^WMithril^WReact as the way to do things.
Like, we’ve got to do better than mob-driven-development, because the reputation of “The Community” as a thought-leader is (or at least should be) thoroughly tarnished.
-
There’s nothing interesting about the phrase “the Rust community …” It’s a description of reality. It’s saying, “I’m linking you to this resource, and this resource has significant buy in from a lot of people.” People value that kind of information. If you don’t, then just say that.
-
I think it’s worth recognizing that particular phrases are frequently abused for rhetorical purposes - usually because there’s some ambiguity in the phrase itself. And in my experience this happens a lot with “the X community” - people frequently say “the X community Y” when they’ve only actually spoken to a couple of X, and from their perspective they’re not lying, but it can all too often be the case that most X don’t actually Y. (Indeed the implicit assertion that there’s a single cohesive X community is, in my experience, almost always wrong). I’d put a lot more credence in a specific statement like “Z out of W of developers surveyed at RustConfUS listed toiko as their preferred async solution” - or even just something like “I’ve got 20 Rust projects starred on GitHub and 5 of them are using tokio” gives a much clearer picture of what “Rust community” they’re talking about.
-
-
-
-
-
-
-
Exactly. The Rust type system allows you to give much stronger guarantees that are compile time checked than rust will give you.
I like both languages. Go is very much a frictionless language for me. I feel very fast when I’m writing with it. But if I’m writing software who’s purpose is to offer a strong security guarantee I’d look at Rust first.
-
-
-
-
-
-
-
-
I think there is a lot of evidence that suggests otherwise. His book The Art of Unix Programming is rated 4.1/5 on amazon. His (accepted) contributions to things like GNU Emacs, Python, as well as a number of tools such as gpsd, fetchmail, reposurgeon, etc, etc suggests otherwise. Now, it’s easy to say, “so? The code isn’t any good!” and that’s fair, but a bit misguided. We live in a world where programmers of languages with no protections against errors, unsurprisingly, make errors and choose abstractions that we later find problems with. When that happens to you, I don’t call you ignorant, point, and then laugh at you.
I don’t mean to defend ESR, because, frankly, someone will assume I support his politics, which I don’t.
But, I am defending the idea that we need to find a way to separate a person’s identities sometimes to create unbiased opinions on an individual one (identity).
I’m suggesting that I feel your (not calling you out, but lots of others, too) opinion of his political identity is influencing your opinion of him as a programmer, which I don’t think is right.
Now, if you had just said ESR is well regarded as a blowhard, I’d do nothing but nod in agreement.
-
I think some of the criticism of ESR comes from the fact that he touts himself as a master programmer (IMHO he takes hubris to new levels) when his code suggests the opposite.
I don’t even know what to say about this:
I often go entire months per project without committing a bug to the repository. There have been good stretches on NTPsec in which my error rate was down around one introduced bug per quarter while I was coding at apparently breakneck speed. This is how I do that.
And earlier in that article:
Yes, there was a bug in my vint64 encapsulation commit. I will neither confirm nor deny any conjecture that I left it in there deliberately to see who would be sharp enough to spot it.
(the above stolen from (felixgallo’s)[https://lobste.rs/u/felixgallo) earlier link.
As to the quality of his code, see my earlier comment.
-
-
- A language with a library to handle basic things you get with C from Unix, such as
-
The same argument I’ve heard for decades, whether I was living in South Carolina or Chicago. But he wraps it in more words, terrible writing and what you’d expect from someone who thinks they are smarter than they are.
-
I think it is quite clear from the writing that the writer is not a racist, and for a better reason. I was never convinced by human neurological uniformity, because it seems clearly false. (Think about it: human height uniformity would be a ridiculous idea.) I arrived at similar conclusions myself to have non-racist belief without believing false premises.
-
-
For those of us who don’t write Erlang code regularly, is it possible to summarize the bent of the changes? Glancing through these changes, it seems like the main reasons for breaking backwards compatibility was repeatability and extensibility?
-
Correct. To make repeatability and extensibility more natural the entire “core” had to be replaced. In previous rebar’s it acted more like Make, it would cwd in to subdirectories and check ‘what can I do here’ and do it. Now we construct an entire view of the project and its dependencies from the top level and go from there.
-
-
I feel that the author’s complaints are unreasonable and unwarranted. He chose a free license for his work, and is angry at not receiving things that were never promised.
-
Is no one allowed to regret decisions?
-
Certainly. My search for “regret” in the article yielded 0/0.
-
English is a complex language, which can be used to express an array of different emotions without using the exact same words.
You’re suggesting that the OP made a foolish decision, and now it’s wrong of them to lament their position, because they should have known better. I don’t think that’s particularly helpful.
-
-
-
-
As someone who has a ‘straightedge’ tattoo and … isn’t straightedge anymore, I support this :p
-
-
It was a really, really important and formative bit of my life, but I’ve grown out of it now.
-
-
-
-
There is nothing about “regret”. I can certainly understand that it’s a bummer that we live in a world where doing what you want and making money aren’t necessarily the same thing, but that isn’t what this post is about, it’s about the author being angry that the world didn’t live up to their end of a contract they never knew existed.
-
-
-
-
-
-
-
This is a very popular motif in complainjng about successful free software projects. “No one cares”, “users demand unreasonable time requirements and/or enhancements that I don’t have interest in”, “someone PRed a 3000 line change with out consulting me, and got angry when I didnt merge it.”
The Internet has turned us into a bunch of entitled whiners. Actually, I’m not sure if its the Internets fault, or society in general.
-
There’s a nice article musing on that possibility called The Web is a Customer Service Medium.
-
-
-
Actually, that isn’t quite true; if I may offer myself as a counterexample.
edit: I suppose I should clarify: I have experienced this, but not in the context of my more successful projects. Maybe that doesn’t count. =)
-
-
-
-
I’m not arguing for or against any ooint here. I’m merely pointjng out that a libre license doesn’t have to imply gratis, which the OP seemed to misunderstand.
Now, putting on another hat, this whole thing is exactly the complaint Zed Shaw so famously made: “I wrote awesome software (mongrel), and its so good, and easy to use that no one is willing to pay me consulting fees to support it.”
While I can sympathize with this, it typically comes off as whining that no one gives a shit that they are awesome, when in reality, the people who use their software are “just trying to get home to play with their kids”, so to speak.
The author should probably reevaluate their interest in releasing open source/free software in the future, or simply release software that sucks, but solves a niche need so people will pay to have stuff fixed, or make enhancements.
-
-
-
he is angry that we do not have a culture where companies who derive significant value from freely-given open source software participate in the gift economy by voluntarily giving some money to the authors/maintainers. especially if the project is the work of a single person who has clearly invested a lot of time and effort into it. it seems like a perfectly valid thing to be angry about to me.
-
-
The heroku router is not nginx.
-
I swear it used to be. I’ll ask @schneems.
EDIT: You were right. It’s a custom erlang app: https://twitter.com/schneems/status/626500188970946560
-
-
Is the guy who wrote Learn You Some Erlang still on the team (think Fred Herb)? That was amazing. There’s also a book by the routing team (or ebook) though I can’t remember the name. Both are awesome reads.
Found it: Erlang in Anger.
-
-
-
-
-
The absolute lack of context takes a lot of wind out of what might have been an interesting rant. It just feels hollow and pointless – I guess it might be solely targeted to people who know him as he mentions. Those people might have a clue what he is working on, why he picked Go, why he stuck with it for a year, and why after a year fairly basic things like pointers are eluding him…
-
-
I disagree, I see it more as a reflection on him, but opinions will vary. Pointer rules in Go are profoundly simple (like everything in Go) and the only gotcha is in the FAQ.
-
-
For what it’s worth, I wrote about when you do and don’t use pointers in Go on StackOverflow.
Speculating, but maybe part of what’s different is that many languages use pointers implictly. In lots of dynamic languages and Java and C#, when you pass an object to a function/method that changes, it changes in the caller too. (C# value types are an exception.) Even in C++, the
thispointer is always a pointer without you explicitly choosing for it to be, and you have references and reference parameters so you can make some&s and*s implicit. With Go, if you’re modifying something in the caller’s scope, you’re quite often (though not absolutely always) going to have a*in your function declaration.The idea in Go is that often enough to matter, you can avoid a pointer or it’s provided implicitly by a built-in type (maps, slices, strings, chans, and function and interface values contain pointers). But you need them when what’s passed in is huge or if you’re going to modify it. Using values where you can can keep stuff off the heap, reducing memory pressure and GC time, and can reduce the chance that something modifies your struct by surprise. Not unlike why C# has value types, probably.
You do have to grok what Go is doing behind the scenes to see the reasoning behind some choices, but the reasoning is there.
-
My thoughts on Go from a year ago http://blog.erlware.org/some-thoughts-on-go-and-erlang/
-
I am a huge fan of Erlang (shipped a major production system in it) – and I will never do it again. Hiring for Erlang was an unholy nightmare. It is nice for my bill rate when doing Erlang consulting, but bad for building a business, so my startup does not use it.
Additionally, a lot of your points are fixed in Go 1.5
- Scheduling: vastly improved in 1.5
- GC: vastly improved in 1.5 (no long global mark and sweep)
- Static Linking: optional in 1.5
I will continue to cheer for Elixir and hope it hits critical mass.
-
-
-
-
Maybe, but after a year? If you can’t nail down that concept in a year, I feel no pity for you.
-
-
-
-
-
Using something like Github doesn’t remove the distributed nation of git at all… I think it is the people who say that who are the ones that don’t understand the distributed nature of git.
-
-
I can’t tell if it is a joke or not… Too much work put in to be a joke, but come on: ‘As we already know, a name or axis (which of course applies to all nouns, not just cores) is a limb. A list of limbs is a wing.’
Another example, ‘Nock’s data model is simple: a noun is an atom or a cell. An atom is any natural number. A cell is an ordered pair of any two nouns.’
So a ordered list of integers? They have to be trolling.
-
Reading in the tutorial for the Hoon programming tutorial (http://doc.urbit.org/doc/hoon/tut/3/) it becomes even stranger. Here some excerpts:
[..] Think of learning Hoon as learning to program all over again. If nothing else, it’s a sort of eccentric adventure sport. Or even a mystery - can a language be esoteric, yet useful? [..]
[..] It’s actually worse than that - learning Hoon is learning to read all over again. Again, Hoon is a reserved-word-free language - any text in the program is part of the program.
So we’ve renamed them:
ace space gal < per ) bar | gar > sel [ bas \ hax # sem ; buc $ hep - ser ] cab _ kel { sig ~ cen % ker } soq ' col : ket ^ tar * com , lus + tec ` doq " pam & tis = dot . pat @ wut ? fas / pel ( zap !You just have to memorize these names. Sorry. We accept that they are vile, barbaric and loathsome. So is life. [..]
So they use 33 three-letter artificial names for commonly known symbols to make you be able to spell the programs?! But wait there is even more craziness ..
[..] But is this at least enough symbols? Alas, nowhere near. ASCII’s glyph supply is not the greatest, but we can make all the squiggles we need by forming digraphs, or runes. For example:
bartis, ie, |=. [..][..] Hoon has almost 90 digraphic runes. Worse, “Hoon runes” are inevitably shortened to “hoons” - a ridiculous non-English word due originally to Wallace Stevens, which also has the unique property of reducing Australians to convulsions.
None of this should scare you. First, 90 symbols is not a lot compared to, say, Chinese. Second, hoons are easier than you’d expect to organize in your head, because the choice of glyph is not random. Third, no one lives in Australia and nobody cares. [..]
So we have composition for those names, called runes. And so it goes on. I did not read yet further. But I guess it would cost quite an involvement to learn Hoon and you have to learn it completely from scratch, without being able to benefit from whatever languages you have learned before.
Why did the designer chose to obfuscate it so much?
-
Why did the designer chose to obfuscate it so much?
Making people spend an enormous amount of effort to join a
cultcommunity means that once they do, they’re invested enough to not leave.I wouldn’t make that judgement about any programming language, but I would (tentatively) make it about this one, after seeing who’s involved in its creation.
-
I almost have also the feeling that this might be an attempt to develop a Stockholm syndrome in the followers, but I am not sure though. I went through the Nock tutorial (http://doc.urbit.org/doc/nock/tut/1/) and with some effort was able to follow and understand it. Went on with Hoon and there I will stop, there - it asks too much involvement from me. And I do not know if this is not a wrong investment. However compiling and making the system run was straight forward, just by following the instructions on the github page. So, who knows, they are maybe out for something interesting.
-
-
-
-
-
Being denied by Whisper https://twitter.com/neetzan/status/522872120569655299
“Please continue sending me your questions. The Guardian article is riddled with outright lies and made up quotes. Happy to debunk them all.”
-
Rebar3. Implementing proper depsolving and update dependency for this thing is killing me. https://github.com/tsloughter/rebar
-
The tl;dr for those unfamiliar with the situation:
Mayve it’s just not clear to me, but is there an actual problem here, or just “I can’t do it exactly how I want to so I’m going to stomp my feet and threaten to leave”?
Does the OP want something that would circumvent all of the static benefits of using Elm? Is the message passing system inadequate?
I believe the actual problem is a communication problem: the user has read some bit and pieces, and started to be concerned about the way they are currently using Elm might not work going forward. That’s a very legitimate concern to have! However, based on what they said, their problem is actually completely solvable right now in Elm without the method they used to bypass Elm’s safety, via ports. Also, the undocumented API they used (“Native” code) led to this situation.
My understanding is yes, that’s what they want: but in standard XY problem fashion, the real concern they have is becoming blocked by upstream bug fixes not being merged as often as they’d like. This is something we’re actively looking into improving in Elm going forward.
There are some aspects of it which are inadequate, for sure. Ports require that all the code that use them be async in both Elm and JS. This can be a problem if you need sync code in your view function, for example. However, that’s entirely possible to work around.
Last I checked the creator of Elm literally did not allow any libraries to be published to the central repository without his personal approval if they used the JS interop system.
While technically true, this doesn’t really paint the whole picture.
You can publish any Elm part of a package that uses ports. What you can’t do is publish the ports exposed themselves. There’s a good reason for that: to avoid name collisions on ports. So, what you do is:
It’s straight-forward to do things in this manner.
Thanks for the context. While I still think it’s problematic from a social perspective to have a benevolent dictator who acts as a personal gatekeeper for what is and isn’t allowed to be published, from a technical perspective it doesn’t seem so bad.
The message passing system is absolutely inadequate for some things (e.g., for replacing Math library functions, or for, as in this case, replacing the native websocket module). These can not be implemented async, and therefore not with ports.
See this quote from the author:
For these things, you need to use JS to do it yourself, and in the latest version, there’s a whitelist restricting which people can create such JS modules. This whitelist is restricted to the elm team.
As result, people are considering forking the compiler, or moving away entirely.
This is not accurate: ports are perfect for replacing the websocket module. The reason why the original poster mentioned websockets is because they wanted to patch the library themselves. However, using ports instead would’ve worked just fine. That’s how the existing library is modelled, after all.
Here is the exact reason the user expressed as to why they’ll have to use a fork of either Elm or rewrite the extension they rely on:
It’s basically out of their hands as a user who didn’t create and doesn’t maintain the extension that their production app came to rely on so they’re already using a fork. That situation was not ideal but they had an easy path forward with the fork. They are now worried that that easy path forward has come to a dead end because the original package doesn’t seem to be maintained well enough for them to think that this will be remedied soon and they will have to do a lot of work, one way or another, to upgrade Elm ≥ 0.19. It might be an amount of work that their team will just port the app to something else entirely.
There are libraries like elm-websockets the OP had to fork and use their forked version because their bug fix PRs have not been merged in 2 years. So the issue of not having releases for years (instead working on the next major release only it seems) and now planning to even disallow this work around for the lack of releases.