parley

As a complete bystander there may be history I'm completely ignorant of, but in Gogs issue 1304 Unknwon themselves wrote:

"In my point of view, it's a sign of success of Gogs that Gitea forked it. Gogs is under MIT license and there is no problem with me totally that Gitea is developing its own version. It happens often in open source community(when you are not satisfied with upstream version, I fork a lot actually)."

In the same issue comment Unknwon also states that they believe Gogs and Gitea to have fundamental philosophical differences, and finishes off with thanking everyone and wishing happy coding.

I don't know all the facts and Unknwon's personal view may have changed in last 18 months, but just judging by the philosophy of the original author and maintainer of Gogs the lack of courtesy, tact and respect of their roots that you refer to might be an opinion of yours that Unknwon doesn't share. If that is so, then what do you mean they lack courtesy, tact and respect towards?

Of course, if I'm mistaken or there are more recent opinions of Unknwon's that contradict this, then please disregard this comment.

It would be so great if Sean got to work full time on hyper, but of course I understand that he is needed elsewhere at Mozilla and he's doing a great job with the time he has. I would hazard a guess that there are so many besides me waiting for the upcoming HTTP client/server improvements that it would probably not be the worst idea if Mozilla (or some other org betting on Rust) threw some money at it.

I'm extremely grateful to everyone working on Rust and its ecosystem (paid or otherwise) for the work that you do. It sure sounds cheesy, but after trying lots of stuff over the years, Rust feels like coming home. There, I said it. I'm pushing it at my employer, and for every piece of tooling or important crate that matures, it gets easier to evangelize.

I love Firefox and use it heavily every day as main browser for 99% of web browsing, which is a big reason why I also donate money to Mozilla.

However, Sync has a dissappointing property: Despite the (simplified) claims on the most readable user facing pages about it, it will not sync your open tabs across devices. It will only sync your last 100 (?) active open tabs on each device.

I will happily admit to being an outlier with >100 tabs per device, and I'm very grateful to Mozilla for this free service they're providing me. I also understand that any such service may need an upper limit.

However, had there been any mention of this fact anywhere other than the bugzilla issues I found while trying to figure out why Sync was (in my perception) not working properly, I wouldn't have tried it. I'd love it if they were just accurate about this in their feature description.

I'm really looking forward to when rustup.rs is stable (atleast for Linux)! I'm trying to push Rust at work, and it's one of those polishy things that would help.

Unfortunately, last time I checked development (on issues blocking the initial stable release) seemed to have slowed as of late, but I should be helping out instead of whining - the Rust community is doing great work!

I write high level automated tests immediately at the beginning of a project, which have several upsides:

They can be read almost like project requirements, so they double as validation for solving the problems in the reqs.

They only use the outermost APIs of your code, which will change much less than internal module APIs, and so won't inhibit changes and experimentation as much.

They enable you to automatically test your code in the "real" scenarios that your project reqs describe, instead of just module-level tests that may not catch bugs in API usage of those "real" scenarios.

Later on in the project, as larger internal modules crystallize, you isolate those modules with their own outer APIs and write automated tests for their APIs.

Yes, this has downsides. High level white box testing exclusively during early stages obviously won't catch all your internal error cases early. However, I have found them to have superb ROI, especially in projects where time constraints have required pragmatic approaches.

YMMV.

Looks nice!

One question though: I didn't see any mention of an API (or other means of exporting data). Is there or will there be an open API?

I tend to never lock my data up any more, having been burnt too many times. Of course, this might not matter to most people.

I have a feeling that that's the completely wrong way to look at it, although I'm happy to be corrected if I'm wrong.

Today, GPU vendors write big, complex, closed-source drivers offering high-level APIs that as a result are buggier and harder for FOSS-developers to keep up with and make FOSS replacements for.

With Vulkan, GPU vendors should write smaller/simpler drivers, in theory making it easier/cheaper for them to provide good drivers and probably reducing the amount of work needed to produce a replacement FOSS-driver.

The complexity and the high-level APIs is supposed to move out of the driver and into libraries and engines, and many such will be FOSS and probably more portable than the FOSS kernel drivers can be. Please correct me if I'm wrong, though, as I'm not a graphics guy, but I was happy for FOSS when I first read about Vulkan.

I'm not a financial expert and can't speak to what's true or not, but here's [1] a short interview with Swedens former Tax Agency chief who was apparently part of a small task force to evaluate Greece's tax collection and aid in its improvement.

He claims that removing corruption is not the only problem, and that the rest of the EU are underestimating the lack of tax collection competence with regards to modern methods and processes, as well as the powerlessness and political isolation of the Greek tax chief, making his/her job impossible - e.g. by not even being allowed to pick his/her own employees.

Again, I don't know what's true or not, just providing the opinion of a former Tax Agency chief of a country that collects a lot of taxes and who apparently had the opportunity to take a closer look at Greece's tax collection.

Google Translate does a decent job with the article translation.

[1] https://translate.google.com/translate?sl=sv&tl=en&js=y&prev...

EDIT: Grammar.

Songkick is one of those services where I feel that it's a fair deal surrendering my data (listening habits) because I get a service in return that's really valuable to me. When I tried it out the first time I was surprised at how good recommendations I got for my geographical vicinity (Sweden/Denmark), as many services - naturally - focus on the US only. Three cheers from me to SK.

I've been porting some JSON/HTTP API servers from Go to Rust recently, and it's been a really nice experience. Rust has convenient struct serialization just like Go, and Hyper is coming along as a nice (relatively) low-level HTTP library. If you want a higher abstraction HTTP server, go with Iron that builds on Hyper.

The I/O libraries have more work to be done (mostly for the async story), but they're ok for now and the plans I can see look promising. I see a bright future for those of us who like to write robust and high performing API servers, so don't shy away from Rust in that domain!

EDIT: Forgot to say that everyone's very friendly in #rust-webdev where Hyper/Iron authors and others can be found.

It is an interesting question and one that's quite debatable. I enjoyed the discussion in [0] the panel "Systems Programming in 2014 and Beyond" from 2014 with panel members Bjarne Stroustrup (C++), Niko Matsakis (Rust), Andrei Alexandrescu (D) and Rob Pike (Go).

Have to say I agree with Bjarne and Niko on most points discussed.

[0] https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pa...

It probably wasn't the first occurrance, but I have a vague memory of hearing it formulated like that first from Niko Matsakis in a Rust video on Air Mozilla.

It's fine, go ahead and fix it. And thanks for your hard work on Rust! =o)

Steve: Perusing or pursuing the trifecta? =o)

Thanks for your reply! An enjoyable exchange in the midst of what often feels like a bit of a very tiring flame war.

I am constantly on the lookout for languages that could be suitable for replacing (or greatly diminishing) the use of C/C++ in my work, and so far Rust is one of the front runners.

However, I am also very much aware of some of the troubles I would most likely face in convincing my colleagues, like language complexity and productivity, and I completely respect the decision that it may not be worth it, depending on a wide variety of factors.

I try to keep an open mind, and I look forward to reading more about the improvements to Nim you envision! Thanks again (and good night). :)

Thanks for clearing that up!

Thanks for correcting me, Patrick. I certainly didn't mean to be unfair (especially as I replied to a comment I felt wasn't being completely fair itself, intentionally or not), and I should have been more precise about the use cases.

I agree about the GC considerations. I meant my points to mainly apply to the use cases where safety such as that offered by Boehm is eschewed in order to achieve other powers at its expense, which I feel is brought up a lot by Nim proponents as strengths during these discussions.

I also apologize beforehand for a long reply. Long posts get long replies.

I can definitely understand this point of view, but I just can't agree. The parent probably wants his/her claim that Nim seems as memory-safe as Rust to not be interpreted literally, as a literal interpretation would make the statement false (by any fair comparison using idiomatic code from both languages to accomplish the same thing).

What the parent is surely talking about is how it pans out in practice. Different languages have their different trade-offs here with different pitfalls, and denying that Nim can crash and burn due to memory management mistakes would be false. Denying it with respect to Rust would also be false, due to Rusts optional unsafe features, but the important distinction is how easy it is to make these mistakes in idiomatic code and what the consequences will be. Only time will tell, which is why anecdotes are of interest, of course - both the parents and everyone elses.

However, I find some choices of words to be a bit disingenuous (though hopefully unintentionally so).

The claim about being able to do "so much more at a low level", like e.g. being able to switch out libc variants, which allegedly is not possible in Rust due to accidental coupling. Is this a temporary difference? If so, it may only be relevant in the short term. I can't answer this question, but it would be interesting if someone did.

Most importantly: "Even though it's not as formally safe as Rust yet, in practice it feels and acts as safe, without the cognitive overload." Yet? Making Nim as formally safe as Rust would require completely changing key aspects of the language. Feeling as safe is possible, and acting as safe is possible too...

... until it doesn't anymore, that is, because the team grew (as it always does, some leave, some join, etc) and the code base ballooned and someone made a simple memory management mistake somewhere that is now a serious debugging problem and no code can be eliminated beforehand from the necessary auditing because the entire code base is vulnerable to these classes of errors.

Memory management errors have a way of resulting in seriously trashed core dumps, etc, sometimes severely complicating and limiting debugging possibilities. Where's my stack trace? Oh, we seem to have been executing data and not code. Where did we come from? Oh, no intelligible stack frames. No valid return address in the register, etc. I've been there, as I'm sure many of us have. Memory management errors can lead to complete debugging nightmares, and that's if they're even reproducible by developers. If they're only triggered at the customers site due to their unique circumstances, good luck. Having a deterministic test trigger it and being able to run it through valgrind until it's solved is the optimal cake walk scenario, but that's not real life most of the time.

Rust can step quite easily from low-level stuff to high-level features and meta-programming too, and I feel no comparison is really made by the parent, only talk of Nims features. The central premise as always for Rust is that it provides what it can provide while still maintaining memory safety. Rust without this prerequisite would not be Rust, and the constraints for everything else flows from it.

The repeated claim of design-by-committee is also not the best one. Having followed Rusts back-and-forths for years, I have to say I feel the discussion has been extremely well functioning, and most importantly: The choices have been very pragmatic within the constraints of preserving the key safety features of the language.

Personally, having gone through many languages all over the abstraction level spectrum and specifically having spent quite some time in embedded C/C++, I am terribly, horribly tired of fatal runtime errors in general and memory management errors in particular. They can cost so much time to debug and fix that development time can swoosh past what it would have been in a language with a type system preventing them in the first place. Your mileage may vary, of course!

There is something to be said for languages that simply eliminate these classes of errors compile-time, and that something is actually a lot. For the small programs, tooling, scripts... I can write them in anything. There are hundreds of choices. That's not what this is about. For the software that matters, that ships and that others will expect to work, I no longer have the patience or tolerance for these error classes.

Many languages with such safety guarantees (and Nim is not one of them) have already existed for a long time, but very few that can be applied to all the use cases that Rust can. That is what it's about. This is why people are excited.

Software development is a form of art and a form of engineering, at the same time. A lot of software doesn't have to be as reliable as space shuttle firmware, and I'm not claiming it has to, but the general bar could sure as heck be raised several notches. We know how the world works, and yesterdays quick hack or proof of concept is todays firmware shipment for use in live environments. Successful software lives for a long, long time. Software is eating the world, and society is now at its mercy.

Personally, I will sleep so much better knowing that these error classes were wiped out compile time in 99.?% of the code I shipped to those customers, while being able to maintain on par performance with the C code it replaced.

These are of course my $0.02, and I hope it didn't come across as combative as that was definitely not my intention - only passionately conveying my own perspective. :)

Sorry about the acronyms.

MVP occurs a lot on Hacker News, in that context meaning Minimum Viable Product, or the least amount of work you must do to make it useful for users/customers.

BDD in the software context means Behaviour-Driven Design and is an opinionated way of writing tests.

With regards to step 3 in your example: Sometimes it can be challenging to design automated tests for certain functionality.

For a game, it could be scripting "fake" user input that is supposed to have a certain end result, and then verify that that end result actually occurred. E.g., the player makes a few good moves, then a few bad moves that should cause health to drop below 0, then check that the player actually died.

Automated tests are a life saver, and often it pays off in the end to learn how to write them for almost any functional requirement.

I hope I answered your questions!

This is good advice, and I agree!

Anything larger than a small project will need to be put aside for a while from time to time (for whatever reason), and I've found that making it easy to pick it up again is one of the most important things you can do.

My strategy for this (admittedly most suitable for software projects):

1) Write down your large, fantastic vision for the finished, complete project.

2) Write down the smallest possible feature that would bring you some utility. MVP, if you like.

3) Take this requirements and write an automated test at the highest level of abstraction possible. It should almost read like the MVP requirement you just formulated. That doesn't have to mean BDD, just something you can read easily.

4) Implement until the test passes.

5) Go to 2.

What I've found over the years is:

- Quickly reaching milestones of utility are key for keeping motivation while working. This is obvious, of course.

- The written down vision brings the motivation and big picture plan back when picking things up: Get your blood pumping again!

- The automated tests help keep implementation going when your drive falters. What should I do know? You should just make the test pass. Nothing harder than that. No need to think super hard. Just try to make it pass.

- The automated tests help you get hacking again without the immediate fear of breaking things: Get the ball rolling again, quickly and easily!

- The automated tests also serve as your requirement specification so far: You can easily see what already works.

Side projects are so important, and one should make it as easy as possible to sustain and restart them! Good luck!

Some advices in this post are related to restrictive tooling and some are related to adjusting ones attitude. Whereas I used to rely on the former, nowadays I find the latter brings a completely different (and better) kind of calm.

This article [0] is one of the best ways I've ever seen it put, and I think both the culling and surrender parts it mentions are very important - not just one of them.

Inner calm is so important. Like countless others in this post have said: Try meditation, and give it time. It can be an important piece of the puzzle of silencing those voices.

Good luck.

[0] The Sad, Beautiful Fact That We're All Going To Miss Almost Everything: http://www.npr.org/blogs/monkeysee/2011/04/21/135508305/the-...

> There is absolutely a place for an API like this -- but that place is not as a replacement for OpenSSL.

I disagree. I think it is exactly the place for an OpenSSL API replacement.

As is alluded to in this link (thanks cremno) [1], they want a critical mass of users before it makes sense to deprecate the libssl API. Deprecation seems necessary in order to perform the serious cleanup/reimplementation under the hood that they would like to do.

While new projects may have an easier time, they admit that adoption by existing projects is significant work. However, so many and large projects already exist that it seems that many of them need to be won over in order for a deprecation to be practical. Many existing projects (see other comments in this post) use this transport layer flexibility in the OpenSSL API, and not offering it with the new API may slow adoption.

Yes, like you say another API layer could be added, and it is a deeply subjective matter so let's agree to disagree... But composability is so important and only becomes more so as we tire of wheel reinventions leading to unnecessary bugs. Enabling modularity and reuse needs 1st class API attention. Being able to easily plug this new API as a source/sink onto the myriad of existing (and yet to be created) I/O frameworks would be a major win. This is my $.02 and humble appeal to the people doing the fantastic work on this lib. My thanks to all of you!

[1] https://marc.info/?l=openbsd-tech&m=141524972826918&w=2

And I really like the new API. Kudos to the creators. I would really like to use this new API in a simple, straightforward and internally consistent way - and grab the byte stream after encryption to feed it into my existing I/O framework. Please forgive the sarcasm, but all my comments are derived from a will to see this new API succeed, which is why I don't want this use case to be overlooked while designing it. If I was happy staying with the original OpenSSL API I probably wouldn't have voiced my concern as fervently.

> I believe so too.

That sounds strange, as I believe we're in disagreement. I believe the flexibility should exist, and choosing the transport medium of already encrypted data should be an option for the developer. This is completely unrelated to the security critical configuration of the TLS protocol, i.e. certs, keys, ciphersuites, etc.

Yes, it's possible to "communicate with self" in various ways to intercept, but it's really ugly. Also, performance may suffer.

I agree whole-heartedly, and wrote as much in another comment below. This should not be overlooked.

I did read the linked page, but perhaps I'm misunderstanding something. To me, this looks like it still requires sockets or fds. I want to be able to grab the TLS-protected byte stream conveniently and transport it to the other endpoint however I see fit. This would make it possible to use this TLS implementation easier on top of I/O-frameworks that don't necessarily map immediately down to sockets/fds. Again, for improved composability and code reuse.

Please correct me if I'm wrong, but I believe that the OpenSSL API allows one to implement the actual transport of the TLS protected data however one chooses, although it provides convenient socket/fd transports. Is this a possibility with this new API? Regardless of whether OpenSSL can do it today, I consider this a very valuable feature and allows for more flexible composition of the TLS implementation and the rest of the system.

Edit: Grammar.

I did this for a decently complex distributed system for embedded devices, and it practically saved my life.

It was in C and I didn't do any language extending/precompiling, but I had interfaces for everything related to I/O, execution actors, randomness, etc.

On target hardware everything used TCP/UDP/real disk, pthreads, normal rand sources, etc. In simulation everything used virtual networking, a single simulation thread stepping all event loops, test-specified random seeds for reproducibility, etc.

It is completely invaluable. I can concisely write completely deterministic system tests that will execute tens of thousands of lines of code. I can fuzz test actor scheduling, I/O problems like dropped packets/msgs, and everything you can think of. I can run the entire test suite in valgrind and other nice tools. I can put a big machine in a corner of the office to fuzz test the suite for weeks on end and email me when a a test fails and tell me exactly which random seed to use to reproduce the failure myself within minutes. I can debug the entire simulation perfectly in GDB.

I've barely begun to describe how great it is to have, how many bugs these tests have caught or what a reliable regression test suite one can build. It doesn't replace testing on target - I do that extensively as well. Big system scenario tests don't replace smaller module and unit tests - I do those too. But deterministic simulation testing saved my sanity. Don't hesitate to evaluate this approach if you're doing something similar.

Could someone with relevant industry insight comment as to why we're not just using IMEI blacklists?

From Wikipedia: "For example, if a mobile phone is stolen, the owner can call his or her network provider and instruct them to "blacklist" the phone using its IMEI number."

Is it because it's actually mutable/not properly authenticated? Or because global blacklist synchronization isn't good enough and not all operators respect them?