Skinney

10 ms·

91.
by Skinney 3y ago
No tuples: I found this to trade some convinience (no need to name anything)for worse refactoring (adding a value to a tuple or reordering the fields breaks everything, doing the same to a record doesn’t). I also improved pattern matching o
92.
by Skinney 3y ago
Yeah. I understand the need for this, but I’m also very hessitant to break guarantees on mutation and other side effects. It’s a tricky problem. It will be looked at pre 1.0.
93.
by Skinney 3y ago
The kernel code API is quite… unfinished. It isn’t documented, it performs no validation and it crashes the compiler when written incorrectly. It really isn’t ready for general use. It’s also expected to break in the next few releases. I wi
94.
by Skinney 3y ago
Would you mind creating a github issue for it? I’ll try to get it fixed for the december release (0.3 is releasing next week, which doesn’t leave me with enough time to do it now).
95.
by Skinney 3y ago
Not sure if I got around to fix that bug. If I haven’t, a PR would be welcome :)
96.
by Skinney 3y ago
Only on the first compile. It doesn’t perform this check when loading a package from the build cache.
97.
by Skinney 3y ago
Elm doesn’t allow kernel code in externel packages. Gren is performing the exact same check, it’s just that Gren uses Git as a package manager and so has to do it in a different way.
98.
by Skinney 3y ago
No. In fact I added some code that still enforces this with the Git-based package manager. I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls. However. The
99.
by Skinney 3y ago
Lead developer here. I think it’s a little misleading that the title of this post is «Gren - an Elm fork». While technically correct, I think there are many who will be dissapointed to find that Gren and Elm are incompatible languages. In a
100.
by Skinney 3y ago
I’m not claiming it is not a fork. It is. That said, people expect certain things when you market something as a fork, so I’m a little careful in making that the first thing someone hears of the language.
101.
Gren 0.2.1: Testing, Testing(gren-lang.org)
1 points by Skinney 4y ago|0 comments
102.
by Skinney 4y ago
LISP was one of the very first high order programming languages (came around the same time as FORTRAN). If anything, other languages are different for the sake of being different. Btw, Clojure makes those exact changes you mention (first in
103.
by Skinney 4y ago
Nokia, Remarkable, Ericson, Spotify, Tidal
104.
by Skinney 4y ago
nitpick: Elm was and is written in Haskell.
105.
Gren 0.2: Hello, Node.js(gren-lang.org)
3 points by Skinney 4y ago|0 comments
106.
by Skinney 4y ago
> but to get correct answers you have to shut the thing down at the end That's one of the things structured concurrency improves on. By defining a scope in a try-with-resources block, you make sure it's teared down at the end o
107.
by Skinney 4y ago
> Basically any time any virtual thread does something expensive/blocking, all the other virtual threads suffer. Most Java APIs like socket and file have been re-written to do this for you under the hood. You're not expected to
108.
by Skinney 4y ago
You already have queues in Java. They should work just fine with virtual threads, as they do on regular threads.
109.
Gren: Documentation as a First-Class Citizen(gren-lang.org)
3 points by Skinney 4y ago|0 comments
110.
by Skinney 4y ago
The official reason is here: https://github.com/elm-lang/websocket I believe it's quite possible to support websockets with the current language features, though, and I hope that websockets will be ready for Gren
111.
by Skinney 4y ago
Lead developer of Gren here. It's great to see people being interested in the project, thanks for the mention! Just wanted to add that both websockets and indexed-db is being worked on by members of the community. I'm hopeful we&#
112.
by Skinney 4y ago
> high-availability, which IMO is absolutely essential for any serious business Depends very much on the business. You can have downtime-free deploys on a single node, and as long as you've setup a system to automatically replace a
113.
by Skinney 4y ago
JS offers classes (or a similar construct pre-ES2015) and you can’t easily merge two objects (there’s the spread syntax, but that doesn’t bring along the prototype). So you’re mostly rewarded by keeping object «types» seperate
114.
by Skinney 4y ago
Not if you use litestream
115.
Gren 0.1.0, a new pure functional programming language, is released(gren-lang.org)
16 points by Skinney 4y ago|0 comments
116.
by Skinney 4y ago
Yeah, and this "kitchen sink" approach is partly why I stopped writing C#. Same thing is turning me away from JS. It's exhausting trying to stay up-to-date with the language, in addition to changes in the frameworks and tools
117.
by Skinney 4y ago
> and voila, all dynamic languages suddenly started to convert into statically-typed This is... just wrong. Plenty of people are using JS without any sort of typing whatsoever. Other dynamic languages, like Clojure, Gradle, Elixir, Phara
118.
by Skinney 4y ago
Didn't know that, that's great!
119.
by Skinney 4y ago
Sure, but do these have API's that work with regular threads?
120.
by Skinney 4y ago
When JVM lands support for virtual threads, what reasons remain for using core.async? core.async will still be useful in ClojureScript land, though.

More ›