While I love the tech behind this (as well as the good article and fun demo video), I'm very skeptical that this will be a good approach for most web apps. I hope it doesn't turn into Python programmers suddenly pulling in 7MB of WASM code/data just to render their websites (along with a 5s startup time), adding yet another layer of complexity and virtualization between their code and the browser. I think the interest in the tool is overall a good thing, but I think we need to be very careful about what kinds of projects we use this for.
@benhoyt | Hacker News
From 2/21/2007, 9:17:39 PM till now, @benhoyt has achieved 5596 Karma Points with the contribution count of 900.
Recent @benhoyt Activity
Introducing PyScript (summary of PyCon keynote)
402 points • 234 comments
I think your pushback is good - I didn't think the explanation about multiple cores made sense either. The Go runtime doesn't magically spread things across cores. However, I don't think your sarcasm helps the conversation.
Berry's response to that (and similar) letters is quite sharp, but fair, I thought:
> I am also surprised by the meanness with which two of these writers refer to my wife. In order to imply that I am a tyrant, they suggest by both direct statement and innuendo that she is subservient, characterless, and stupid -- a mere "device" easily forced to provide meaningless "free labor." I understand that it is impossible to make an adequate public defense of one's private life, and so I will only point out that there are a number of kinder possibilities that my critics have disdained to imagine: that my wife may do this work because she wants to and likes to; that she may find some use and some meaning in it; that she may not work for nothing. These gentlemen obviously think themselves feminists of the most correct and principled sort, and yet they do not hesitate to stereotype and insult, on the basis of one fact, a woman they do not know. They are audacious and irresponsible gossips.
> And it's not even compiling and optimizing and linking, it's just transpiling typescript to javascript. It's ridiculous. It's ridiculous to think we can't do better.
I don't do (much) frontend development, so I haven't had a chance to use it, but it looks like esbuild does do better: https://esbuild.github.io/ -- are you guys able to use that?
I agree with the sentiment, though! And it's part of the reason I like Go: build speeds are fast, especially incremental builds (which is almost all the time, given how it caches compiled packages).
Compatibility: so it can run all the existing AWK scripts without modification, and people can refer to existing AWK documentation when writing scripts, and they'll just work under GoAWK.
For a 45-year old language, it's actually surprisingly good. There are a few annoyances and clumsy things (getting substrings is a function call without nice str[start:end] syntax, regex matches are harder than they need to be, string concatenation syntax is weird, arrays aren't nestable (except in Gawk), and so on).
I've actually thought it'd be great to "fix" these things and make a nicer AWK language, but the problem is then no one would use it. :-)
> Somebody is forgetting that comparison and arithmetic operators are an interface on a type, and that almost every popular language (even many that are ostensibly “statically typed”) have ubiquitous nightmare scenarios surrounding implicit casts.
For what it's worth (and in the context of the article), Go doesn't do implicit conversions like this: you get a compiler error if you compare an int32 to a uint64, for example, and you always have to convert one to the other type explicitly. That goes for comparisons and arithmetic (neither of which are overloadable in Go).
Duck typing is safe (2020)
58 points • 79 comments
A beautiful, big full moon was visible over Christchurch, New Zealand tonight, and I was just talking about this with the kids. It fascinates me that scientists have sent us up to the moon, but can't figure out exactly why it appears bigger when it's rising.
Odd, I find the standard library very full-fledged and useful, including the strings package. I've almost never needed to reverse a string, except in interviews. :-) The stdlib has a full (and good) HTTP server with HTTP/2 and TLS support, HTML templating, excellent I/O support, compression, even image encoding/decoding and drawing. That said, the container types are pretty sparse, but that may change a bit now that generics are here.
What, apart from string reverse, do you miss for real projects?
I think you forgot the "hasA" type on the var line. Fixed: https://go.dev/play/p/0Amm7nd1Av4
My thoughts on his points, from someone who really likes Go and has used it heavily on small and large projects (1M LoC):
1. Probably a matter of taste, but I love this feature, just because of the lack of noisy public/private keywords everywhere that you see in Java et al. It also means you can tell from a usage (not just the definition) that something is exported, which is often useful.
As far as renaming goes, either rename the definition and see where the compiler complains, or get your IDE to do it (I use GoLand, but good things are said about gopls).
As for his example, the idiomatic way to write that is either just call it `usr` or `adminUser`, or use `user := &user{}` which is valid (if a little confusing).
2. This is a feature: it allows you to define interfaces only where you need them (on the consumer side), and you define the interface with only the methods you actually need. This means that when you add a bunch of new methods on the implementation, you don't need to change all the consumers. Go interfaces are amazing.
The downside he discusses almost never happens: it's surprising, but even in large projects I've never had structs accidentally implementing interfaces or a IsAdmin method being implemented with reversed polarity by accident.
3. Definitely has its downsides. Tooling helps find unchecked errors. Though I've found the biggest downside to explicit errors is the verbosity. You do get used to it, and the explicitness is at least clear.
4. There are a couple of "magical" things like this, but they're well known and documented, and simple to fix if you run into them. I love the fact I can just name a file foo_test.go and add TestFoo methods, and "go test" finds them automatically.
5. I have not found this to be the case, and in the rare cases it does happen, the compiler tells you loudly and it's easy to fix.
6. Yeah, this is a slight pain, but the semi-official "imports" package (golang.org/x/tools/imports) fixes it up, so you just run generated code through that (and it auto-formats the code as well). It's a couple of lines of code. See: https://github.com/benhoyt/prig/blob/2df1b65a2bdf34c10bb5e57...
7. Yeah, I wouldn't mind a ternary operator. Easily misused, which is why they didn't add it, but it would be really nice used judiciously, rather than the 4-line if-else block.
8. Fixed by sort.Slice, which avoids the need for Len and Swap (and even more so by the new generics "slices" package, coming soon). I guess this was added after the article was written?
9. Fixed by "Go modules", which is really well designed and works well (though opinions differ).
10. Fixed with generics being added in Go 1.18. And generic helpers like "slices" and "maps" packages coming soon.
11. Yeah, slightly annoying for newbies, though as he mentioned, tooling tells you. I do like the control you (can) get over allocation and memory management with Go slices.
As far as his summary goes (eg: the type system getting in your way for large programs), I have definitely not found that to be the case. The author doesn't like Go, and that's okay! I don't like Java. :-)
I highly recommend you learn the basics of AWK, which is a little language that lets you match on and run commands on every line of input (so AWK "scripts" are usually one-liners). The very basics can be learn in 5-10 minutes, the whole language in a couple of hours (read the first three chapters of "The AWK Programming Language" by A, W, K.)
For searching recursively through folders, I recommend ripgrep (rg), though it won't do number conversions and the like.
Self-promotion (but I think it's useful here) is my GoAWK project, which is a POSIX-compatible version of AWK, with the recent addition of proper CSV support: https://benhoyt.com/writings/goawk-csv/
You're not wrong, I should have just said .gz (though that really wasn't my point :-).
> I thought if you use compression, you'll always lose at least a small amount of data. Or is that a fundamental misunderstanding?
Yeah, that is a misunderstanding. There's lossless compression and lossy compression. For images, the classic example of lossless is PNG and lossy is JPEG -- with JPEG you get more and more artifacts/noise the higher your compression is, but with PNG you can always recreate the exact pixels of the original, hence the OP's use of it as an archival format.
PNG is similar to how .zip and .tar.gz files work for executable files and other data -- those have to be lossless, because for text and executables and the like you need the exact 1s and 0s back out that you put in, otherwise the executable will crash or the text will be garbled.
> you actually get to choose whether you put things on the heap or stack
I think I know what you mean, but this isn't strictly true. In Go, the compiler decides for you, and you don't have to worry about it. The compiler allocates on the stack whenever it can (because it's faster and uses less memory), but if it determines that a variable "escapes the stack" or if it can't figure out whether it escapes or not, it allocates on the heap. You could have a simplistic (but correct) Go compiler which allocated everything on the heap -- interestingly, the Go spec doesn't mention the words "heap" or "stack" at all.
Go does give you a lot of control over allocations (stack or heap!) and memory layout, though, which makes it pretty good for relatively low-level performance work.
Definitely agree. I really like that ripgrep is fast, but I mainly use it for its better UX for what I do every day: search code. If ripgrep wasn't any faster than grep, but was still recursive by default and ignored .gitignore et al, it'd still be worth using for me. (In fact, I used to use "ack", which is basically ripgrep but slow. :-)
Just my two cents as someone who isn't associated with Sourcegraph: I also thought this comment was overly snarky and not exactly true. Their main product is a really good code search/navigation tool, and even Code Insights is hardly "tracking" software productivity. See also "don't be snarky" in the HN guidelines: https://news.ycombinator.com/newsguidelines.html
This is definitely true, and I wouldn't fault anyone for using Ruby or Python to write the initial version of their startup. However, there's a difference between initial productivity and ongoing productivity (maintenance). Statically typed languages like Go and C++ are much easier to rework and refactor, because the compiler is checking types (not to mention typos).
The Tools I Use to Write Books (2018)
170 points • 39 comments
site design / logo © 2022 Box Piper