as-j

That's why I excluded Uber and the like, the push was for the same strategy for all sorts of their smaller invesments.

Edit: thinking companies like Wag, DoorDash, etc

I wonder how much good vs damage SoftBank has done to tech companies, or was it just te normal consequence of the end of the tech bubble? I don't mean Uber, WeWork and the high profile ones, but the less news worthy failures. What do I mean?

SoftBank funded companies were told to grow at any cost, scale to become the market leader. A lot of companies weren't mature enough, or maybe not viable enough to do so and just burnt through cash and ended up with nothing as a result.

I wonder how they would have done had they not had such a strong drive to grow at any cost?

This is really cool, and great to see Lua project on HN, I think it's a woefully undervalued language. If someone knows LTUI 2 questions:

1. I tried to find api docs, but it didn't leap out at me. Is there one?

2. i wonder how you can include LTUI with an existing event loop. (hence why I was looking for #1) app:run() is great if the UI is the standalone app, but if I'm doing async io or any other more complex lua app, I have to combined the two event loops.

If only my system was big enough to have ncurses this would be super cool and I'd use it right away. <shigh>

We use lua and coroutines heavily in an embedded Linux project. We use ubus, and uloop from OpenWRT, which have Lua bindings^1. It works really well, and makes some very nice to read code in the final application.

It's nice to see someone using it well, and Lua's lack of a good TLS/HTTPS bindings is a bit sad.

Lua does have it's issues, and can be a pain. But it's an incredibly powerful little language that really fits our needs well on a embedded system with restricted ram. Debugging an app when are 4 coroutines deep and have 4 stack traces unrolled on the screen...isn't so fun.

---

1) Though they leave a bit to be desired, and we've cleaned them up. I need to remember to try and see if we can it get upstreamed.

The saying pilots generally have is "If you have time to spare, go by air"

Ok, going 40mi you have only so much weather than can go wrong, but I've had friends trapped at an airport due to weather, leave their plane and drive/fly commercial home. It's a fun hobby though. :D

> Do you remember landlines, and how responsive they were?

They weren't always, except for local calls. My Background: I made a lot overseas phone calls in the 1980's to talk to my father, from North America to Japan. I also took a telecom class going through uni.

When calling Japan, not only was it crazy expensive, but the connection was typically terrible. We considered it amazing to be calling Japan at all, so that was ok. Issues:

1. Latency, just start talking when the ringing stops. If you wait to hear the person say "hello" they'd generally hang up before they heard you. Sometimes it would be around 5s latency, we always said this must be "satellite" connections vs using undersea cables.

2. Voice quality. You could hear and recognize the person on the far side, but that's about it.

3. Cost. I don't remember the cost exactly since I was young, but I remember it was between $2-$5/min in 1980's dollars. Calls were short.

Latency was a major focus of telecom networks for a couple of reasons. One was human, obviously humans really prefer low latency in telecom networks. Good old school POTS lines also have to sidetone[1] the old fashioned way, and if the round trip time gets too high it's really disruptive to hear your own voice > 300ms later. But this causes a big echo problem, so have a shorter round trip time makes the echo cancellation filters shorter/easier.

1) Sidetone is hearing your own voice come out of the speaker. Analog POTS lines are super cool this way, on longer connections the signal is weaker so the sidetone is weaker, so the human speaks louder. This means their own voice is louder so the person at the far end can hear them over the weaker signal.

On 2 you've got a point, but it does depend on the dev and how fast a language is moving. I tend to find, or feel this push on newer languages to always being pushed forward.

We're on python 3.7, 3.5 and 2.7, yay! :) Don't use it on embedded systems though, version just depends on who's backend, mfgtest, etc, we're dealing with.

That's awesome thanks! I look forward to it.

Nope?

This?

https://ferrous-systems.com/blog/2019-06-05-sealed-rust-the-...

Do you have a short version recap in 1 or 2 sentences? Plus any liensing/costs/etc/etc?

This is amazing, and great. "Does a language change too much" is very much use dependent, and it's great to have the data.

For me, an embedded systems developer, this is an order of magnitude too much. Rust is so appealing for my use case in many ways, but I need an environment that a team can easily work in for years. My current code base is 10 years old. Our base system dates from 2017, and it took until 2018 for us to update to that. We were going to do a late 2019 base update, but sadly the project was delayed for other reasons. Our application side updates monthly, a much smaller OTA DFU. (over the air device firmware update)

You can compare it Lua:

https://www.lua.org/versions.html

The community is much smaller but it's interesting to see even at it's comparatively glacial release schedule there's a large split between 5.1/5.3.

Why do a rapidly evolving language, stdlib, etc matter?

1. We're going to be year(s) behind. I need everyone to learn and be proficient at the languages we use. They need good consistent doc and manual for our version. And not complain that we're on 1.31.0 but this great feature is in 1.33.1.

2. Moving base languages is support, not direct project improvement. While we standstill moving the base system/language/tooling forward our customer releases a new feature.

3. People are always going to google "how to do silly thing" and get code snippets. Heck I do this all the time with Python. =) It's really nice for this be somewhat consistent/right.

Sigh, as an embedded dev I'm so torn on Rust.

Cool!

Something I wish project docs would always include is …why… and what. Why does fe exist? Why did the orignal author spend a span of 6mo on it? What can it do and what can't it do? Don't make people read between the lines. It can be just to learn and have fun! But please don't make me read between the lines.

The overview is interesting:

* Supports numbers, symbols, strings, pairs, lambdas, macros

* Lexically scoped variables, closures

* Small memory usage within a fixed-sized memory region — no mallocs

* Simple mark and sweep garbage collector

* Easy to use C API

* Portable ANSI C — works on 32 and 64bit

* Concise — less than 800 sloc

Since I work in embedded Linux systems I always like looking at small languages, using Lua at the moment. So it struck my interest, oooh this is interesting.

The single fixed allocation is interesting, and odd. It then has gc...so why On the not just use malloc the manage the pool? I wonder if the performance is that much better?

But beyond print there's no IO library, so I guess it's a "toy" language, maybe somewhere to learn a lisp flavor?

So sorry to hear you lost your job, it's pretty traumatic, going from working every day, dead lines, things that important to suddenly, none of that's important and not your problem. Personally I've found it jarring the few times it's happened to me, and it's really hard.

So a few thoughts:

1. Were you the only one laid-off or was a portion of the org?

2. 3.3 million people in the US filed for first time unemployment last week, and it'll surely be similar this week.

A couple of weeks ago I got asked "what if we need to cut engineering staff?" And we ran the numbers. Of course the first thing I did was push back, we won't be able to hire them back, it's an amazing team of dedicated engineers, if the bad times are 4 weeks this will gut our skill set, at this level what managers are left, do we need any? Certainly don't need me. Thankfully we found a way through without cutting engineering staff.

It's pretty dreadful on the engineering management side, though not as devastating. I never want to let any of my team go, but I can't be a petulant child either. :(

How we pick people...sometimes it's seniority, or experience with the product/team/etc. Sometimes you just have to reduce to meet burn rates.

I don't want to recommend any 1 leadership book. But leadership comes in big L and small l versions. Technical leadership is important, and something I would expect out of any team member with 15 years experience. Much of the literature focuses on how to be a big L people leader, but if you want to stay technical ferret through all the books and find a book focused on how to be a technical leader/architect/etc.

my reply was for montalbano directly. He has K&R which lays a foundation of the language. Maybe you're right and this builds off of that as a #2 type of book, so you could be right there.

Safety-critical and security-critical are interesting for an intro book. I'd like people to be aware, and conscious of of them. Anyways, we could debate this one. It really depends on how paranoid a beginner programmer becomes.

Looking over the contents, it seems expensive for what you get and what not might be the most practical day to day C issues. If you want to use C more effectively, I'd look at a systems programming book for what ever system you prefer. When hiring engineers knowing C isn't the issue, knowing how to code daemons in Unix, how to use sockets, pipes, io, handle signals, etc etc is the issue.

Contents are:

* How to identify and handle undefined behavior in a C program * The range and representations of integers and floating-point values * How integer promotions are performed and how they may affect portability

I think it's incredibly important to understand how numbers on computers work, what are the limits of 32bit and 64bit values and how double/floats play into it.

* The order of evaluation of expressions

Most coding styles avoid ambiguity by just using (enough parentheses) around (important statements).

* Dynamic memory allocation including the use of non-standard functions

Non-standard worries me here. Memory allocation isn't particularly

* The philosophy underlying the use of character types in C Character encodings and types

I'm curious as to what this is covering? Is it system specific?

* How to perform input/output (I/O) with terminals and file systems using C Standard Streams and POSIX file descriptors * The translation phases implemented by the C compiler and the role of the preprocessor * How to test, debug, and analyze C programs

IO is an interesting topic, but I suspect best covered by a systems programming manual. There's several unix books, Stevens being the goto guide historically, and I would go straight to the source instead.

I think perhaps you're being overly pedantic, missing a free, or leaving a reference to no longer used memory has the same result for the application, the heap grows and eventually causes problems.

I run a distributed embedded Linux systems, and we use both C and Lua which is GCed. We track heap use from both Lua and C daemons for pretty much exactly the same reason. Both C and Lua apps can leak and I need to know if we've got a problem in field.

Our biggest problem in C is Jansson and keeping track of all the borrows vs steals of references. Lua is so dynamic it's sometimes easy to lose track of someone holding a reference for too long or forever. When you mix in closures, sometimes it's not always clear what the lifetime will be, especially if the result or error never happens.

They've never bothered me, I treat them like any other wild animal, give them a wide berth, let them be, don't trap them, and don't turn my back on them. Normally they're going somewhere, and just let them go there.

I worry about people with dogs since dogs can easily chase a coyote, corner it then get bitten or eaten if it's small enough.

As an early morning runner in SF, I see coyotes in SF every week or two, including at Twin peaks as mentioned in the article. One morning in Golden Gate Park I warned a few people walkings dogs since there were about 4 coyotes around the corner.

From my first hand experience, I'd assume any wooded area with cover in SF has a coyote living there.

The city prohibits from being rented long term since it lacks a full kitchen. The SF rules are, I could not airbnb if I could rent it long term.

It would make a big difference to me. :) But it would not change supply.

I have an airbnb off my garage. It's a granny flat, a bed, a small bathroom and a kitchenette. A sink, but just a hot plate a fridge and no oven. It's not somewhere you'd want to live for a long time, in my opinion. But it's a great place to crash for a few days, have a cold breakfast, some oatmeal, reheat left overs, etc.

There's people like me who it helps live in SF and offset property taxes, price of the house, etc. Bad actors/bad markets/etc certainly do exist, but like all things it's complicated.

I've crossed or gotten around Market to/from my work for the last 3 years. These articles are more hype than anything. Thoughts:

1. This has been slowly under way for years, and finally closing it cars really isn't a big deal. I would never have willing taken Market east of 10th for years, there's better and faster routes. (Mission, Folsom, etc)

2. You can still cross Market on car. You have too, going between the Financial district, SoMA, and then highways, 80, 280. So there's plenty of cars around.

3. Market is already clogged full of buses, trams, etc. It's not like it's turned into this walking boulevard heaven.

4. The article calling "one of the cities busiest...thoroughfares" seems pretty disingenuous. I admit I don't have the stats, but in the closed section it's slow, essentially 1 lane, ton of lights, etc. Yes there's a ton of buses, trams, etc but for cars...I can't see it. Is it really busier than Mission, Howard, Folsom, Harrison, Pine, Geary, Oak, Fell, Gough, Van Ness, etc? Ex: Franklin is 4 lanes of traffic going 1 way, with a timed green wave of lights.

5. West of 10th up to the Castro then Twin peaks, and when Market turns into Portola, now that's a busy road, and I use it a good bit.

I've lived in a 1 bathroom house in the US and i said never again. It was one of the first things I looked at when buying a house overseas as well, and it served me well.

Problems with a single bathroom which includes the toilet:

If you have kids, everyone is fighting over a scarce resource in the morning. Showering/shaving/etc all takes time and you're all leaving in a narrow window.

If you don't have kids the people buying the house may, and they will care. It makes selling the house so much harder.

The bathroom _must_ be cleaned to be guest ready, and they get to accidentally snoop through everything. I love my ensuite for this reason. (and if you don't care about it being clean, your partner probably does)

If you have the room, why not have an extra bathroom? So much easier to build in new construction than add later.

When I lived in Australia the toilet was in a separate room, so the 4 bedroom house worked ok with only 2 bathrooms. The toilet wasn't blocked/held hostage by someone taking a shower. (washing your hands on the other hand...) But this also helped sell the place, since with 2 full bathrooms you can have kids/house mates/etc.

My current house has 3 baths with 4 bedrooms. One is in the in-law suite, which I airbnb, so we have 2 on the main floor. It makes 2 baths for 3 bedrooms. This feels like a nice "adult" house. We have a spare rooms for house guests, and they have a full bathroom they can use. This means we can host friends/family for days/weeks and we can be annoyed by their personality, instead of annoyed fighting over a bathroom. ;)

Of all the weird things in the US, a house having "too many" bathrooms really doesn't seem like a problem.

Ok, I know maybe it's too early in this projects lifecycle, but when I read the page this was my initial reaction.

As an embedded engineer I found the github page incredibly frustration, and it's tempting to just write it off. If the original author, or anyone else putting a putting together a language page, here's question I shouldn't have to dig for:

1. Where's an example this has been used professionally? (or out side an academic setting) I'm pretty risk adverse since FW/embedded systems are harder to OTA, and changes once we've approved the HW design blows up projects. If it hasn't been, be upfront about it.

2. What's the plan for the project? Is the language stable? Is a standard library next? I use a vendors language/BSP to avoid writing everything little thing from scratch, like printf()

3. Give me a comparison to other languages, why should I use T1 over any other embedded solution. Include size, and maybe the performance hit.

4. Show me some code. If I'm picking this for a project I need to think of everyone else I need to teach the language too, and how they'll accept it. It really helps for a quick glimpse at the syntax to see how foreign it is. Even if it's just Hello World.

5. How do I access peripherals/HW? For example if I need flash/nvram persistent storage, access to the serial port am I back to C to write driver or interface to the BSP? If so I now need good C skills, T1 skills and good binding skills.

Thanks for everyone for the slides, reading the hacker comments pretty much answered 1-5:

https://t1lang.github.io/NorthSec-20190516.pdf

https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/asn1...

I think this would be amazing for some cities. I've used a electric motorcycle/scooter to commute around San Francisco for 3 years now, and it made me fall in love with the city again. I've used Jump e-bikes to get around as well instead of Uber/Lyfts when I can. (I'd use them more, but their service area stop a mile from my house)

Sadly I think SF is a good special case where it works well most of the year:

1. City is pretty compact. It's not exactly 7mix7mi, but not far off either.

2. Weather is pretty good most of the year. (no ice/snow/freezing rain, etc) Yes you can cycle in fog. ;)

3. Speed limit is 20mph in residential, and 30mph on busier roads, but congestion generally makes the impossible. Bike lanes are normally free.

4. Bike lanes/paths/routes are expanding throughout the city. Including nicely protected routes.

5. Parking and Gas are expensive here. I was just in Texas and filled up a car for < $20. I can't remember when I did that last.

Sure it's a dream, and I wish the article would come true here. Imagine how cool it would be to have tons of bikes on the road and so many less cars/ICE zooming around? Ok, maybe I'm just not a car person. ;)

There are hiccups though:

1. Carrying groceries/etc. You can't get a shopping cart full and take it home.

2. Kids...getting them to school. Cargo bikes here are an option, but they need to be a certain age and I do worry about safety. :/

3. It does rain...and ridding in the rain sucks. Most parts of the US get it so much worse though, it feels hard to complain.

4. Commuting via bike to work does take time/effort. Carrying a change of clothes, showering, etc, etc.

I really hope this gains traction. i use Lua in a professional setting on an smaller embedded Linux system. Lua's memory requirements, ability to bind with C, and developer speed really works well for this project.

But it feels like a strain on the Lua community to have LuaJIT essentially "stuck" with Lua 5.1. Many projects seem to have taken a long time to move on and start moving forward to 5.2, or 5.3 which were released in 2011 and 2015 respectively. LuaJIT is so impressive it feels unfortunate to leave that community behind and move forward.

When we evaluated Lua, and which Lua version to go forward to this was our key points:

1. LuaJIT was abour twice as fast for us. 2. LuaJIT has nice C integration/binding. 3. LuaJIT was no longer maintained/developed/etc and was now ~10 years out of date wrt to the core language. 4. Lua is being used in non-performant areas, we have C when we need performance. 5. Integers and bitwise from 5.3 operations are important for us. 6. Overall the changes in 5.2 and 5.3 are good language improvements.

We ended up going with Lua 5.3 due to ongoing development, and for us it ticked all the boxes. But it would amazing to have the options to use LuaJIT, and to encourage everyone to move forward instead of being stuck on 5.1.

If you want to skip the install, and misc setup, and just see the game:

http://www.youtube.com/watch?v=A33pDTAFtdY&t=1m23s

I think I work beside the 2nd one... ;)

No, because I like doing things outside in the summer after 6:30pm.

> Changing our clocks twice a year has little benefit, economic or otherwise

I've lived in 2 different places in the world that did not do DST, and I have to respectfully disagree for many cases. In the summer the sun would rise before 5am and set by 6:30 or 7pm. This does curtain outside activities. Sitting outside at a restaurant, maybe having a drink, is much easier to do while the sun is up, the bugs are at a bay, etc. Or maybe a BBQ in the backyard etc, all are much easier to do when there's natural sunlight. (then let's talk about sports games, no major leagues but kids sports, etc, etc)

So yes we could all start getting up earlier and say going to work earlier...Say starting work at 7am and leaving at 4pm...but this is what DST does for us.

Caveat:

It greatly depends on where you are in the timezone, and how far north you are. Growing up in northern Canada the sun set at 11pm and rose at 4am, so it did make little difference.

2nd Caveat:

Yes full time DST could be right for some places. But! That's damn confusing if someone has a different time through the year. When I lived in Indiana they didn't do DST, so the time didn't change. And it felt like half the phone calls outside the start started with "what time is it now." So there's something to be said for consistency. :/

I've been lucky (?) as a guest and never had a serious issue.

But friends have, and a phone call fixed the problem in the instance actually fixed the problem.

As a host I've had guests call airbnb and ask for exceptions for my cancelation policy (which is moderate) and have airbnb grant them and cancel booking at the last minute, or after check-in time and do 100% refunds. (or at least I get $0)

So while you might be trained that way, and it's understandable, they publish their number and make it pretty available to guests. Maybe the problem is labeling it an emergency number? (I take emergencies as huge deals so naturally avoid calling emergency numbers)

It's a shitty situation and I don't really want to blame the victim. I just really wanted to point out there's an number you can call for help and if you call it earlier they can help you. In case it helps someone nn the US its: +1-855-424-7262

Sorry maybe I wasn't clear. Why didn't she contact airbnb immediately when the host suggested an alternate place that cost more. This is a big red flag, and a simple phone call probably would probably short circuited the article.

And yes this has happened to friends, showed up a place that wasn't as described/ready/etc. Called and complained and ended up having airbnb book them a hotel.