What does he mean by this? "The language does have annoyances. The absence of const is a minor one." https://gobyexample.com/constants const s string = "constant"
He's referring to it as a type qualifier, I would assume.
Grappling with Go
81–90 of 118 posts
Re: Grappling with Go
#82What does he mean by this? "The language does have annoyances. The absence of const is a minor one." https://gobyexample.com/constants const s string = "constant"
I don't think he was complaining about the lack of a syntactic token reading "const", but rather the inability to protect values from modification (in certain contexts) without incurring the overhead of hiding them behind an interface.
Re: Grappling with Go
#83Earlier quoted context omitted.
They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn…
> I genuinely do not like the idea behind the ntpsec project I don't know the NTP protocol well enough right now, or the aims for the ntpsec project itself. I will say that having a signed response from an NTP server, would raise the trust level of the accuracy of that response. That is, no one can respond with a bogus time and screw up all sorts of stuff. In terms of privacy/tls etc, that seems less important. But s…
ntpsec isn't a project to revamp or cryptographically improve the NTP protocol; it's an attempt to do for ntpd what BoringSSL and LibreSSL are doing for OpenSSL.
Re: Grappling with Go
#84Earlier quoted context omitted.
I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…
Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience. Different concerns have different emphases in each fad, but the systems built have structura…
> You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It's worked for many people, and it can work for you. - Ron Minnich
Re: Grappling with Go
#85What does he mean by this? "The language does have annoyances. The absence of const is a minor one." https://gobyexample.com/constants const s string = "constant"
He's referring to it as a type qualifier, I would assume. https://en.wikipedia.org/wiki/Const_(computer_programming)
Got it! Thanks for the clarification.
Re: Grappling with Go
#86> I checked this by writing loccount as a parallelized tree traversal. Each file in the tree gets a goroutine spawned to count its lines; the threads run in parallel and as each finishes its work it stuffs a statistics block into a channel. In the past, this approach would blow up because Go would spawn a kernel thread for each blocking system call that was performed. I had to use a rate limiting channel to constrain…
Isnt there a way to limit the number of threads? Starting N threads each reads the same queue and executes the operation. The queue gets full when there are no workers are available. I though you can implement something like this in Go...
You risk deadlocks if you have a limit on the number of system threads.
Think about something like goroutines reading and writing from pipes.
Re: Grappling with Go
#87Earlier quoted context omitted.
> I genuinely do not like the idea behind the ntpsec project I don't know the NTP protocol well enough right now, or the aims for the ntpsec project itself. I will say that having a signed response from an NTP server, would raise the trust level of the accuracy of that response. That is, no one can respond with a bogus time and screw up all sorts of stuff. In terms of privacy/tls etc, that seems less important. But s…
ntpsec isn't a project to revamp or cryptographically improve the NTP protocol; it's an attempt to do for ntpd what BoringSSL and LibreSSL are doing for OpenSSL.
Sort of. The NTS people appear to be ntpsec people: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp... , and talk about how clearing out the crud (including unused modes) provides enough headroom for the work of adding security.
Re: Grappling with Go
#88Earlier quoted context omitted.
Because they are not competing with another! :) Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-c... -> "Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering e…
With a sub-millisecond GC pauses there are many overlapping use cases. For example, while you might need Rust to target a PIC or a ESP-32 class processor, Go will run perfectly fine on a ARM Cortex-M3 which also has hardware vendors selling Java compilers, e.g. MicroEJ OS ( http://www.microej.com/ ).
GC pause time is not the only criterion, and focusing on it to the exclusion of all else is problematic.
I used to have to explain this in a HN comment every time it came up, but now Mike Hearn has written up [1] better than I ever could, so I can just link there :)
[1]: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
Re: Grappling with Go
#89Earlier quoted context omitted.
Pass the release flag when you build loc; `cargo build --release`. I see ~5 seconds for loc and ~34 seconds for loccount to count a freshly cloned linux repository. edit: woops, that was user time. These both spin all the cores. loc takes ~0.7 secs and loccount ~6.6 secs real time.
I'm not seeing any changes in my results. I'm testing in an old laptop, I guess that's why it's so slow. My rustc version is 1.15.0 and go 1.8.
If you are running the program with `cargo run` that takes the same --release flag. Could be the machine difference though.
Re: Grappling with Go
#90Earlier quoted context omitted.
They certainly have a lot in common, either way: - Both compile to native code. - Both care a lot about performance. - Both care a lot about parallelism. - Both care a lot about safety. - Both were invented by a major browser vendor, roughly around the same time. - Both include an unsafe fun zone that lets you play with raw pointers. Maybe some of that was inevitable just by following the trends in the field (safety…
Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP? Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I ca…
> Go doesn't go beyond Java level safety
Go doesn't reach Java level safety because of a lack of generics.