take plain old database, then add requirements 1) to be public, 2) not controlled by a single entity, 3) stored data is objectively consistent, and you basically get a blockchain
P.S. I find the name of the book 'The Bitcoin Standard' fairly misleading, given that the first 2/3 it is about Gold Standard and barely mentions Bitcoin. I have not found the latter 1/3 of the book interesting to read, so I dropped it there.
Yes, except... again, this is fighting fire with fire.
If you don’t know git internals, mistype a non-obvious command and lose a bunch of commits, then “look in the reflog” advice is frankly adding insult to injury.
The reflog is awesome! It keeps pointers to commits that have been dropped, rewritten by rebases, stuff like that.
Git is garbage collected, even if a commit is dropped from a branch it won't simply disappear immediately afterwards. The object is still in the git repository and it can still be reached, most easily through the reflog. Only when garbage collection is performed will any unreachable commits be deleted.
> It's really hard to lose changes once they've been committed.
I've still managed to do it (or maybe I used git rm to delete some files that weren't committed?) so let me give one more shout out to 'git fsck' which saved me here.
That is my fault--nonintutive interface. With this one, you need to select the songs you like and they are added to the list in the box. When you press play, that list plays. The idea was to create some customization without a login. Please see if that works for you.
Elm is awesome, its compiler is awesome, but its ecosystem is kinda stalling, isn't it?
I mean, a lot of libraries aren't updated to the last lang version, debugging JS-Elm interactions been a real challenge for years, yadda yadda. Overall I'd say Elm ecosystem doesn't receive enough attention to survive.
I'm not complaining, I'm just sad about that and kinda surprised I didn't found a mention of that in the OP article.
As I understand it, there was a rift in the community over the leadership's tone in messaging and communication. Some Developers also felt like they could not contribute in a meaningful way or have constructive discussion with maintainers.
See posts like these for more details and comments:
Honestly I think the main reason for this perception is that people in the Elm community have gotten increasingly tired of correcting inaccuracies people like to post about Elm on Hacker News.
I spent a bunch of time doing that in the past, and eventually stopped because I felt like Sisyphus. The same people would crop up on the next thread repeating the same things anyway. Of course if the claims go unchallenged, it leads to the perception that they're accurate...but that doesn't make engaging with them any more enjoyable a way to spend one's free time.
If you want to check the health of the Elm community, visit Elm Slack and ask in the #beginners channel how people feel about it. It takes about the same amount of time as posting a HN comment, but it gives a very different perspective than the one you'd get if your main source of Elm information was Hacker News comments! :)
Speaking as someone who liked Elm for a while, then abandoned it, I will say that the biggest problem with the language is absolutely its leadership. Development moves at an absolutely glacial pace and basically takes place with no transparency at all. I would argue that it's more like a "source available" project than an "open source" one since the core dev team is so exclusionary. Most planning takes place inside Evan's head, leaving others to just speculate as to what's going to happen to the language.
On top of this, the community is run like a dictatorship. Dissent is silenced and banned, and faux positivity is spread far and wide. I got sick of it and was banned from the Elm subreddit after I expressed my frustration. That's pretty much when I gave up on the language, years ago, on version 0.18 (fwiw, they're on version 0.19 now, that's how slow updates are)
This is an example of the type of post I was referring to being tired of correcting.
I don't use Reddit anymore, but if memory serves there have been about 5 people total banned from the aforementioned Elm subreddit, which is fewer than 1 ban per year it's existed.
I invite anyone to evalute the accuracy of "Dissent is silenced and banned" with that data point in mind, and to evaluate the accuracy of the other above claims accordingly.
FWIW, I have the same experience as the parent poster. I used to love Elm, evangelized the architecture, wanted to write Elm professionally. I was constantly bumping into things that were not finished or working, but didn’t really mind. But I also often encountered cases where the leadership team was saying “we don’t want this discussion here, thank you very much”, even if the discussion was perfectly legitimate, friendly, technical and related to some sorely needed feature or bugfix. I constantly felt unwelcome, like I was trespassing on someone’s lawn. I didn’t want to base my work on that. Eventually I just shrugged and left.
Totally fair! I'm sorry to hear you had that experience, although I hope maybe you'll someday consider giving it another chance in the future. :)
My personal experience has been different, but I upvoted this because I really appreciated that you shared your own experience without overgeneralizing it.
Interesting food for thought. I bought your book awhile back and was 2 chapters in before reading about the aforementioned "Dissent is silenced and banned" issues which led me to abandon continuing at the time. Maybe I'll jump back into it.
I've not heard of such misinformation being spread about other languages. Id love to hear your side on why Elm itself seems to attract such ire if its inaccurate.
I think there's more than one factor, but the biggest one comes down to setting expectations, especially in the early days.
Elm does a lot of things differently than other languages, and while I think that overall those differences have been instrumental to its success, especially early on it sometimes wasn't clearly enough communicated when "this is temporarily different because it's a WIP; you can expect it to be more like what you're used to in the future" versus "this is different by design, so expect it to stay different or even to become more different."
Examples of this include typeclasses (a lot of people coming to Elm from a Haskell background assumed Elm would add them as a matter of course), JS interop (by design, it's not a traditional FFI, although there was an unintended backdoor that kind of worked like one; when that backdoor was finally removed, after much communication that in retrospect should have happened at the outset, some of those who had been relying on it were understandably upset), how the project is run (more like Clojure than like JavaScript), and what the release schedule looks like (batching large projects rather than more frequent smaller releases).
I think things are a lot clearer today, but for some it's unfortunately too late to make a difference.
One thing is that it wasn’t communicated that well, but other (and that’s what made me feel really uncomfortable) is that it felt like „This feature is not allowed anymore - except for some dudes, they’re cool enough and can use it” (e.g. native modules, operators). Either keep or drop feature
Kernel code and custom operators are only allowed under elm/ and elm-explorations/, so only 7 core packages can use them. The core developers cannot use those features in projects like everyone else.
And who can contribute to `elm` and `elm-explorations`? The 7 cool dudes.
The Elm contributor circle is a clique that you literally have to be a strong contact with one of the contributors to get into it. It goes against everything open source stands for.
> It goes against everything open source stands for
Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.
The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!
And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.
The problem is there are some reasonable features that cannot be implemented with the current ports system that _should_ fit into the expected design. Specifically, I feel you should be able to replicate the `Http` module using ports or some other available system. However, you cannot properly dispatch a task and then tie together the result with a curried `Msg`, as you might expect or hope [unless you store a complex state object in your model]. These types of issues are the frustrations that, I believe, cause some discontent in the community. I feel more people understand why you should not, per se, make random FFI calls in the middle of pure code (e.g. since it would break dead code elimination and require evaluation order guarantees), but other restrictions seem arbitrary.
The thing I found unsettling wasn’t that something was disabled (fair design decission), but the mindset that considers some features harmful , but is happy enough to use it in its own „special case projects/packages”. It doesn’t really matter for how many packages its available, since it can be changed on a whim. I can only speak for myself, but I found it unfair and patronizing
I don't think that's fair. If elm ever wants to replace js it only needs to rewrite the kernel modules, they govern. Otherwise the whole ecosystem would break in that case and yes, that would be a harmful feature.
I didn’t mean locking features, especially native modules - didn’t write a single one, so personally I won’t miss it. I meant „some repos are more equal then other” mindset. It’s clearer in case of custom operators - they are considered confusing, unless you mean parsing and by parsing you mean elm/json or elm/url, then it’s cool.
By all means, I’m not saying those are crucial features or that they don’t have right to do whatever they want with their language. They can and they do. I just find this kind of atitude and reasoning patronizing.
I'm a fan of Elm, and I'm using it in production, but I think this is very much a case of using some flaws in the way people see Elm to ignore some correct criticism of it.
The community absolutely suffers whenever anyone comes across one of these issues where there just isn't a solution, and more than that, no communication at all. It implies the project is dead.
I accept that Elm is functionally just stalled and won't see any changes until some arbitrary point in the future, I can live with that. I don't think the project communicates it's state and direction well though, and that leads people to disappointment and the posts you see.
That's a good point and maybe I shouldn't have re-posted these stories in my comment as I have not personally witnessed this behavior. I just know that when I started learning Elm initially (Nice Frontend master courses btw) I ran into this sentiment a good bit on reddit and hackernews so thought there was probably something to it if it was being echoed by so many.
I'll add a reply to my comment to make it clear this is hearsay and doesn't necessarily reflect the truth.
After considering the way I phrased this comment above, I want to clarify that I never personally observed or witnessed this kind of behavior myself. My own dealings in the Elm community have been almost entirely positive. I had heard a lot of these criticisms from comments on hacker news or reddit and realize now they mostly resemble hearsay or people like myself repeating what they heard from others resulting in a sort of echo chamber. I apologize for adding to that echo chamber.
Also Mint at https://mint-lang.com, which is heavily inspired by Elm (and better, IMO). The open source aspect is also the opposite of Elm - the community is very friendly, the developers are responsive and positive, and PRs are encouraged.
F# solves many of these problems with it's ability to pull in C# libraries. When looking for a functional language to learn I settled on F# and am loving it so far. I'm not sure if I'd ever use it in production as it is still very niche.
What Evan is doing with Elm is awesome, he has a small closed set of features to make a language that is aimed at doing one thing. He has very tight control to make sure there is zero cruft in the language. It's an amazing project. The cost is that it's very hard for outsiders to have any input into the language. So the ecosystem will never take off.
I would argue the opposite! The elm slack is very active with people who frequently contribute to the ecosystem. I don't think the "a lot of libraries aren't updated to the last lang version" is true, the vast majority are.
Debugging elm-JS interactions is not really a problem when using the standard interop methods of ports and webcomponents. It's just not something that comes up often.
Source: have been writing elm professionally for the last 2 and a half years.
Disclaimer: I'm just describing an annoying technical problem, it's not a blocker for the use of Elm. Elm _is_ great :)
I have been using Elm for a kinda-simple project on my work: dashboard for microservices, deployment configs, nodes, etc.
One of the biggest time-drains was debugging JS-Elm port interactions, looking whether there is a mismatch in types.
Cuz the error looks like this:
Elm eventreceiver failed: Error: Trying to send an
unexpected type of value through port `collectPeerInfo`:
[object Object]
I know of no way of even looking into that `[object Object]`. Simply logging its fields would already be a relief, lest telling what field/type caused the error.
I'm not an Elm veteran like a lot of the folks here, but I think an aspect of Elm is that a lot of the traditional ways that people expand ecosystems are discouraged by Elm's approach. For instance, components are hard to do in Elm and are discouraged in the documentation[1].
So my own personal Elm projects have involved a lot of reading other code and often copying and modifying open source code, but it's hard to wholesale import components in the way that JavaScript and other languages do it. My experience with the language is that it is very easy to do what I want in it, but it seems more difficult to share that as an open source contribution in Elm than in similar languages.
I think "1 container = 1 process" is a common misconception. There should be a separation of concerns, but there's no reason to go to extremes where it doesn't make sense.
When docker first arrived, people were confused about how to use it. I remember seeing lots of people putting an ssh daemon in their containers!?! I like the s6-overlay approach, it's pragmatic.
I haven't been using containers as much lately, but I wonder if s6-overlay's approach could be used to justify including a database into the container with an application. Is that a good idea?
> I haven't been using containers as much lately, but I wonder if s6-overlay's approach could be used to justify including a database into the container with an application. Is that a good idea?
The answer is as always: it depends. My rule of thumb here would be: would it ever make sense to configure the application to use a different (or even just remote) database? If so, then the database should have a separate container (when using a local db). This applies most of the time.
Similarly, if the database itself is an integral part of the application which it doesn't make sense to swap out or have remote... then by all means just include it and tell the user to mount their data volume to /data or whatever. Example: A single-system file indexer.
> would it ever make sense to configure the application to use a different (or even just remote) database?
Emh, don’t we always end up like this? As in, the database stays up while restarting the app; The DB is restarted when upgrading versions; and when we start 10 front-end nodes while keeping one DB only. All if this because they have different lifecycles: DB data is permanent, webserver data is ephemeral.
>would it ever make sense to configure the application to use a different (or even just remote) database? If so, then the database should have a separate container (when using a local db).
This can probably be further simplified to "does it run over ports? then probably yes". E.g. you'd separate your application and database, but not your database and its filesystem.
I'm not sure I fully understand, but with my assumptions in hand:
That's bit of an implementation detail, I think.
If my app is the most amazing file system indexer using PostgreSQL behind the scenes, I don't think the "port" distinction is relevant... oh, wait. You're thinking of ports as in INET vs. plain sockets?
That took me a long time to get. A very technical way to put it, but thank you.
