mvdan

5 ms·

1.
by mvdan 7mo ago
Indeed! This blog post is also relevant: https://cue.dev/blog/guardrailing-intuition-towards-reliable...
2.
Using CUE to unify IoT sensor data(aran.dev)
55 points by mvdan 1y ago|4 comments
3.
MinCal, an open source calendar widget for Android(github.com)
6 points by mvdan 3y ago|0 comments
4.
by mvdan 4y ago
https://github.com/mvdan/sh/blob/master/syntax/canonical.sh is one small example.
5.
by mvdan 4y ago
For the first two caveats, I actually agree that we could and should handle ambiguous input. It just hasn't been a priority because doing that properly would be quite a bit of work, and such ambiguous syntax isn't particularly com
6.
by mvdan 4y ago
gofumpt will never have formatting knobs, following gofmt's design. But if one of gofumpt's rules forbids a style which is reasonable even if it's not very popular, we might want to make the rule more conservative or remove i
7.
by mvdan 4y ago
You might be getting confused. gofmt does not warn about lacking comments, that was golint, which has since been deprecated. gofmt does not divide or re-join imports into groups, but gofumpt does :) Neither gofmt nor gofumpt enforce a chara
8.
by mvdan 4y ago
I hadn't really considered that people might want to do this. From experience reading and writing Go code for ~8 years at multiple companies, the only times I've seen leading or trailing empty lines in blocks have always been eith
9.
by mvdan 4y ago
It's not quite as simple as that :) I think upstreaming half of gofumpt's additions to gofmt would be reasonable, but the person who wrote and maintains gofmt is Robert Griesemer, who continues to be quite busy with generics. They
10.
by mvdan 4y ago
I agree that empty lines can help. I've been careful to only remove empty lines which, in my opinion, don't help when structuring the code or making it more readable. If you have examples where gofumpt is being a bit too aggressiv
11.
by mvdan 6y ago
I'm the author of that presentation, and I'm surprised to see the very similar content and structure, to say the least. I left a comment on the Reddit thread[0] to see if I'm missing something. [0] https://www.redd
12.
What's coming in Go 1.15 [slides](docs.google.com)
2 points by mvdan 6y ago|0 comments
13.
TinyGo v0.9.0 Released(github.com)
3 points by mvdan 7y ago|0 comments
14.
by mvdan 7y ago
It might lead to fewer allocations in complex programs, as the compiler is able to put more in the stack under some edge cases.
15.
by mvdan 7y ago
Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from. The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os&#x
16.
by mvdan 7y ago
These are the slides from a talk; I didn't spend the extra time to change the format or write down what I explained. After all, I didn't post them here, someone else did :) I personally think it's best to just follow the link
17.
by mvdan 7y ago
See https://github.com/golang/go/wiki/Go-Release-Cycle . We're one month into the three-month freeze, so it's unlikely that new features are going to be merged in before the tree reopens. Bugfixes ar
18.
Slides: What's Coming in Go 1.13(docs.google.com)
16 points by mvdan 7y ago|3 comments
19.
Benchmarking package initialization in Go(commaok.xyz)
1 points by mvdan 8y ago|0 comments
20.
by mvdan 8y ago
If anyone wants the recording, this is the timestamp in the meetup recording before an edited version is available: https://youtu.be/RGeHsqj2RWo?t=2h16m11s I can see that the slides alone aren't self-explanatory in som
21.
by mvdan 8y ago
I'm going to go on assuming that you're not being sarcastic :) As I mentioned in another comment, once Go's wasm support is shipped and stable, I hope to make the JS package smaller and better. Until then, this is the best I
22.
by mvdan 8y ago
That's a good point. I am adding more and more examples to the Go documentation these days. Ideally I'd just point the JS people at the Go docs and examples, but the translation is not exactly one-to-one. This is why the README fi
23.
by mvdan 8y ago
It sounds like I should use streams then. After all, that's what the Go API uses, Readers and Writers. Those simply pass chunks of bytes around. Thanks again for the help!
24.
by mvdan 8y ago
Yep, I've exchanged a few emails with Andy before, the oilshell author. I started the parser in early 2016, so we were both getting started around the same time. If you look at my README's caveats section, you'll see a very s
25.
by mvdan 8y ago
Most Go code out there is under permissive licenses, I assume because static linking is the norm. I hope I don't get an angry email from RMS at some point :)
26.
by mvdan 8y ago
Point taken; yes, when I said they were still different, I meant the simplicity of the tool and how its output is higher level than machine code. But as you all say, this is just a spectrum. Perhaps the future generation will call JavaScrip
27.
by mvdan 8y ago
Is there a more appropriate word for source-to-source transformation? I understand that compilers aren't that different, but generating machine code is quite different.
28.
by mvdan 8y ago
I'm not sure I understand what you're saying. If there was a Go->Bash transpiler (or a JS->Bash one), yes, we would theoretically end up with a Bash parser and interpreter in Bash. I imagine it would be quite the monster, th
29.
by mvdan 8y ago
I hope noone notices that most of my code was written by a Markov chain.
30.
by mvdan 8y ago
This is hacky, but it beats having to write a shell parser from scratch again :) Once wasm support is shipped with Go, I hope to be able to accomplish the same without a transpiler. I'd also hope that the final package would be smaller

More ›